You are in a taxi when the message arrives. The room wants to offer a client a new volume tier and waits for your yes. You type “fine” and put the phone away. Two questions follow you inside. Did anything happen, and had you typed something less clear, what would the machine have made of it?
The step that stopped the room and waited for you is the Signature. The ledger that recorded every moment of the wait is the Record. Both are parts of the Cabinet, ArkOne’s reference design for an executive agent, and between them they answer both questions. The sentence to carry: the Signature waits as long as it must and never continues on its own; the Record writes everything down and never holds the meeting up.
A wait with three rules, and a ledger with one
A Signature is a step your company places in front of any tool it chooses, most often the fourth kind from the fourth paper: money, filings, an offer to a client. When the Chair, the one voice that speaks for the room, reaches one, three things happen in code.
The first is the pause. The run stops, nothing passes the Signature, and the wait has no expiry. A person who has not answered has not decided, and the design reads the silence as that.
The second is the checkpoint. The state of the meeting at the pause is written down: the rounds so far, the material gathered, the action proposed word for word. Whoever restarts the run starts from here, so what goes out after approval is what you were shown. Without a checkpoint an approval is a hope, because a run that resumes may reason its way to a different message from the one you read.
The third is the ambiguity rule. An answer the design is not confident it understood is asked again, never guessed. “Fine” is a yes. “Hmm, if they commit to two years” is a question, and the room treats it as one. The threshold that decides belongs to the twenty-second paper; here it is enough that the rule runs in code, its value on the Register, the standing page of every setting in the design.
Then the setting to look at twice. When the person answers, the run records the decision and stops, and a person restarts it. An approval that restarts a machine has consequences you cannot see coming; an approval that stops it gives you one more look, and the Record two entries rather than one: the yes, and the act.
That Record is the ledger of every action the room takes, with the reason beside it. It is append only: nothing is edited, a correction is a new entry, the old one stands, and that is what makes it evidence rather than notes. And it never blocks a turn. If its storage is unreachable the failure is logged elsewhere and the meeting goes on, at a cost the design states plainly: a minute of lost ledger is a minute in which the evidence is a note saying the evidence is missing.
The pause, the answer, the stop
Suppose the renewal that runs through the series, its figures invented for the exercise. The Chair has decided to hold the list price and offer the volume tier, and your company puts a Signature in front of any reply carrying a new commercial term.
| Moment | What the Signature does | What the Record holds |
|---|---|---|
| The Chair proposes to send the reply | Pauses before the Door, the rules that decide what may leave the room; writes the checkpoint, the reply word for word | The proposal, the pause, where the checkpoint sits |
| Forty minutes pass | Nothing; the wait has no expiry | Nothing new |
| You reply: “hmm, if they commit to two years” | Not confident it is a decision; asks again: approve as drafted, or change terms? | Your words, the low confidence, the question back |
| You reply: “approve as drafted” | Records the decision and stops; the run does not continue | The decision, who gave it, when |
| A colleague restarts the run | Resumes from the checkpoint; the reply goes to the Door and leaves | The restart, the send, the rule that allowed |
| The ledger’s storage is briefly unreachable | Nothing; the meeting continues | One line in the fallback: an entry could not be written, at this time |
Exhibit 2. Illustrative. A pause, a vague answer asked again, a clear answer recorded, a stop, a restart; and the ledger beside it, once failing to write.
The third row is the ambiguity rule at work. Your first reply was a real thought, and a design without the rule would have made something of it: read “two years” as a conditional yes, rewritten the offer, sent it. The reference design asked instead, which costs one message and saves you a client holding terms you never approved.
The last row is the ledger failing and the meeting not caring. What survives is a line naming which entry is missing and when: a smaller loss than a reply that never left because a database was slow.
What this arms you to ask
Ask which actions wait for a human, and what happens when the human is slow.
A good answer names the actions, says no timer turns silence into consent, and says the run resumes from a saved state. Then the question separating a Signature from a notification: after the human answers, does the job finish itself? The answer to press on describes a chat message you react to, after which the work carries on. Your approval and the action become one gesture, with no second look between them. Ask what it did the last time an answer was unclear, and whether the transcript shows the question it asked back or the guess it made.
Then the ledger. Show me the record of the last thing it did and why. A good answer is a page you can read without an engineer, the reason beside the action, corrections added rather than written over. And can a failed write stop it working? The answer is no, followed by the line where that failure was logged. If the logs live in a dashboard only the vendor can open, the evidence is theirs.
Next paper: One meeting, several models, no loyalty.
Asked plainly
What happens when an AI agent waits for approval and the person is slow?
In the reference design, nothing. The run pauses at the approval step, its state is saved where it stopped, and it holds there until a person answers. Silence is never read as consent, and no timer turns a missed message into a yes. A slow approval means a delayed action, never an assumed one.
After a human approves, does the AI agent finish the job on its own?
Not in the reference design. When the person answers, the run records the decision and stops; a person restarts it, and it resumes from the saved state rather than from the beginning. The design chooses this so that an approval is never the same gesture as an action, and the two are written down separately.
Can a failure to write the audit log stop an AI agent from working?
It should not, and in the reference design it cannot. A failed audit write is itself logged, in a fallback, and the meeting continues. The ledger is append only, so nothing already written is edited or removed to make room; a correction is a new entry and the old one stands. The honest limit is that a moment of lost ledger is a moment where the evidence is a note saying the evidence is missing.
Ask the vendor
The questions this part arms, each with the good answer and the answer that arrives instead.