Revised · 12 August 2026: the earlier version described the full execution stack as a 23-step chain. That inventory was useful for architecture work but too expensive as the default explanation. Recent causal-explanation experiments support a smaller public model built around the questions that actually change the next action.
At each boundary, ask what the previous layer has actually proved. Do not let a successful model call, Tool call, process, or old receipt silently answer a stronger question.
One simple task
Suppose the instruction is:
Renametimeout_mstotimeoutMs, update callers, run the tests, and ship it if the repository is still in the expected state.
The model can reason about the edit in seconds. But five different questions now appear.
- What work is the Agent allowed to attempt?
- What did the Agent actually ask the machine to do?
- What physically happened?
- Did any external consequence occur?
- Does the evidence still justify completing the task now?
Those questions are the architecture.
1. What work is actually authorized?
A capable model can imagine many useful actions. It should not have to guess which of those actions belong to the current job.
The owning domain or participant defines the objective and consequence. Host preserves the durable work commitment across interruptions. Harness receives one bounded assignment for one Agent episode.
domain intent
→ durable work commitment
→ one bounded Agent assignmentThe important distinction is:
Something can be visible to the Agent without being authorized as a consequence.
The Agent needs enough addressable information to distinguish its meaningful legal options. Final authority still belongs to the owner that admits the action.
2. What did the Agent decide to do?
This is the Harness layer.
Harness compiles the current working view, calls the model, presents the permitted Tools, returns observations, tracks the bounded episode, and stops when the Run reaches a candidate conclusion, needs input, exhausts its budget, or is interrupted.
There can be two valid paths:
- a mature Provider Harness can keep its own native Session and lifecycle;
- Ordivon Harness can provide a first-party model–Tool loop when the Provider supplies intelligence but no complete Agent system.
The two paths do not need one synthetic internal event model. They need enough shared evidence to hand durable responsibility back to the caller.
3. What physically happened?
The model says “run the tests.” The Harness asks for a Tool. Neither fact proves that a process started.
Runtime owns that boundary.
It binds exact Workspace state and operation identity to a durable Job and Attempt, then records process state, output, Artifacts, cancellation, timeout, restart recovery, and reconciliation. When immutable inputs or an execution provider matter, those physical commitments become part of the admitted operation.
Agent Tool request
→ admitted Runtime operation
→ process / file / local system change
→ exact physical evidenceIf the client disappears after admission, a later Agent should recover the Job rather than infer from missing output that nothing happened.
4. Did anything change outside the machine?
Now imagine the “ship” step calls an external deployment API. Runtime can prove that the local HTTP client process ran. It cannot, by itself, prove what the remote service committed.
This is where provider-native evidence and the narrow World boundary matter.
If the response is lost after dispatch, three outcomes are different:
- confirmed success;
- confirmed non-commit or failure;
- UNKNOWN — the external consequence may have happened, but current evidence cannot establish it.
UNKNOWN is not a model mood. It constrains the next action. A blind second POST may duplicate the consequence. The system must reconcile the original operation against the external owner before redispatching when idempotency is not already guaranteed.
World survives where the relationship across independent owners must remain correlated: which external object, which provider action, when the observation became available, and what original consequence remains unresolved.
5. Is the evidence still applicable now?
The tests passed ten minutes ago. Meanwhile another change landed on main.
The old test receipt can remain perfectly authentic. It can also be insufficient for the current completion decision.
Historical validity answers “what was true then?” Current applicability answers “may this evidence govern the decision now?”
The owning domain or Host-side completion boundary must revalidate the facts that make the evidence applicable: source generation, required Artifacts, unresolved consequences, current authority, and the domain's acceptance conditions.
This is why a completed Harness Run is still only a candidate completion. The work owner decides what the evidence means now.
The whole trajectory in one picture
1. domain / participant
What should happen, and what counts as success?
↓
2. Host + Harness boundary
What durable work is assigned to this Agent episode?
↓
3. Harness
What did the Agent decide and observe?
↓
4. Runtime
What physically happened on the machine?
↓
5. provider / World relation
What happened outside the machine, if anything?
↓
6. current owner
Does this evidence still justify the next semantic consequence?The numbering is explanatory, not a mandatory workflow. Some applications bypass Host. A mature Provider Harness may own more of the Agent episode. A local-only task may need no World relation. The boundaries appear only when their failure class appears.
Five common category errors
Most of the architecture exists to stop these one-step overclaims.
What should persist?
“Persist everything” sounds safe and usually creates a second problem: more stores, more stale state, more reconciliation, and more old context competing with current truth.
Recent cross-project experiments support a narrower rule:
Persist the smallest responsibility-bearing state whose loss would change current or recoverable responsibility, semantic selection, causal interpretation, recovery, or consequence identity.
A model's intermediate thought does not automatically qualify. A selected Artifact identity may. A durable Task frontier may. The original external request identity under an unresolved consequence may.
Where the formal objects fit
Once the causal picture is clear, Ordivon's formal names become useful compression rather than prerequisites:
Durable semantic responsibility and resumable frontier.
One bounded cognitive and Tool-using episode.
Exact local physical operation and evidence.
Facts that connect independently authoritative systems.
The object names are useful because the responsibilities already exist. They are not evidence that every application needs the same schema.
What changed since the first version
The earlier guide tried to be complete by enumerating every step from user surface through model serving, Tool calls, receipts, verification, and graph advancement. The newer Ordivon research suggests a better default: preserve exact detail in source and evidence, but teach the system through the causal questions that change the next decision.
That is not merely an editorial preference. EX3–EX7 compared richer explanation structures against compact causal prose across 1,326 accepted Agent decisions. The richer representations did not improve exact action on the tested surfaces.
Where to go next
- Read The Shorter Explanation Won for the explanation experiment.
- Read UNKNOWN Is an Operational State for response-loss and external ambiguity.
- Read World Got Smaller—and Got Clearer for the deletion test behind the current World boundary.
The model supplies the next intelligent proposal. Dependable work begins when the surrounding system can say exactly which stronger facts that proposal has—and has not—earned.