Every AI coding agent wants project context. Claude Code, Codex, Cursor, OpenCode, Windsurf, and similar agentic development tools all need the same basic facts: how the repository is structured, which commands matter, what rules should be followed, which agents exist, and which project knowledge should survive beyond one chat.

The problem is not that tools want context. The problem is that each tool tends to invent its own branded home for it.

The infographic behind this post shows the core APC thesis in one picture: project meaning should not be trapped in .claude/, .cursor/, .codex/, or any other vendor-specific folder. It should have one neutral name: .apc/.

The concrete thesis

APC is not another prompt dump. APC is a filesystem convention for durable, project-owned agent context. APX is the local runtime/tooling layer that makes that context useful in daily work while keeping runtime state outside the repository.

That split matters.

A repository should be able to say: "these are the agents, rules, skills, MCP hints, and curated memories that belong to this project." Any compatible agent runtime should be able to read that without asking the team to duplicate the same meaning into five different folders.

At the same time, a repository should not contain raw sessions, private transcripts, local caches, or secrets. Those belong to the runtime.

From branded silos to a shared standard

Without a shared convention, teams end up with parallel context trees:

.claude/
.cursor/
.codex/
.opencode/
.windsurf/

Each folder may contain useful instructions. But when the same repository rule is copied into multiple tool-specific locations, the real source of truth becomes unclear.

Did the team update Claude but forget Cursor? Did Codex read the newer rule or the stale one? Are MCP expectations documented once, or scattered through local config files?

APC turns that into a simpler model:

AGENTS.md        # root project contract
.apc/            # structured project context

AGENTS.md gives compatible tools a broad root contract: repository rules, stack notes, commands, and guidance. .apc/ carries structured project context: project metadata, agent definitions, reusable skills, rules, durable plans, and MCP hints that are safe to share.

The project/runtime boundary

The right side of the infographic shows the most important design constraint: APC is for durable project meaning, not runtime state.

Commit this kind of information:

.apc/project.json
.apc/agents/<slug>.md
.apc/skills/
.apc/rules/
.apc/plans/
.apc/mcps.json   # no secrets

Keep this outside APC:

raw sessions
conversation transcripts
local caches
private memory
API keys and credentials

APX follows that boundary. A project is identified by AGENTS.md plus .apc/project.json, while APX stores runtime data under ~/.apx/projects/<id>/. That lets the project definition travel with the repository, while local execution history stays on the machine where it belongs.

Why the neutral name matters

Names shape behavior. If project context lives under .claude/, people treat it as Claude-specific. If it lives under .cursor/, people treat it as editor-specific. If every runtime owns its own folder, teams keep maintaining the same project contract many times.

.apc/ says something different: this context belongs to the project.

That means a future-compatible runtime can consume APC directly, project it into its own internal format, or use APX as a reference runtime today. The goal is not to delete every tool folder immediately. The goal is to stop making vendor folders the only source of truth for shared project meaning.

Practical rule

When deciding where a file belongs, ask one question:

Would this still be useful if I switched from one AI coding agent to another?

If yes, it probably belongs in AGENTS.md or .apc/.

If no, it probably belongs in runtime storage such as ~/.apx/, ~/.codex/, .cursor local state, or another tool-owned location.

APC gives the project one context and one name. APX keeps the daily runtime work local, private, and operational.