Back to Blog

2 min read

What we mean when we say an agent closed the loop

Most agent products stop at the suggestion. The interesting engineering starts after the action, in whether the result makes it back to somewhere anyone can check.

Amara OseiHead of Product
A painted butterfly resting on a pale, textured ground.

There is a version of an AI agent that demos beautifully and is nearly useless in production. It reads your data, proposes something sensible, and stops. The proposal is the product. What happens next is your problem.

We call the alternative closing the loop, and it is less about autonomy than about bookkeeping.

Four steps, and most tools do two

  1. Read the context, not just the CRM record, but the thread, the calendar, and what happened the last three times this pattern appeared.
  2. Decide, and be able to say why in a sentence a human would accept.
  3. Act in the system the work actually lives in, not in a side panel that only the agent can see.
  4. Write the result back, so the next read, by a person or another agent, starts from what is now true.

Step four is the one that gets skipped, because it is the least demoable and the most annoying to build. It is also the only reason any of the first three compound.

Why the write-back is the hard part

Writing back means dealing with every way a system of record can refuse you. Required fields you do not have. Validation rules written in 2019 for a process nobody follows. Rate limits. A record locked by a workflow that fires on update. An identity that resolves to two contacts because someone changed their surname.

None of this is interesting, and all of it decides whether the agent is trustworthy. An action that silently fails to persist is worse than an action never taken. The log says it happened, the record says it did not, and the person who finds the gap stops believing the log.

An agent that acts but cannot prove the result landed has not automated the work. It has moved the work to whoever reconciles it later.
Amara Osei

What we build instead

Every action is transactional. It either lands in your system of record or it surfaces as a failure with the reason attached and a retry that a human can trigger. There is no third state where the agent believes it succeeded and the CRM disagrees.

Every action also carries a receipt: what it read, what it decided, and where it wrote. The receipt is not a log line for engineers. It is the artefact a rep looks at when they want to know why a deal got nudged on a Tuesday, and it is the reason they keep the agent turned on.