Where the call lands
After a reviewer approves, the agent makes one allowed call to a system the site already runs. This is what that call is, where it goes, and what is kept about it.
· 4 min read
IN SHORT
The call an agent makes after approval lands on a system the site already runs, reached through a declared route the admin made available and the version named. It is the step that sends, spends, or changes a record, and it is made only after a reviewer approves. What was sent, whether policy allowed it, and who approved are written to the run record on the appliance.
A run on Czar spends most of its time reading and drafting. Those steps touch nothing outside the agent. Then there is one step that does: the call that sends the reply, posts the entry, or changes the record. Everything about how an agent is governed on the appliance comes down to that step, so it is worth being precise about where it lands.
The call is the last step, not the first
The sequence of a run is fixed in the version. A packet arrives through the desk's front door. The agent reads only what it may read and drafts from those passages. The step that would send, spend, or change a record waits. A reviewer sees the draft and what it used, and approves or stops. Then the allowed call is made, or the run ends.
The call sits at the end of that sequence by design. By the time it is made, the inputs are known, the draft is complete, and a named person has decided. A run that is stopped at the waiting step makes no call. There is no partial write to undo.
The route it travels
The call goes out through Local Bridge, Substrate's declared routes to on-premise systems. The admin has made the target system available as a tool. The version has named it. The route runs from the appliance to the system over the site's own network.
On a connected site, the system may be the desk's messaging platform, the ledger, or the records system, each reached the way the site's other applications reach it. On an air-gapped site, the system is inside the same segment. In neither case does the call go to a vendor, to a cloud, or out of the building.
The system it reaches
The target is a system the site already runs and already secures. The agent does not get a special door into it. It uses the route the admin declared, with the scope that route carries, and the system applies whatever controls it applies to any other caller.
This matters for the owner of that system. A posted entry from an agent is a posted entry. It appears in the ledger the way any entry does, subject to the ledger's own rules, and the agent's run record on the appliance points at it. Two records, kept by two systems the site controls, agree about what happened.
It also means the scope of a call is bounded twice. The version's bounds say which tool the agent may call and when. The route itself carries the shape of what may be done on the target system. An agent cannot do more to the ledger than the route allows, even if a draft proposed it.
What is kept about the call
The run record holds the call in its place in the sequence. It shows which tool was called, what was sent, whether the version's bounds allowed it, and who approved when a person had to. The inputs that led to it and the draft that became it are on the same record.
So the question "why did this entry get posted" has an answer on the appliance. Someone opens the finished run and reads forward: this packet arrived, these passages were read, this draft was produced, this reviewer approved, this call was made. Inputs, draft, decision, and call are one sequence someone can open tomorrow.
Calls that are never made
Some runs end without a call. The reviewer stops the run because the draft is wrong, or the packet turns out not to be the kind the agent handles. Those runs are on the record too. The record shows the inputs, the draft, and the decision to stop, with the reviewer's name against it.
A stopped run is not a failure of the agent. It is the agent doing what the version said it would do: wait, and let a person decide. For the role that makes that decision, see /resources/glossary-reviewer. For the broader controls, see /governance.
Questions this raises
- Can a run make more than one outbound call?
- A version can include more than one step that calls a tool, and each step that sends, spends, or changes a record waits for approval. The bounds say which tools may be called and where approval is required, so the number and placement of calls is a design decision made before publishing.
- What if the system the call is going to is unavailable?
- The call does not succeed and the run does not pretend it did. The record shows the call was attempted and what came back. The desk's own application, which called the stable address, receives that outcome and handles it the way it handles any failed write.
- Does the reviewer see what will be sent before approving?
- Yes. The reviewer sees the draft, which is the content of the call, together with the passages and reads the agent used to produce it. The decision is made on the actual content, not on a summary of it.
KEEP READING