AI Agent API: What Persists After the Request Ends
"AI agent API" means two opposite things, and the SERP serves both without noticing. Here is the precise definition, the four vendor approaches compared, and the design decision nobody covers: what actually survives after the request returns.
Every endpoint, parameter, and policy below was checked against vendor documentation on 27 August 2026. Check the linked docs before you commit.
Key takeaways
- An AI agent API accepts a goal and runs a multi-step loop on your behalf, handling reasoning, tool calls, and execution, instead of returning a single completion.
- The phrase carries two opposite meanings in the wild: an API that is an agent, and the APIs an agent calls. This article uses the first.
- Providers broadly agree on the request shape and disagree sharply on state. Mistral persists conversations, Google points you at third-party frameworks, Perplexity exposes it as two response fields.
- Retention and expiry go undocumented on most agent surfaces. OpenAI is the exception, and its default is 30 days.
- "Stateful" in agent-API marketing usually describes where the vendor keeps your data, not whether your system remembers anything.
What is an AI agent API?
An AI agent API accepts a goal and runs a loop against it. The model reasons, calls tools, reads the results, decides whether it is done, and repeats. You get back the outcome of several steps rather than the next message in a conversation. That loop, running on the provider's infrastructure instead of yours, is the whole category.
The term is doing double duty on the open web, and no page ranking for it says so. Sorting that out first is worth thirty seconds.
| Sense of "AI agent API" | What it means | Who uses it this way | | --- | --- | --- | | An API that is an agent | You send a goal to a provider endpoint. The provider runs the reasoning loop, executes tools, and returns results. | Mistral, Google, Perplexity, OpenAI | | The APIs an agent calls | The integration surface your agent reaches through to read records and take action in other systems. | MuleSoft, Composio |
MuleSoft, currently the definitional authority Google leans on for this keyword, describes it as a type of API that lets AI agents communicate with other software and platforms. Composio's January 2026 guide frames it the same way: "APIs give your AI agent a way to perceive data from external systems and act on it." Both describe the second sense. Both are reasonable. Neither is what Mistral, Google, Perplexity, or OpenAI shipped.
This article uses the first sense throughout. If you want the upstream definition of the thing doing the calling, start with what an AI agent is.
What does an agent API add over chat completions?
Four things, roughly in order of how much work they save you.
Built-in tools. Perplexity's Agent API ships web_search, fetch_url, and finance_search behind a single bearer-authenticated call to POST https://api.perplexity.ai/v1/agent, with an OpenAI-compatible alias at POST /v1/responses. Mistral describes built-in connectors for code execution, image generation, document library search, and web search, plus MCP tools.
An execution environment. Google's managed agents provision a Linux workspace on a single API request, isolated at the OS level, where the agent runs programs, handles files, and browses. Mistral runs Python in a sandbox for calculation and analysis.
Multi-step orchestration and handoffs. Mistral's agents can be added to or removed from a conversation, and tasks delegated between specialized agents through configured handoffs.
Persisted conversation, sometimes. This is the one that varies, and the one worth the rest of this article.
Chat completions endpoints are not going away. A single-turn classification or extraction call is cheaper, faster, and easier to reason about through a completions endpoint than through a full agent loop. The agent surface earns its place when the work genuinely branches.
Why this matters now
Every major provider shipped an agent surface within about fifteen months of each other, and they diverged on architecture while converging on vocabulary. Google's page was last updated on 18 August 2026. Mistral's remains a May 2025 announcement. Teams are picking between them on request ergonomics and latency, which are the two properties easiest to swap later, while the property that is hardest to swap later goes unexamined.
Four concepts to get right
State and persistence
Ask four questions of any agent API. Who holds the conversation history. For how long. Can you query or export it. Is there a record an auditor would accept.
The answers are inconsistent enough to be worth a table.
| Provider / API | State model | Retention or expiry documented? | Can you query or export it? | Source | | --- | --- | --- | --- | --- | | Mistral Agents API | Server-side conversations. The announcement advertises "Persistent memory across conversations" and says "Each conversation retains its context." | Not documented | Not documented. A Conversations API appears in the docs marked beta, without operations detailed. | mistral.ai/news/agents-api | | Gemini managed agents | No native conversation state. A hosted Linux workspace holds files between calls. For multi-turn and multi-agent state, the docs point to LangChain/LangGraph and the Google ADK. | Partly. Environments are deleted after seven days of inactivity. Nothing documented for conversation state, because there is none to document. | Files persist in the workspace the agent controls. Conversation state exists only if your framework stores it, in which case you own it. | ai.google.dev/gemini-api/docs/agents | | Perplexity Agent API | Two response fields, previous_response_id and store. The quickstart shows them in a response body without prose definitions or a multi-turn example. | Not documented | Not documented | docs.perplexity.ai/docs/agent-api/quickstart | | OpenAI Responses API | store controls whether a response is retained, previous_response_id chains turns into a threaded conversation, and Conversation objects hold messages, tool calls, and outputs under a durable identifier. | Yes. "Response objects are saved for 30 days by default." Conversation records are described as exempt from that limit. | Responses are retrievable through the API and visible in dashboard logs. | developers.openai.com conversation state guide |
Two findings deserve to be stated plainly and neutrally. Mistral advertises persistent memory in an announcement that publishes no retention window, no expiry rule, and no export path. Google's managed agents hold no conversation state at all and point you at LangGraph and the ADK, which is honest and also means the memory problem is still yours.
Here is the position that follows. "Stateful" in agent-API marketing almost always means the vendor is holding your state, not that your system has become stateful. A conversation you cannot query on a field you care about, cannot export on a schedule, and cannot show an auditor with attribution is a context window on a longer lease. It is genuinely useful for a session. It is not a system of record, and treating it as one is how teams discover in month eight that the history of what their agent did lives somewhere they cannot reach. This is the same boundary that separates trace collection from real observability for agents.
Tool access and permissions
The agent acts under some credential. Which one, and scoped how far, is the question your security team will ask first.
Google documents the most interesting answer here and gets the least attention for it. Credentials can be supplied through "egress proxy header transformations," so they are never exposed inside the workspace itself. The same page also documents that outbound network access is unrestricted initially, with domain allowlisting available, and warns that any credential you supply may be usable by the agent. Both facts are in the vendor's own security guidance. Neither is a scandal. Both change your default posture, and the second one in particular means an agent workspace on a default configuration can reach anything on the public internet.
Scoped credentials, short-lived tokens, and rotation are the baseline. See control at the point of action for why the enforcement point matters more than the policy document.
Execution environment
Google's documentation calls its managed agents "a configurable agent harness," and what that buys you is a Linux workspace with OS-level isolation, where the agent runs code and manages files across calls, with idle environments pausing and resuming on a later request. Mistral's is narrower, a Python sandbox for calculation, analysis, and plotting. The difference matters for anything that produces artifacts. A file written in a sandbox that expires is a result you did not keep.
Orchestration and handoffs
Mistral describes agents being added to or removed from a conversation, with tasks delegated between them through handoffs. That is real multi-agent structure inside the provider's loop. The tradeoff is that the topology lives in the provider's configuration rather than in code you version and review. For a deeper treatment, see orchestrating models and the app layer.
Comparing the managed agent APIs
No winner, because the right pick depends on what you are keeping.
Perplexity's surface is the fastest to first call and the most opinionated about search. Google's is the most capable execution environment and the most explicit about its own security defaults. Mistral's has the most developed multi-agent story and the least documented durability. OpenAI's Responses API is the only one of the four that publishes a retention number you can put in a policy document.
Managed agent APIs are the fastest path to a working agent, and provider-held state is a sound choice for short-lived interactive sessions. Self-managing state is real engineering work that nobody should take on for a support chat widget. The calculus changes when the work has consequences someone will ask about later, which is also where the move from prototype to production stops being a deployment step and starts being a design one.
Common misconceptions
That "stateful" means your system is stateful. It usually means the provider stores something for an unspecified period under terms you did not negotiate.
That an agent API removes the need for your own data model. It moves the loop, not the records. If the outcome of the agent's work matters to your business next quarter, it belongs in a schema you designed.
That a bigger context window substitutes for persistence. A context window is not queryable, not attributable, and not durable. It is the working memory of one run.
That an agent API removes the need for a framework. Google's own documentation points to LangGraph and the ADK for stateful and multi-agent work, so choosing a framework layer remains a live decision even on a managed surface.
That the two senses of "AI agent API" are the same thing. They describe opposite directions of a call. Mixing them is how procurement conversations go sideways.
What we're building at Major in response
The interesting question about an agent API is not the shape of the request. It is what survives the response. Most agent APIs answer with a conversation object on the vendor's side, which is useful for a session and thin as a record. A team that needs to know what an agent did last Tuesday, on which account, under whose credentials, cannot get that from a conversation store with undocumented retention.
Major's answer is to put the durable state in software the organization owns. When an agent works out how to handle a repeatable piece of work, it builds an app for that part, and the app carries a managed database, file storage, and its own logs. Results and history persist as queryable data with an audit trail rather than as provider-side conversation entries. Because the repeatable work then runs as deterministic code instead of a fresh round of reasoning, one move produces two properties: the work executes the same way every time, and it remembers. The model still gets called, for the judgment that needs judgment, just far less often, so cost is front-loaded and then flat rather than climbing with every request. And because that work lives in permissioned, audited code, governance applies where the agent acts.
This argument does not settle agent evaluation, which is a harder and separate problem, and it does not claim the model disappears. It claims that an agent which forgets is an agent you pay to re-reason. Reason once, run forever.
If you are weighing an agent API and the retention question is the one you cannot get answered, it is worth seeing how Major's agents keep results and history in an app with its own database and audit log: see how state persists in software you own.
Related articles
Frequently asked questions
- What is an AI agent API?
- An AI agent API is an interface that runs an agent loop on the provider's side: you send a goal, and the provider handles the reasoning, the tool calls, and the multi-step execution, returning an outcome rather than the next message. It differs from a chat completions endpoint, which returns one completion for one prompt and leaves the looping to your code. The term is also used loosely for the APIs an agent calls. Every run still passes through the model, and that is the cost and the variance you inherit. Major takes the other path, where an agent reasons once to produce a deployed app and the repeatable part of the work then runs as code.
- What is the difference between an AI agent API and a chat completions API?
- A completions API returns one response for one prompt, and any looping is your code's job. An agent API runs the loop on the provider's side, usually with built-in tools and an execution environment attached, and often with the conversation persisted server-side. Completions endpoints remain the better choice for single-turn extraction or classification work. Both bill per run, because both re-derive the same procedure every time. An agent on Major calls those APIs while it builds the app, and the finished app then serves the requests that used to be prompts.
- Are AI agent APIs stateful?
- Some are, and the state they keep belongs to the provider rather than to you. Mistral persists conversations server-side without publishing a retention or expiry policy. Google's managed agents hold no native conversation state and point developers to LangGraph and the ADK. Perplexity exposes it as previous_response_id and store, and OpenAI saves response objects for 30 days by default. None of that is a record your systems can query, join, or audit. On Major, state lives in a managed database inside the app the agent builds, so it outlives the run and stays yours.
- How do I give an AI agent access to my internal APIs?
- Through tool or function definitions, an MCP server, or a unified integration layer that fronts several systems. The mechanism matters less than the credential behind it. Give the agent a scoped, short-lived token bound to the specific operations it needs, rotate it, and log every call made under it. Google's own guidance recommends minimal-privilege credentials and short-lived tokens for exactly this reason. Major runs that half through a credential proxy, so the agent reaches the system without ever holding the secret and each action is recorded at the point it happens.
- Do I need an agent framework if I use an agent API?
- Not for a single-loop task with a clear finish line, since the managed surface already covers it. You need a framework once you have durable state across runs, branching control flow, or several agents coordinating. Google's managed agents documentation points developers to LangChain, LangGraph, and the ADK for stateful and multi-agent workflows. Major answers the same problem differently and is not always the right call: it suits work that repeats under stable rules, and a framework remains the better fit while those rules still change week to week.