Documentation
Make documentation legible to agents.
Documentation is not only an explanation for a person. It is part of the working context an agent uses to decide what to do next.
An agent needs more than a catalogue of endpoints or features. It needs enough context to choose the right path: what a capability is for, what it needs, what it returns, what can go wrong, and when another route is better.
Write for the decision
Begin with the job the capability helps complete. Name the situation in which it is useful, the conditions that make it a poor fit, and the outcome a successful use should produce. That is often more useful than mirroring the shape of an internal implementation.
Keep important context close
Split documentation makes a workflow harder to assemble. Place the constraints, required inputs, related tools, and common failure modes near the action they affect. A person can infer missing connections from experience; an agent may not have the same context.
Show the route back
A complete guide includes what happens when an input is missing, a request is ambiguous, or a step needs approval. Recovery is not an edge case when an agent is working across real product boundaries.
Review it as part of the product
When the product changes, revisit the language around it. Old names, stale examples, and overlapping descriptions create the same kind of friction as a broken interface.
The question is simple: does the documentation help an agent make the next decision with less guesswork?