Agentic AI

Agent APIs Are Becoming Runtime Contracts

12 min read
A small doorway being redrawn as a wide arch enclosing a gear, a ledger, and a lock, showing an agent API widening into a runtime contract.

For the last year, if you were building anything serious with agents, you spent most of your time building everything that was not the model. You wrapped model calls in queues. You wrote a tool router. You added a sandbox, budget caps, an approval step, a memory store, and a trace viewer, because without them the agent was a demo, not a system. The model reasoned. The runtime you built around it decided whether the work could be trusted.

So when the newest wave of agent-platform releases lands, the reasonable instinct is to read it as a model race. Which model scores higher, which is cheaper, which reasons longer. I have reached for that lens too. It is the wrong altitude by one layer.

Read the releases as an API-boundary shift instead, and they line up. OpenAI's GPT-5.6, Google's Gemini Managed Agents, and LangSmith's coding-agent tooling are not competing on the same axis. They are all pulling the same layer into the platform: the runtime you have been assembling by hand. The primitives that used to live in your application code, your workflow engine, your observability stack, and your cost dashboard are moving down into the API itself.

This is the next turn of something I have written about before. First the model was the product. Then, as I argued in the agent is the runtime, not the model, the differentiator moved to the runtime around it, and in the harness is the control plane, that runtime turned out to be where governance actually lives. The new part is where the boundary now sits. The runtime is becoming part of the vendor's API surface.

The agent API is no longer a model invocation. It is becoming a runtime contract.

A useful way to see the change is to picture what the API used to be. It was a vending machine. You put in a prompt, you got out text, and everything else was your problem. What is arriving is closer to a work order for a general contractor. It has to state what the worker may touch, how the work is coordinated, what gets kept on the record, what it costs, and how it stops. That is a contract, and a contract decides far more than a benchmark does.

The old contract was too small

The first generation of LLM APIs had a clean shape. Send input, receive output, maybe call a tool, and keep the application responsible for everything else. That shape was enough for chat, summarization, extraction, and simple tool use.

It breaks for agents, because an agentic task is not one request and one response. It is a trajectory. The work may inspect files, call APIs, branch across independent subtasks, run code, process large intermediate outputs, wait in the background, recover from a dropped connection, ask for a client-side action, and leave enough of a record for a human to audit what happened. If the API only returns text, the application has to rebuild a runtime around it to hold all of that.

That rebuilt layer is not incidental. It is where the real engineering has been going: orchestration and retries, state and permissions, sandboxing, traces, budgets, approval gates, and rollback paths. Most serious agent builders, myself included, learned the same lesson the slow way. The model may reason well, but the runtime determines whether the work is controlled.

The platform vendors are now absorbing that layer. Custom runtimes do not disappear. The default contract just gets wider, and the line between what the API owns and what you own moves.

OpenAI is pulling orchestration into the request

The clearest signal is Programmatic Tool Calling, where the model writes a short program to coordinate several tool calls itself instead of bouncing every step back through the model. In the GPT-5.6 family, which shipped in July as three sizes named Sol, Terra, and Luna, the model can write JavaScript that calls tools in parallel, keeps intermediate results, and returns a smaller structured answer.

The interesting part is not that the model runs code. It is how tightly the code is bounded. OpenAI runs each generated program in a fresh, isolated V8 runtime, the same JavaScript engine that runs in Chrome. It has no Node.js, no package installation, no direct network access, no subprocess execution, and no persistent state between runs. Your application still decides whether Programmatic Tool Calling is available at all, and which tools the program may call. Client-owned tools stay client-owned. The guidance is careful about when to use it: reach for it when a stage has predictable control flow and code can reduce several tool results into something smaller, and keep it away from work that needs fresh model judgment, an approval, or a citation.

That is a runtime contract written down. It says predictable control flow can move into code, expensive intermediate data does not need to pass through the model at every step, tool eligibility stays under your control, and the execution surface is isolated and ephemeral.

The multi-agent beta moves a second orchestration primitive into the API. A root model can coordinate subagents, the child agents it spawns, running them in parallel and synthesizing their results in a single request. The point is not that agents can call agents. It is that delegation, parallelism, waiting, and synthesis are becoming API-level primitives rather than things you hand-roll in a loop.

Capability moved down a layer. Responsibility moved with it. The more orchestration the platform owns, the more you need clarity on its failure modes, isolation, limits, and cost attribution before you depend on it.

Gemini is turning managed agents into remote workers

Google's Gemini Managed Agents point the same way from a different side. The July 7 update adds background execution, remote MCP server support, custom functions, and credential refresh across a long-running interaction. MCP here is the Model Context Protocol, the emerging standard for exposing tools and data to agents. One endpoint now gives an agent reasoning, code execution, package installation, file management, web access, and an isolated cloud sandbox.

That is not a chat API. That is a hosted worker.

Background execution is the tell. Long work should not depend on an HTTP connection staying open, so the caller can set background: true, get back an interaction ID, and then poll, stream progress, or reconnect later. A background job moves through states like in progress and completed, and a custom function can move an interaction into requires action. Those states are the vocabulary of a job system, not a chat exchange.

Remote MCP support moves the tool boundary into the managed environment. Instead of writing middleware for every internal database, a team connects the agent to remote MCP servers, tools hosted elsewhere that the agent can reach, and adds custom functions alongside the built-in sandbox tools.

If that sounds familiar, it is because it is the same set of habits serious operators already learned locally. Long work needs an ID. Interrupted streams need reconnection. Credentials need rotation and refresh. The difference is only where the boundary sits. The application used to wrap the model in these concerns. Now the API exposes them directly.

That helps, because fewer teams have to reinvent job control and sandbox lifecycle. It also creates a sharper dependency. If the managed runtime owns package installation, file state, web access, and remote tools, its contract has to be clear about what is persisted, what is ephemeral, what is logged, what is billable, what can be replayed, and what can be revoked. Without that, a managed agent is convenient and opaque, and opaque runtimes are exactly where production adoption stalls.

LangSmith is chasing the operational residue

OpenAI and Google are pulling execution into their APIs. LangSmith is chasing what happens after a team runs more than one agent surface at once.

The problem it names is concrete. A single feature might pass through Claude Code, Cursor, Copilot Chat, Codex, OpenCode, and a custom agent, each emitting activity differently. A manager who asks what a workflow cost gets partial answers from several dashboards. That is not only a finance nuisance. Scattered cost means weak governance, and scattered traces mean weak debugging. When subagent activity is not normalized, you cannot tell whether the expensive part of a run was useful work, redundant retrieval, a failed shell command, or an unnecessary jump to a bigger model.

LangSmith's answer, in its July coding-agent work, is to pull sessions from those tools into one trace model, normalized so you can query across agents with the same fields, capturing model calls with token cost, tool calls and shell commands, MCP activity, subagent invocations, errors, and timing. The companion gateway work adds the control half: budgets by organization, workspace, user, and key, with spend tied back to the traces.

This is the missing half of the runtime contract. Execution without evidence is not production architecture. Cost without attribution is not governance. Coding agents are a useful forcing function here precisely because they leave a mess in shared systems. They run shell commands, spawn subagents, burn tokens fast, and touch repositories, tickets, and CI. You cannot evaluate that work by its final answer. You need the trajectory.

The new contract has five parts

Put the three together and the emerging contract has a recognizable shape. Five parts, each of which used to live in your code.

Orchestration. Can the platform express parallel work, loops, background jobs, waiting, reconnection, and cancellation without forcing you to rebuild a workflow engine? This is what Programmatic Tool Calling and Gemini's background execution are really about. The question is no longer whether the model can call a tool. It is whether the system can run the work under bounded control flow and keep the job boundary intact.

State. What state exists, where does it live, and what survives between steps? A fresh V8 runtime with no persistence is one contract. A managed sandbox that keeps files, installed packages, and cloned repositories across a credential refresh is another. A background job you rejoin by its interaction ID is a third. State is not an implementation detail here. State is the reliability contract.

Authority. Which tools can the agent touch, under what identity, and with what approval boundary? Remote MCP servers, client-owned tools, hosted tools, and shell access all need different authority models. The failure mode to fear is ambient authority, where the agent can reach more than the task requires because the runtime boundary was drawn too wide.

Evidence. Can the system reconstruct what happened, not just the final output but the trajectory: model calls, tool calls, shell commands, subagent invocations, errors, retries, approvals, and cancelled work? In agent systems, traces are not a debugging extra. They are the operational record.

Cost. Can spend be attributed to work rather than reported by provider? Cost per task, per user, per subagent, per tool path, per failed trajectory. A team that cannot say where the money went cannot tune the runtime, and a team that cannot cap or route spend cannot scale adoption responsibly.

What this changes for builders

The practical mistake is to evaluate agent platforms as if they were model endpoints with nicer tool calling. That frame is too small. The evaluation should start from the runtime contract, and the questions are engineering questions, not a procurement checklist. What orchestration does the API own, and what stays in my application? What execution state is persisted, and can I inspect or delete it? Which tools run in the hosted environment, and which must stay client-side? Where are approvals enforced, and what happens when a background job stalls or needs a client action? Are the traces complete enough to debug a trajectory-level failure? Is cost attached to sessions, subagents, and users? Can policy be enforced before execution rather than reconstructed afterward?

Model choice still matters. It moves quality, latency, and cost. But the decisions that last sit around the model, not in it: who owns orchestration, memory, tool policy, evidence, cost control, and recovery. That is the platform boundary, and it is where the cost of agent work becomes a scheduling problem rather than a per-token line item. The more agent capability moves into APIs, the more the API becomes a distributed-systems boundary, with job semantics, state semantics, identity semantics, and cost semantics all at once.

The runtime is the product boundary

The industry keeps rediscovering the same lesson in different forms. First the model was the product. Then the harness became the product. Now the API itself is becoming the harness. OpenAI is making programmatic orchestration and multi-agent delegation part of the request. Google is making managed agents look like remote workers with job control, remote tools, custom functions, and sandbox state. LangSmith is making cross-agent traces and cost governance the control surface around the work.

The agent is no longer a smarter autocomplete box. It is a worker operating under a contract, and that contract has to say what the worker can do, how it coordinates, what it remembers, what it touches, what it costs, what it proves, and how it stops. Teams that treat this as a prompt problem will keep building fragile demos. Teams that treat it as runtime architecture will build systems people can trust.

The model answers. The runtime commits.

Sources

The features and vendor claims here are reported by the vendors cited, not independently verified. Read them as directional.