Agents with tools that are already a real backend.
An agent is a model that calls your interfaces as tools, in a loop, until it has an answer. In Air Pipe that is one action — with memory, a bounded loop, and an answer whose shape the provider enforces. The tools it calls are the same routes your apps call, with the same auth, the same validation and the same traces.
One action, not a framework
The agent action takes a model endpoint, a list of tools and an input. tools: names interfaces in the same config, so there is no adapter layer, no tool registry to maintain and no separate service to deploy alongside the API. The loop runs inside the request that started it.
tools: references interfaces in the same config
Tool input schemas are derived from the assert tests those interfaces already carry
No second copy of the schema to keep in step with the route
Any provider that speaks the OpenAI shape
Which is, in practice, all of them. The url is yours to point: OpenAI, Gemini's compatible endpoint, Anthropic, OpenRouter, Groq, DeepSeek, Mistral, Azure, or a model you host yourself with Ollama. Changing provider is changing a URL and a model name, not rewriting the agent.
Swap provider without touching the tools or the flow around them
Self-hosted models work the same way — nothing has to leave your network
Keys live in managed variables or secrets, never in the config text
It remembers, and it can borrow tools
An agent forgets between requests unless you tell it not to. memory: takes a key that scopes the conversation — one per user, per session, per ticket — and a window that bounds how many turns are replayed, so a long-running thread cannot grow without limit. Separately, mcp: draws tools from a remote MCP server in addition to your own interfaces: they are discovered at run time, so the model is offered whatever that server publishes today rather than whatever it published when you wrote the config.
memory.key scopes a conversation; memory.window bounds the replay
mcp: adds tools from a remote server alongside your own interfaces
A remote tool whose name collides with one of yours is refused, never silently shadowed
max_iterations caps the model round trips — default 4, ceiling 12, and hitting the budget is reported rather than silent
A shape the model cannot break
A model asked for JSON in a prompt will usually return JSON. schema: removes the "usually": the schema is sent to the provider, which enforces it, so content holds a parsed object rather than a string. There is nothing to validate afterwards and nothing to retry. If an endpoint ignores the field, the action fails and names the likely cause rather than passing prose on to whatever runs next.
The part most agent stacks leave to you
An agent that can act needs auth in front of it, a schedule or a webhook to start it, a database behind it, a human in the loop for the risky step, and traces when it does something surprising. Those are not add-ons here — they are the same config the agent lives in, and every tool call produces an OpenTelemetry span and Prometheus metrics without instrumentation code.
JWT verification and network access control guard agent-callable routes
Cron, webhooks and durable jobs start and resume the work
Human approval steps for anything you would not let a model do unattended
Traces, metrics and OpenAPI docs generated from the same config
Frequently asked questions
Is this an agent framework like LangGraph or CrewAI? It is a single-agent runtime rather than an orchestration framework. One agent gets a model, tools, memory, a bounded loop and an enforced output shape — which is most of what a working agent needs. What it does not do is orchestrate several agents handing work between each other. If you want that, keep your framework and give it Air Pipe tools over MCP; the difference is that here the agent, the tools it calls and the API in front of it are one deployable artifact rather than three.
How does the model know what my tools do? The tool signature is generated from the interface's own assert tests — the test vocabulary for types, patterns, ranges and formats maps to JSON Schema. Write clear assertions and the agent gets an accurate signature for free, one that cannot drift from what the route really validates.
Can I stop an agent from calling something destructive? Yes, in the ordinary way rather than a special one. A tool is an interface, so it carries whatever auth, access control and assertions you give it, and anything genuinely irreversible can sit behind a human approval step that the agent cannot skip.
What does a failed agent run look like afterwards? A trace, with a span for the agent action and a child span for each tool call it made, plus the run history for the deployment. You can see which tool it called, with what, and what came back — rather than inferring it from a transcript.