Use model: inherit to Keep APC Agents Portable

A portable agent definition has a subtle design choice: should it name a model? My thesis is that model: inherit is the better default for an APC agent unless a particular model is genuinely part of the project's contract. It keeps the role portable while letting the runtime make an operational choice. APC is the repository-owned context layer: AGENTS.md and .apc/ describe what a contributor or agent needs to know about a project. APX is the daily-use runtime and tooling layer that reads that context and runs agents. The distinction matters here because a role is project knowledge, while a provider account and an available model can vary by machine. A role does not usually need a provider The APC agent specification recommends this frontmatter shape: --- name: reviewer model: inherit description: "Reviews behavior changes and migration risks." skills: release-checklist --- Check compatibility claims against tests and docs. Report concrete risks first. The durable part is the reviewer's responsibility. A teammate using another compatible tool should still understand that role. If this file instead hardcodes a vendor-specific model for convenience, every clone inherits an operational assumption that may not hold for that teammate. inherit is explicit, but it does not name a model. It says the agent definition makes no model override. A runtime can then apply its configured choice. This also makes review easier: a model value other than inherit signals an intentional project decision rather than a default copied from one person's workstation. What APX actually does APX's agent model resolution code treats inherit and an empty model field as no forced model. It resolves a per-call override first, then a model forced by the agent file, then the runtime's active model routing. The marker is not sent to an engine as a literal model ID. That gives a useful practical distinction: | Agent file | Meaning | |---|---| model: inherit | Keep the role; use the runtime's model choice. | model: provider:model-id | Make this agent request a specific model. | The example provider:model-id is a format illustration, not a ready-to-run model identifier. The runtime still needs a valid configured provider and model. inherit does not promise that any particular model is installed, healthy, or affordable; it simply leaves that selection outside the shared agent definition. Suppose a project defines a reviewer, and one contributor runs it with a local model while another uses a hosted provider. The review responsibility, skills, and project rules can travel with the repository. Each contributor's credentials and runtime defaults remain local. That is the portability APC aims for. When a forced model is justified A specific model can be part of the contract. Perhaps the agent is used to evaluate behavior against a named model, or a workflow depends on a model-specific capability and the team has agreed to maintain that requirement. In that case, state the reason near the agent definition and document what happens when the required model is unavailable. But “this was my current default” is weak evidence for forcing a model on everyone. It creates maintenance work whenever a provider renames a model or a teammate uses a different runtime. Review the decision as you would any other project constraint: can a new contributor satisfy it, and does the task require it? A small audit is enough. Read .apc/agents/*.md , identify every concrete model value, and ask why each one belongs in version control. Keep justified requirements. Change incidental choices to inherit , and configure the actual model in the runtime. The result is a stable role definition with a clear operational boundary. Explore the APC specification and examples. Top comments (0)