Name the Project Before the Conversation Drifts

A useful agent conversation needs more than a capable model. It needs a clear answer to a smaller question: which project does this turn belong to?

If that answer changes invisibly, an agent can read the wrong rules, suggest the wrong specialist, or look at the wrong local history. The failure is subtle because the reply may still sound reasonable.

APX makes project selection a per-turn decision. It uses the project already active on the surface, otherwise a project named in the message, otherwise the project named earlier in that conversation. That order gives a practical rule: when the project matters, name it before the conversation has a chance to drift.

A project is more than a folder

In APC, a project carries portable context: AGENTS.md, agent definitions, skills, shared MCP hints, and project metadata under .apc/. That is the contract a compatible tool can read from a checkout.

APX is the runtime layer. It uses the selected APC project to decide which agents, MCP servers, root guidance, and durable agent memory belong in the turn. Its conversations, sessions, task logs, and private runtime state remain local under ~/.apx/.

So selecting a project is not a cosmetic label in a chat sidebar. It is the boundary that tells APX which portable contract and which local working state apply.

Let the surface decide when the surface is clear

A project chat or code session already has useful scope. If you open the storefront project and ask for a checkout review, APX can use that project directly. The work surface and the project contract agree.

That is the best case for sustained work: stay in the project surface while the task belongs there. The conversation gets its agents and guidance from the same project whose files the work will touch.

But not every request begins there. A person might be in a general chat, replying from a message channel, or returning to an old conversation after changing tasks. In those cases, make the target explicit in ordinary language:

For storefront, review the release checklist.

In the data-pipeline project, summarize the failed import.

The project name is short context with a large effect. It avoids relying on a previous topic that may no longer be relevant.

Do not turn conversational carryover into ownership

Using a project named earlier in the same conversation is helpful for follow-up questions. After discussing storefront, a later “what should we test first?” can keep the same scope without repeating the name every turn.

That convenience should not become hidden ownership. Switch deliberately when the work changes:

Now for data-pipeline: list likely causes of yesterday's import failure.

A new project name is better than assuming that the last active project remains correct. It gives the next turn an observable boundary and gives a reviewer a simple explanation for why certain context was present.

Keep chat scope and command scope aligned

A terminal command has the same problem in a different form. When the current directory is not a reliable signal, pin the project:

apx messages tail --project storefront
apx agent list --project data-pipeline

The message-level name and the command-level --project flag serve one idea: state the intended owner at the moment it matters. Neither copies project rules into runtime history, and neither makes private session data portable. They only select the correct boundary.

A small habit that prevents quiet mistakes

Use the project surface for ongoing project work. Name the project in a neutral conversation when scope is important. Repeat the name when the subject changes. Pin commands when the shell location is incidental.

APC keeps the project contract portable. APX makes that contract useful turn by turn. Naming the project is the small bridge between them—and it is easier to trust than a guess based on whatever the conversation happened to discuss last.