A Conversation ID Is Not Project Context

A conversation ID may seem like an easy way to give an agent context, but it is not the right approach. A conversation ID is just runtime state, while project context is a contract. They should not be stored together. APC is a portable context layer that includes agent roles, reusable skills, project metadata, and MCP hints. APX is the runtime and tooling layer that runs agents and keeps local records, such as sessions, conversations, messages, caches, and task logs.

Using a split approach makes a clone predictable, ensures that a conversation belongs to one local runtime, and prevents the repository from implying guarantees it cannot provide. Committing a conversation ID to the repository can lead to issues, such as another machine not having the underlying conversation or not having permission to read it.

Instead, keep the durable decision and remove the handle, which should remain local to APX. When a new machine registers the repository, it should start a new local runtime history. This separation allows for portability without importing one machine's chat history, as well as safer cleanup and sharing of repositories without publishing chat transcripts.

APX provides operational continuity, while APC preserves what collaborators need to know before work begins.