Why our agents stop for a person

An agent can take several steps on its own, and that is exactly why it needs a clear place to stop. Our agents plan the work, check each step, watch for events, route the decisions that belong to someone else and do the groundwork so a person can decide quickly. When a decision needs a person, the agent stops and waits.

Decide the stopping points before the first run

The useful question is not whether an agent can perform a step. It is whether that step should happen without a named person seeing it first. A practical test is to ask what a mistake would cost, and whether it could be undone. Anything that moves money, changes a record others rely on, or closes something with a safety or regulatory duty is a candidate for a stop.

In the examples on our Operate page, posting a journal, releasing a payment and changing bank details all fall into that group. The agent prepares the work in each case. A person makes the call.

What the agent may do, and what it may never do

Every agent gets its own set of tools, each one typed and whitelisted. Reading is not the same as writing, and drafting is not the same as posting. An agent can have read access to a ledger and permission to draft a journal, while having no route at all to post it.

Some actions are never available. A payment the agent cannot send cannot be sent through a clever prompt, a retry or a tool error. The limits are yours to set, and they are enforced, not suggested. What the agent may never do, it cannot do, however it is asked.

What the person sees before they decide

When a step waits for approval, the person does not receive a bare request. They see the evidence the agent used: the records it read, the rule it applied, the draft it prepared and the sources behind it. They can approve, edit or reject. If they edit, the change is kept in the log with their name against it.

The same principle applies to customer-facing work. The agent can draft a reply in your style, using your own records and policies, but nothing is sent until a person signs it off. Routine questions can be answered directly. Anything that needs judgement is handed over with the conversation attached, so the person does not start again from the beginning.

Routing by rules you can read

Handing over is not a single switch. Decisions are routed by rules that you write and can read. The illustrative invoice case on our Operate page sends a held invoice under £500 from a known supplier to an accounts payable clerk. Above £5,000, or from a new supplier, it goes to the AP manager. If the bank details changed in the last 30 days, it goes to the finance director and needs a phone check. The thresholds are examples, but the pattern is the point: the rule decides who sees the case, not the model.

Keeping the trail

Every plan, call, input, result, retry, refusal and approval is logged, along with who allowed each action. Any run can be replayed step by step and explained afterwards. For a regulated team, that is the test that matters: an agent should be easier to audit than the manual process it replaces.

Most of an agent is guardrail. Reasoning plans the work, but the checks, permissions, approvals and logs around it are plain code that can be tested. That is why we can say where an agent will stop before it runs, and show the person who approves it what they are approving.