I work in Cowork with a filesystem I control, or in Claude Code and also with Codex.

I instructed Claude and Codex to checkpoint into my external memory: keep a session journal in a fixed format markdown with front matter (date of creation, summary, keywords, status, links to related entries) and the body of such entry is the actual context and important notes, including also links to relevant files. (porbably what Claude or Codex could write in its own memories) and add such record to a common journal index. Notes are captured when I ask, and periodically if agent feels that we have some "milestone" in conversation. This means I now can ask Claude to make the "handoff" from such jounrals (give the filesystem links of the needed journals + the additional information) to "onboard" the other agent. I then simply place this in new chat and the agent onboards itself. I also can pick the needed articles myself and ask the agent to start from or let it search there ("start where I talked about.. on last week.."). Agents can search in this "context articles cloud" very efficiently. These "articles" are "memos" and are stored in one place on my file system organized by month when they were created and then by topics on which the agent was asked to work. They contain links to the project's relevant files, links to other notes in this knowledge base, and contextual information, real "context articles". Perhaps how agent would store it in their memories but now it stores in mine :) This also nice place for me to see that all, notes have clean visual organization and recognizable names. This really helps me.

Our "project knowledge" consists of artifacts of such types:

- product documentation (made by human). Intended product behavior and capabilities.

- technical documentation (maintained by human and agent who work together on feature). Implementation documentation.

- feature session journal (made by agent and human who work together on specific feature). Per feature session. Contains original problem, gaps, problems, misunderstandings and failed attempts.

- wiki and ontology articles for targeted knowledge retrieval. Built by Knowledge Keeper procedure under human supervision on demand. Consolidate the knowledge across subsystems.

- code and tests (mostly written by agents).

All these knowledge artifacts (except code and tests) are mostly markdown articles. They are stored in git - this allows versioned storage, authorship and diffs. All articles have front matter with summary, keywords, status (draft or reviewed and approved by human) and links to related articles, so we and agents know what is relevant and what the source of truth is. Wiki and ontology articles hold the semantic relationships for better retrieval.

Typical process of changes: As agent and human work on the feature, this is captured in the session journal. At any moment in this process, the engineer who works with the agent can ask the agent to hand off their work to other agents, integrate in the technical documentation or handoff to a Knowledge Keeper. Such handoff includes the message with documentation links and the link to the session journal, so one who continues starts with the context.

The Knowledge Keeper is a supervised procedure that keeps wiki and ontology aligned with the product documentation, technical documentation, known issues. Knowledge integration process is currently manually initiated by the handoff of the human who worked with agent on the feature. The Keeper prepares the integration plan which a human approves. Keeper builds the index on top of wiki and ontology after integrating the knowledge and tests the knowledge retrieval via MCP to check if integrated knowledge retrieves correctly and reports to the human maintainer. MCP allows the consolidated view of the product and its capabilities. Its answers point to the primary docs, therefore users do not need to find one person who remembers everything.