OpenAPI tells an agent what an API is. It was never meant to carry what engineers learned the hard way: the rules behind the call sequence, what a successful response actually means in this domain, which failures are safe to retry, when to stop and ask a human, and what to do when the API changes or shuts down.
That knowledge lives scattered across specs, SDK behavior, runbooks, incident retros, support tickets, and people's heads. api-agent.yaml is a structured, machine-readable file the API author publishes to pass it on.
The gap
What agents can lean on today
OpenAPI / GraphQL / gRPC / AsyncAPI: the interface shape: the operations, data, and events that exist.
Arazzo / agents.json: designed workflow sequences.
MCP: tools exposed to agents.
auth.md: how an agent registers and authenticates.
AP2 / x402: agent payments and per-call metering.
What's still missing
What must happen before a risky call?
Which errors are retryable? Which need a human?
How does an agent recover from partial failure?
What changed since last time, and what replaced a dead endpoint?
That missing layer is the operational contract, and it has no standard home today. The API Field Guide gives it one.
What it is
A companion file published alongside openapi.yaml. It does not replace OpenAPI, Arazzo, auth.md, or anything else. Instead it points to them through a refs block and adds the layer none of them cover. You can write it by hand, or generate most of it from tooling your team already uses.
The API Field Guide tells your agent:
- What to knowConceptual model, key insights, auth guidance, what the docs leave out.
- What to doPer-endpoint preconditions, scopes, compensation paths, human-approval thresholds.
- What changedVersion diffs, deprecation forwarding, sunset notices that point to a successor.
- What to sayA feedback channel, modeled on security.txt, so agents report problems back to the owner.
A glance at the file
Every line below is clickable. The field note beside the file explains what each line tells an agent and why it exists, which mirrors the spec's own philosophy: context arrives when the agent needs it, rather than all at once. Full schema in the spec.
Mobile users, tap a line to see its purpose.
# served from /.well-known/api-agent.yaml (click any line) model: auth: constraints: endpoints: "POST /orders/place": "POST /orders/queue": failures: global:
The self-healing loop
The sections above are not independent features. Together they form a closed loop between agents and API owners, and that loop is the reason the file exists.
- DetectAn agent hits behavior the contract did not predict: an undocumented error, a dead endpoint, a mismatched response.
- Re-fetchIt re-pulls the field guide with a conditional request (an unchanged file costs almost nothing), falling back to the canonical git copy if the API is dark.
- Compare
lifecycle.versionagainst the version it persisted last visit. - Adapt or reportVersion changed → migrate using breaking-change notes, replacements, or the successor contract. Unchanged → file a
stale_contractreport viafeedback. - RegenerateThe API owner feeds accumulated reports back through the generation pipeline and republishes.
- BenefitEvery subsequent agent gets the corrected contract.
How it fits with what exists
The Field Guide is additive by design. Every section references a source of truth rather than duplicating it.
| Spec | Covers | The Field Guide adds |
|---|---|---|
| OpenAPI | Endpoint shapes, schemas, security schemes | Operational wisdom, failure taxonomy, human gates, lifecycle |
| Arazzo | Designed workflow sequences | Failures you discovered in production, not just the ones you planned for |
| auth.md | How an agent registers & gets credentials | How a credentialed agent operates safely, with scopes per operation and auth-failure recovery |
| MCP | Tool advertisement to agents | The API-side contract, from API to agent |
| security.txt | Vulnerability disclosure | A runtime channel for reporting operational contract failures |
| AsyncAPI | Event-driven interface shapes | Latency, consistency lag, pagination, polling cadence: behavior no schema captures |
| agents.json | Flows & links over OpenAPI | When not to call, and what to do when calls fail |
| AP2 / x402 | Signed payment mandates; per-call HTTP 402 payments | humanGates declare when approval is needed; the failure taxonomy says what a 402 means on this API |
How an agent finds it
An agent that knows only the domain looks first at a predictable location, following the same convention as security.txt:
https://api.example.com/.well-known/api-agent.yaml
APIs serving multiple live versions may also publish one next to a versioned surface (/v2/api-agent.yaml). A canonical address inside the file points to a git-committed copy that survives deployment changes, deprecation, and full shutdown, so the path to a successor API outlives the live endpoint.
Built skeptical
The spec pairs its fields with a trust model. The file is advisory, API-authored, and untrusted by default: descriptive fields (semantics, gotchas, error meanings) are safe to reason over and checkable against observed behavior; imperative fields (run this command, adopt this successor) require human approval or out-of-band verification. Free text is treated as a prompt-injection surface, and field-guide text never outranks the human operating the agent.
And because compliance is cooperative, the spec requires what it cannot enforce: every limit that matters must also be enforced server-side or at a gateway. Declared limits protect cooperative agents from mistakes; servers protect the API from everyone else. Full text in the spec’s Security Considerations.
Why it matters
The future is not a smarter agent guessing its way through a passive API. It is an API that briefs the agent before the first call: how to authenticate and what to call, what not to do, how to recover, and when to escalate. It says what changed since last time, and it gives the agent a way to report back when reality doesn't match the contract.
OpenAPI
helps agents call an API.
auth.md
helps agents get access.