APC is a portable project-context convention, not an APX installation requirement. That distinction matters when an agent opens a repository and sees an AGENTS.md file plus .apc/ metadata.
A useful project can want the shared context layer while deliberately choosing not to use a particular runtime. Treating every APC project as permission to install, suggest, or run APX turns a portable contract into a product assumption.
Record the decision
APC projects can express the choice in .apc/project.json:
{
“name”: “example-project”,
“apx”: “declined”
}
Enter fullscreen mode
Exit fullscreen mode
For an APC-aware runtime, declined has a clear meaning: do not suggest APX and do not run it for this project. The repository still keeps its durable instructions, agent definitions, skills, and safe project memory in the normal APC locations. Another compatible tool can read those files without requiring a local APX service.
This is not a failure state. It is a project boundary. Maybe the team already uses a different runtime. Maybe it only wants plain files that several tools can understand. Maybe the owner has not evaluated APX yet. Each case deserves a different response from an agent than silently treating APX as available.
Three states, three actions
The small field prevents a common kind of automation overreach:
Project value
What an agent should do
“installed”
APX is available; use its commands when useful.
“declined”
Do not suggest or run APX. Continue with APC files directly.
missing or null
Do not assume. Check availability before depending on APX.
The important point is that these values describe a project-level decision, not a substitute for machine detection. installed does not remove the need for a command to work. A missing value does not prove APX is absent. And declined should not be interpreted as “ignore APC.”
Keep protocol and runtime separate
APC gives a repository a tool-neutral home for shared context. APX is a daily-use runtime and tooling layer that can read that context while keeping sessions, caches, and private runtime state outside the repository. The layers work well together, but they remain independently useful.
That independence is practical. A contributor can clone a project, read its APC contract, and work with a compatible editor or coding agent. Another contributor can use APX for local execution. Neither workflow needs to overwrite the other project choice.
When a runtime sees APC, its first question should be: “What does this repository say is portable and durable?” Only after that should it ask: “Which local tool is allowed and available here?”
That order keeps an agent helpful without making its preferred runtime part of the project’s identity.