Qopper
Action verifiedEXECUTED IN YOUR SYSTEM

Blog/Engineering

How an AI agent actually takes action in your systems

The model doesn't execute anything: it asks for it to be executed. What tool calling is, what the full loop looks like, and why reads and writes aren't treated the same when something fails halfway.

Kevin Manotas · CEO & Co-Founder

October 6, 2026 · 4 min read

A language model doesn't execute anything. It surprises almost everyone the first time they hear it: the only thing a model knows how to do is write. When an agent cancels an order, what the model did was ask for it to be canceled, and an ordinary program that was listening canceled it.

That request has a name: tool calling. It's the entire mechanism by which an agent goes from saying to doing, and understanding it is what lets you judge whether someone's agent really does something or just describes it well.

What a tool is, to a model

Three things: a name, a description and a form with the fields to fill in. “cancel_order”, “cancels an order that hasn't left the warehouse yet”, and one required field, the order number. Nothing else.

The description is the most underrated piece. It isn't documentation for the team: it's the instruction that decides when that action is used and when it isn't, and the model reads it. A vague description is an agent that cancels orders when asked about a return.

The loop, step by step

  1. 1The message arrives. The model gets what the customer wrote and, alongside it, the list of tools it's allowed to use at that moment.
  2. 2The model picks and fills in. It doesn't answer the customer yet: it answers with a request. This tool, with these values taken from the conversation.
  3. 3It runs outside the model. The call is made by ordinary code, with the business's credential, its timeouts and its rules. The model never sees the credential or decides the how.
  4. 4The result comes back. It enters the conversation as one more message, but marked as a result and not as something anyone said.
  5. 5And around again. With the result in front of it, the model answers or asks for something else. A real case chains three or four: check the order, check the policy that applies, make the change, verify it.

The model decides what. Never how, with which permissions, or up to how much.

Reading and writing aren't the same thing

This is where almost all the serious engineering of an agent that acts lives, and it's an asymmetry you don't notice until something fails halfway.

  • A read can be repeatedIf the network fails or the system returns a transient error, you ask again. Asking twice costs one request and nothing more.
  • A write is only repeated if you can prove it never landedAnd a timeout doesn't prove it. The refund may well have been issued and the response lost on the way back. Retrying it is refunding twice.
  • When nobody can know, it goes to a personThat case ends as a failure that gets handed off, with what was attempted and what's known. Not knowing is an honest ending. Guessing isn't.

The same action, twice

There's a second road to a double refund, and it doesn't come from the network: it comes from the model itself. Asking for the same action twice in the same turn, because the first result didn't come back as expected, isn't a rare failure. It's a Tuesday.

That's why the same action, with the same values, in the same conversation, counts as already done for ten minutes. Long enough to cover the model that insists and the customer who asks again three messages later; short enough that a refund genuinely requested twice in an hour still goes through.

What an agent can do in a turn goes through three filters before it reaches the model: what the business has actually connected, what that specific agent has turned on, and what its owner has left on automatic instead of behind an approval.

All three sound like settings, and they're product. An agent offered seven store actions with no store connected can only answer that it can't, and on the other side that doesn't read as a pending setting: it reads as a broken product.

Executing isn't finishing

The last part is the one most often missing. A call that didn't error doesn't mean the change is made: it means the other system accepted the request. Verifying is looking again AFTER acting and finding the change there.

A write nobody looked at again isn't verified. It probably worked, and most of the time it will have, but “probably” isn't what you tell a customer. And when it couldn't be verified, the result travels with the sentence the agent is allowed to say, ahead of the answer: a verdict the model doesn't see doesn't change a single word of what the customer ends up reading.

The hard part of an agent that acts was never that it acted. It's that it knows when it didn't manage to, and says so.

Keep reading
Start today

The AI layer for your customer support

Agents that resolve, not deflect: they act in your systems, verify and respond.