A Conversation ID Is Not Project Context

A conversation ID can feel like the fastest way to give an agent continuity: save it in the repository, pass it to the next machine, and resume where the last prompt stopped. It is also the wrong boundary. A conversation is runtime state. Project context is a contract. They should not be stored together.

APC is the portable context layer. Its AGENTS.md and .apc/ tree describe the project: agent roles, reusable skills, project metadata, and MCP hints without credentials. APX is the daily-use runtime and tooling layer. It runs agents and keeps the local operational record: sessions, conversations, messages, caches, and task logs.

That split is not a limitation. It makes a clone predictable.

A conversation belongs to one local runtime

When APX registers a project, its committed definition remains in the repository. Its runtime data lives under ~/.apx/projects/<apx_id>/. Per-agent folders include sessions/ and conversations/; those files reflect a particular machine, engine, account, model context window, and moment in time.

A saved conversation ID may depend on all of those conditions. Another machine might not have the underlying conversation, might use a different runtime, or might not have permission to read it. Committing the ID makes the repository imply a guarantee it cannot provide.

The same mistake appears in a subtler form: copying a raw transcript into AGENTS.md or .apc/memory.md so the next agent can “continue.” Raw turns include temporary questions, stale tool output, and often sensitive operational detail. They grow quickly while teaching future agents what happened once, rather than what must remain true.

Keep the durable decision, not the handle

Suppose an agent investigated a deployment failure and found a durable rule:

The deploy command needs a clean generated-assets directory; run the project check before publishing.

That rule can become a reviewed project instruction or a concise curated memory fact. It can travel in APC because it explains an ongoing constraint. The conversation ID that led to it should remain local to APX, where an operator can inspect or summarize it when needed.

The resulting workflow is small:

1. Run work through APX; it records the local session and conversation.
2. Extract only stable, reviewable decisions.
3. Add those decisions to APC-owned instructions when they apply to the project.
4. Let a new machine register the repository and start a new local runtime history.

For a short-lived task, the durable output may be nothing. That is healthy. Not every discussion earns a permanent place in project context.

Portability needs a clean restart point

A clone should be able to answer: Which agents exist? Which rules apply? Which skills can run? Which project ID connects this repository to local APX state? APC provides those answers without importing one machine’s chat history.

APX then supplies the operational continuity appropriate to that machine: apx conversations list can inspect stored conversations, and apx session summary <id> can turn a completed session into a concise explanation. Those are runtime tools, not repository format requirements.

This separation also makes cleanup safer. Removing local runtime state does not erase repository rules. Sharing a repository does not publish chat transcripts. Switching from one supported runtime to another does not require pretending that an opaque conversation handle is a portable artifact.

Use APC to preserve what collaborators need to know before work begins. Use APX to retain the local evidence of work already done. A conversation ID can help one runtime resume a thread; it should never become the project’s memory contract.