Project Choice Determines AI Agent Success: APX's Per-Turn Boundary Strategy

When we use an AI Agent for conversation, we often focus on the model's capabilities themselves, but overlook a more fundamental question: which project does this turn of conversation actually belong to? If that answer quietly drifts during the conversation, the Agent may read the wrong rules, recommend mismatched experts, or reference irrelevant local history. The most troublesome part is that the reply still sounds plausible, but the error is already planted. APX's solution is to make project selection a per-turn decision, following a practical principle: when the project matters, name it before the conversation drifts.

A Project Is More Than a Folder: The Layered Design of APC and APX

In the APC (Agent Project Contract) system, a project carries portable context—including AGENTS.md, Agent definitions, skills, shared MCP prompts, and project metadata under the .apc/ directory. This is a contract that compatible tools can read from a code checkout. APX is the runtime layer, which, based on the selected APC project, determines which Agents, MCP servers, root guidance, and persistent Agent memory belong to the current turn. APX's conversations, sessions, task logs, and private runtime state are kept locally under ~/.apx/.

Therefore, selecting a project is not a decorative label in the chat sidebar, but a boundary that tells APX which portable contract and which local work state apply. This layering keeps the contract portable and the runtime state private, with the two connected through the act of project selection.

Agent Project Contract (APC) is an open convention for AI Agent toolchains, with the goal of decoupling project-level context from a specific runtime and making it an artifact that can migrate between teams and tools. Its core idea is to write "how the Agent should work" into plain text files (such as AGENTS.md), reusable skill definitions, and MCP prompts, all placed uniformly under the .apc/ directory, so that any APC-compatible tool can directly read the same contract from a code checkout. In contrast, APX is the runtime that consumes this contract; it is responsible for mapping abstract project definitions to concrete processes: which Agents to load, which MCP servers to connect, which root guidance and persistent memory to inject, and writing conversations and task logs to local ~/.apx/. This division of "portable contract, privatized state" allows projects to flow between CI, IDEs, and chat clients without bringing sensitive runtime traces out of the local machine.

MCP (Model Context Protocol) is a protocol that establishes standardized connections between AI models and external tools and data sources. In the APC system, shared MCP prompts refer to instruction snippets distributed with the project that guide the model on how to call specific MCP servers. They sit alongside Agent definitions and skills as part of the project contract: when APX selects a project for a given turn of conversation, it uses that project's MCP prompts to decide which servers to connect and how to expose tools. In this way, the same set of MCP configurations can be reused by other tools along with the code checkout, without having to manually reconfigure them in each runtime.

When the Interface Is Clear Enough, Trust the Interface

The project chat or code session itself already carries useful scope information. If you open the storefront project and request a review of the checkout flow, APX can directly use that project—the work interface matches the project contract. This is the ideal state for sustained work: whichever project the task belongs to, stay in that project's interface; the conversation obtains Agents and guidance from the same project, and that project is exactly where the files will be touched.

But not all requests begin in a project interface. Users may be in a general chat, replying from a messaging channel, or returning to an old conversation after switching tasks. In this case, the goal needs to be clarified in natural language, for example:

For storefront, review the release checklist.

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

The project name is short but efficient context; it avoids relying on old topics that may no longer be relevant.

Beware of Conversation Inheritance Becoming Implicit Attribution

Leveraging a project mentioned earlier in the same conversation is helpful for follow-up questions. After discussing storefront, a question like "what should we test first?" can carry over the same scope without repeating the name every turn. But this convenience should not turn into hidden attribution. When the work content changes, switch deliberately:

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

Giving a new project name is more reliable than assuming the last active project is still correct. It provides an observable boundary for the next turn and also makes it easy for reviewers to explain why certain context appears. In multi-source analysis, community discussions have also repeatedly emphasized: if an Agent's "memory" lacks explicit boundaries, it is prone to semantic drift in long conversations, and explicit naming is the lowest-cost corrective measure.

Context drift refers to the phenomenon in which an Agent gradually deviates from the original task scope or project boundary during a long conversation. It is usually not caused by a single obvious error, but by a series of seemingly reasonable inheritances: the model treats the previous turn's project name, expert role, or local history as a default premise, amplifying it turn by turn, and ultimately giving a reply that "sounds plausible but is misattributed" without the user noticing. In development scenarios with multiple projects in parallel and frequent task switching, drift is especially insidious, because the error does not trigger an error message; it only manifests as recommending a mismatched expert or referencing irrelevant rules. The reason explicit project naming is regarded as the lowest-cost corrective measure is that it provides an observable, reviewable boundary signal in every turn, so the model does not need to rely on implicit guesses about the conversation history.

Align Chat Scope with Command Scope

Terminal commands face the same problem, just in a different form. When the current directory is not a reliable signal, you can pin the project:

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

Message-level naming and the command-level --project flag serve the same idea: declare the expected attribution at key points. Neither copies project rules into runtime history, nor makes private session data portable—they are only responsible for selecting the correct boundary.

A Small Habit to Avoid Silent Errors

To summarize into actionable daily habits: use the project interface for sustained project work; proactively name the project when scope is involved in general conversations; repeat the project name when the topic changes; and pin the project with commands when the shell location is merely incidental. APC keeps the project contract portable, APX makes the contract take effect turn by turn, and naming the project is the small bridge between the two—it is more trustworthy than guessing based on "what the conversation last talked about."

According to feedback from some developer communities, this kind of explicit boundary habit is especially effective in multi-person collaboration and cross-project switching scenarios, and can significantly reduce the probability of an Agent misusing project context. Although current discussions are still mostly from a single source, the design idea of per-turn project selection provides a direction worth learning from for context management in Agent toolchains.

One-line Summary

APX turns AI Agent project selection into an explicit per-turn decision, preventing silent context drift.

Paragraph Summary

The article discusses an overlooked fundamental issue in AI Agents: which project each turn of conversation actually belongs to. APX's solution is to make project selection a per-turn decision, following the principle of "when the project matters, name it before the conversation drifts." The article distinguishes the layers of APC and APX: APC carries portable context (AGENTS.md, Agent definitions, skills, MCP prompts, and .apc/ metadata), while APX as the runtime uses it to determine the Agents, MCP servers, root guidance, and persistent memory for the current turn, with private state kept locally in ~/.apx/. Project selection is therefore a boundary connecting the portable contract and private runtime state, not a decorative label. The article gives a priority order: the current interface project first, then a project explicitly named in the message, then a project mentioned earlier in the conversation; and reminds that conversation inheritance should not become implicit attribution—when the work changes, switch explicitly. Terminal commands align with chat naming through the --project flag. Finally, it distills this into actionable habits: use the project interface for project work, proactively name the project in general conversations, repeat the name when the topic changes, and pin the project when the shell location is incidental.