Draft RFC
Field Manual · Agent Operations July 2026
Edition v0.3

The API Field Guide

A pocket reference for the field (if your agent had pockets). It shows an AI agent how to work an API it has never seen before, safely and to completion.

# the artifact, published at the API's /.well-known location
api-agent.yaml

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.

Think of it as the Ocean's Eleven briefing for your agent. Before anyone touched the vault, they knew the layout, the guards, the alarms, and the way out.

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:

A typical field guide runs 300 to 1,500 tokens, less than a single failed call-and-retry cycle costs an agent. Every section is optional. A quarter-filled file is a normal file, and agents read only the sections the task at hand requires.

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.

One agent's failure becomes every agent's knowledge. Agents stop being passive consumers of stale docs and become the sensing layer that keeps the contract true.

How it fits with what exists

The Field Guide is additive by design. Every section references a source of truth rather than duplicating it.

SpecCoversThe Field Guide adds
OpenAPIEndpoint shapes, schemas, security schemesOperational wisdom, failure taxonomy, human gates, lifecycle
ArazzoDesigned workflow sequencesFailures you discovered in production, not just the ones you planned for
auth.mdHow an agent registers & gets credentialsHow a credentialed agent operates safely, with scopes per operation and auth-failure recovery
MCPTool advertisement to agentsThe API-side contract, from API to agent
security.txtVulnerability disclosureA runtime channel for reporting operational contract failures
AsyncAPIEvent-driven interface shapesLatency, consistency lag, pagination, polling cadence: behavior no schema captures
agents.jsonFlows & links over OpenAPIWhen not to call, and what to do when calls fail
AP2 / x402Signed payment mandates; per-call HTTP 402 paymentshumanGates 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.

The API Field Guide helps agents finish the job safely, and successfully.