The Toolsystem Agent: Why AI That Operates Systems Needs a New Interaction Standard
Why a reasoning caller needs a new interaction model — and why I think that model is a category, not a feature.
I've spent most of a career building infrastructure for systems to talk to other systems — messaging fabrics, API gateways, the plumbing that lets one program reliably ask another to do something. So when AI agents started calling APIs, my first assumption was the comfortable one: this is the same problem we've always solved, just with a new client on the other end. Give the agent the tool definitions, handle the auth, let it call.
I no longer think that's true. I think there's an assumption buried so deep in the entire tool ecosystem that almost nobody states it out loud — and that the arrival of AI agents breaks it. This essay is my attempt to state it plainly, follow it to its conclusion, and name what I think comes next.
The assumption nobody states
Every piece of infrastructure we use to connect software was designed with one assumption baked in so deep it's invisible: the caller is either a human or a deterministic system.
Look at the stack. OpenAPI specs. REST and gRPC. API gateways. Generated SDK clients. Tool lists and function-calling schemas. Every one of them describes what a system can do and how to address it — and every one of them assumes the thing on the other end already knows what it wants.
A human navigates a UI. They arrive with intent, and the interface's job is to let them express it and to quietly stop them from doing the wrong thing. A deterministic system is even simpler: it calls a known endpoint with known inputs and handles known outputs. Neither of these callers reasons in the moment. Neither decides what to do based on a situation it's never seen before. They execute a known path against a known interface.
That assumption was correct for thirty years. It is correct no longer.
AI agents are a third kind of caller
An AI agent is not a human and not a deterministic system. It is a third thing, and we don't have good infrastructural intuitions for it yet.
It reasons. It decides. It acts autonomously across multiple systems in response to intent that was never fully specified — "sort out this customer's problem," "reconcile these accounts," "get this order to where it needs to be." It figures out the path turn by turn, inference by inference, and acts on each conclusion as it goes.
This is a genuinely new caller. And here is the thing I keep coming back to: we are handing this new kind of caller an interface built entirely for the old kinds. We give the reasoning, deciding, improvising agent the exact same tool list we'd give a deterministic script — a flat menu of capabilities — and we hope it behaves.
The mismatch between the kind of caller an AI agent is, and the kind of caller our infrastructure assumes, is — I've become convinced — the root cause of most of the governance, drift, and reliability problems people are hitting in production AI today. We keep treating these as model problems or prompt problems. I think they're interface problems.
Three places the mismatch shows
If the mismatch is real, it should show up in specific, diagnosable ways. It does. Three of them.
One — APIs expose capability, not how systems must be operated.
An API tells you what a system can do: the endpoint exists, it takes these parameters, it returns this shape. It says nothing about how those capabilities must be used. Which operations are valid in which states. Which sequences must precede which actions. Which roles can reach which methods. Which technically-valid call is operationally wrong.
A dispatched order can't be cancelled. KYC must clear before activation. This tier gets that pricing, fetched before you quote. These rules govern every action a competent operator takes — and they exist nowhere in the API surface. Connect an agent to your APIs and you've connected it to capability stripped of the operational knowledge that makes capability safe.
Two — prompts are advisory, applied by discretion.
The standard patch for the first gap is to put the rules in the system prompt. Tell the model what it should and shouldn't do. This works — until context grows long, until a model updates, until another developer edits the instructions, until the session runs long enough that the early constraints fade from attention.
In every other part of engineering, governance means the wrong action cannot execute — not that the system was instructed not to. A prompt is a suggestion the model applies probabilistically. A guardrail and a suggestion are different things, and the difference is the entire ballgame in production.
Three — tool-call chains accumulate drift.
Most agents operate in a loop: reason, call a tool, get the result, reason again. Each reasoning step is an independent inference pass. The model re-applies the rules from scratch every turn. So the agent that correctly followed a business rule at step three may not follow it at step seven — not because anything changed, but because reasoning drift is cumulative. Governance that has to be re-applied on every turn isn't structural governance. It's repetition under conditions you can't control.
None of these three is a model limitation. A better model drifts more slowly; it does not stop drifting. They are all symptoms of the same root: a reasoning caller pointed at an interface built for a deterministic one.
What a reasoning caller actually needs
If the interface is the problem, then the answer isn't a better model or a longer prompt. It's a different interaction model — one designed for a caller that reasons. When I work through what that model would have to look like, I get four requirements that hang together.
It must let the agent express its reasoning as one complete program — not a chain of tool calls.
This is the heart of it. Instead of the agent picking one tool, seeing the result, reasoning again, and picking another — drifting between each step — the agent should reason once, completely, inside a model of the domain, and emit a single program that encodes the whole intent: the conditions, the sequence, the transformations. One reasoning act. One program. One execution. One result. The conditional logic lives inside the program, not as round-trips back to the model for re-reasoning. The model authors; the runtime executes.
It must give the agent a formal operational model, not a tool list.
For the agent to reason completely in one pass, it needs more than method signatures. It needs the operational model: entity lifecycles, permitted and forbidden transitions, the hard boundaries, the business rules, the access constraints. This is what I've come to call a domain contract — a typed, versioned specification of how a capability group must be operated, loaded before the agent reasons, present on every session. Not retrieved at query time. Not stuffed into a prompt that drifts. Compiled in, structurally present before the first reasoning act.
Governance must happen before generation; containment at execution.
These are two different gates doing two different jobs. Governance belongs before code is written — in the operational model the agent reasons inside. If the constraint is structurally present before generation, the forbidden call is far less likely to ever appear in the program. Containment belongs at execution — an isolated sandbox with hard limits and no path out except the ones the contract permits. The reasoning gate makes the wrong action unlikely to be written; the execution gate makes sure that even if it is, it can't reach anything it shouldn't. Both. Neither alone is sufficient.
The upstream AI must see intent, not tools.
The orchestrator, the voice agent, the assistant on the other end — it should send intent and receive a conclusion. It should never hold the tool-call loop, never see the schemas, never carry the intermediate state. One call in, one result out. You stop governing hundreds of tools at the interface layer and start governing one thing: the intent boundary. Everything else is enforced structurally, below it, where the reasoning and the execution actually happen.
What this looks like, concretely
Here is the whole argument in one example. The task: cancel order 123 if it's eligible, and notify the customer.
The tool-list way: the agent is handed get_order, cancel_order, notify_customer. It calls get_order, sees the state, and now has to remember — from a prompt, somewhere up in a context that may be very long by now — that a dispatched order can't be cancelled. Maybe it remembers. Maybe, three days into a long-running session, it doesn't, and it cancels something it shouldn't. Nobody changed anything. The architecture produced two different outcomes from the same situation.
The domain-contract way: the agent receives a typed model that states the lifecycle and the hard boundary — cancellation is permitted only in pending or confirmed, never in dispatched. It reasons inside that model and writes one program: fetch the order, check the state, return "cannot cancel" if it's dispatched, otherwise cancel and notify. The state check is in the code the agent wrote. The forbidden action doesn't execute — not because a rule was remembered, but because the agent reasoned inside a model where the rule was structurally present before it wrote a line. Three days later, different session, same contract: same result. The program is the audit record.
That's the difference between an agent that can call your systems and an agent that can operate them correctly. It's not a smarter model. It's a different interaction model.
Why I think this is a category, not a feature
Here's the claim I'll plant a flag on.
REST and gRPC solved system-to-system communication — the deterministic caller talking to a known interface. They became standards because the problem was universal: everyone connecting services needed the same primitive, and it was better to adopt one than for each team to reinvent it.
Agentic AI has the same universal problem now, one layer up. Any organisation that lets AI act on its systems — not just answer questions, but execute real operations with consequences — will eventually need a way to carry operational knowledge into the agent's reasoning, to make governance structural rather than advisory, and to keep the upstream AI on intent rather than tools. They'll either build that primitive ad hoc, badly, over and over — or the field will converge on a standard one.
I don't think "tool list plus system prompt" is that standard. I think it's the deterministic-era interface being stretched, visibly past its limits, onto a caller it was never designed for. The standard for a reasoning caller is a different primitive: a formal operational model the agent reasons inside, and an agent whose whole job is to operate a set of systems correctly on behalf of other AIs.
That agent deserves a name distinct from "tool-use agent" or "function-calling agent," because it is doing a different job. I call it a toolsystem agent — an AI whose job is to operate your systems correctly, on behalf of other AIs. Not the AI that talks to the user. The AI that stands between that one and your systems, holds the rules of correct operation, and drives the tools through code.
One was built for deterministic callers. This one is built for reasoning ones.
That's the thesis. The rest is implementation.
This is the thinking behind Nexus — a toolsystem agent (powered by Claude) that operates your systems correctly, on behalf of other AIs. If the argument holds, the implementation is the easy part to talk about; the hard part was seeing that the caller had changed and the interface hadn't.
© 2026 Kannan Iyengar. First published at nexus.optomate.io/insights/the-toolsystem-agent. The term “toolsystem agent” and the argument set out here are the original work of the author.
Nexus is a toolsystem agent (powered by Claude) — an AI whose job is to operate your systems correctly, on behalf of other AIs. Built on dataBridges and APIFront. If you want to see the argument demonstrated against real systems, start a conversation about a first POC.
Talk to us →