Corey James- 83generated operations, kept internal
- 36designed tools agents see
- A dozensemantic rules every manifest is checked against
A specification checked against behaviour
In FAFO Core and Function Forge I built a platform that puts third-party APIs behind agent tools, and the first thing I decided was that an API's specification is a claim about the API. An OpenAPI 3.x document, or a hand-written seed for an API without one, is converted deterministically into a schema-checked manifest: operations, parameters, authentication and response shapes in one canonical format, checked against semantic rules. The platform's test catalogs include negative cases, so the gate itself is tested.
The delivery is told in Closed by evidence.
Tools drawn around an agent's decisions
In FAFOHive the same document pulled me the other way. I wanted agents on the X data API, and generating one tool per endpoint from the vendor's OpenAPI file took an afternoon. I did not give them to agents. Agents choose badly among dozens of small billed calls, and what makes the API cheap and safe, batching identifiers before fetching, reusing cached results, refusing stale data, lives between endpoints. So I draw tool boundaries around the decision an agent makes, and on top of the generated layer I designed tools shaped like the jobs an agent does, such as finding fresh conversations on a topic.
One operation per endpoint, held as a typed layer with each operation's safety class, unit cost, pagination and credential fields.
- Shaped like a job, such as fresh conversations on a topicone call
- States its cost formula, returns its actual costevery tool
- Read and act surfaces, authorised separatelytwo surfaces
I know what an OpenAPI document is good for: a typed client and a starting manifest.
An OpenAPI document is a poor design for an agent's tools and no proof of what an API does.