Orchestration vs Enforcement: Your Task Graph Stops Agents Skipping Steps. It Cannot Prove They Didn't.

If your agent keeps skipping steps, the advice you will find is to stop asking the model nicely and take the control flow away from it: a state machine, a task graph, a durable workflow, Google ADK's SequentialAgent, a stateful MCP tool. That advice is correct and you should follow it. But it solves the operational problem and leaves the evidential one untouched. When someone later asks "prove the approval step ran before the payment step," an orchestrator can only offer its own account of itself, and a signed receipt log cannot tell you about a step that never happened. A skipped step writes no line. Absence leaves no entry.

Two families of answer, and the gap between them

The step-skipping problem has produced two distinct bodies of work, and they do not overlap as much as their vocabulary suggests.

Orchestration makes the correct order the only available path. Explicit state machines, task dependency graphs, durable execution engines and ADK's SequentialAgent all share the same insight: if skipping a step is structurally impossible, the model's probabilistic tendencies stop mattering. This works. It is the right first move and nothing below argues against it.

Receipt layers make each action independently checkable. Microsoft's open-source Agent Governance Toolkit intercepts tool calls before execution, evaluates them against a Cedar policy, and emits offline-verifiable Ed25519 receipts hash-linked to their predecessor. The Agent Receipts specification signs each agent action as a W3C Verifiable Credential. These are genuinely good designs, and the cryptography is not the hard part any more.

Now put an auditor in the room. They ask one question: did every required step run, in order, before the money moved?

The orchestrator can answer, but its answer is its own log, written by the process under examination. That is fine for debugging and worth very little as evidence, for the same reason a company's own assurance that it followed its procedure is not an audit.

The receipt layer can prove that the receipts it holds were not tampered with. What it cannot do is tell you about a receipt that was never created. If the approval step never ran, no receipt exists for it, and the hash chain over the remaining steps is perfectly intact. The chain is not lying. It simply has nothing to say about the step that is missing.

Why a hash chain cannot detect a gap

This is worth being precise about, because tamper-evident is often read as complete, and they are different properties.

A hash chain binds each record to the one before it. Alter record three and records four onward stop verifying. That is a strong guarantee about the records that exist.

Completeness is a claim about records that do not exist, and no amount of chaining can establish it, because there is nothing to chain. A run of four steps where the second was skipped produces three receipts that link correctly to each other. Nothing in the artifact distinguishes it from a workflow that was only ever meant to have three steps.

A log can only report what it contains. To notice that something is missing, you need a statement of what should have been there, made before the run, by something other than the thing being audited. Without that, "complete" is not a checkable word.

What closes it: declare the order first

The gap closes with one structural change. The caller declares the step order in advance, and every step is checked against that declaration before it executes.

That inverts the problem. A skipped step is no longer a silence discovered later; it is a DENY at the moment it is attempted, with a signed record of the refusal. The question stops being "can we find evidence of the missing step" and becomes "the step could not have proceeded, and here is the receipt that says so."

Four properties follow from that one change, and each is a thing a per-call receipt cannot supply on its own:

• Order is checkable, not assumed. A step arriving out of turn is refused against the caller's own declared order, not against a convention.
• Replay is blocked. Each step carries a nonce that is accepted once. A captured payload replayed later is refused rather than silently recorded twice.
• Freshness is bounded. A request whose timestamp is far from the gate's clock is refused, so a stale authorisation cannot be presented as a current one.
• The run has an end. When the final declared step completes, the sequence is sealed and no further step is accepted into it. A sealed run is finite, so it can be hashed whole, archived, and cited as one object rather than as "everything so far".

That last one is easy to skim past. An open log can only ever say so far. A sealed sequence can be referred to as a completed thing, which is what makes it usable as evidence in a process that happens weeks later.

This is not a replacement for your orchestrator

Enforcement does not run your steps, retry them, handle timeouts, or hold workflow state. Those are real problems and your orchestrator is the right tool for them. Keep it.

What a gate adds is a second party. Your orchestrator decides what happens next; an independent gate decides whether it is permitted to, answers ALLOW or DENY before execution, and signs the answer. The division matters precisely because the orchestrator is inside the system being asked about, and the gate is not.

In practice that is one HTTP call before each step. The gate returns a decision and a receipt; your orchestration logic is unchanged apart from honouring a DENY.

What this does not establish

Being straight about the boundaries is the point of the exercise, so:

• A receipt records that a step was permitted, not that it succeeded. Whether your downstream action worked is your runtime's business, not the gate's. AgenticRail is an enforcement layer, not an execution runtime.
• It does not check that the work was correct. That the moderation step ran, in order, before the result was recorded is provable. Whether the moderator was right is not, and no receipt scheme changes that.
• Timestamps are signed, not attested. The signature covers the time, so it cannot be altered afterwards without breaking verification. It does not establish that the time is true, because the gate generates it. Signed and attested are different words.
• Sealing is detectable, not impossible. A sealed sequence cannot be reopened without leaving a detectable break in the receipt chain. A single altered receipt is caught immediately. A full downstream rewrite by whoever holds the signing key is caught by an independently held copy, not by the chain alone, which is why custody is a separate question from cryptography.

How to check every claim on this page

None of this needs to be taken on trust, and none of it requires contacting anyone:

• Run the live demo. It executes a real multi-step sequence against the production gate and returns a sequence identifier.
• Try to skip a step, or replay one, and watch it come back DENY with SEQUENCE_VIOLATION or REPLAY_NONCE.
• Paste the identifier into the verification tool. It returns every receipt, including the denied ones, each with its raw signature and the exact bytes that were signed.
• Fetch the published public keys and run standard Ed25519 verification in your own code, offline, with no call back to us.

The public evaluation key is DEMO-AGENTICRAIL-PUBLIC-2026. It is real, there is nothing to sign up for, and the docs have a copy-paste example.

If a claim on this page does not match the live system, the live system is the authority and the page is wrong.

Frequently asked questions

Related reading: Deterministic vs Probabilistic AI Agents · Pre-Action Authorization · AI Agent Audit Log Best Practices · Completeness Specification