Does deterministic orchestration with state-machine checkpoints satisfy an auditor?

It satisfies the first half. Deterministic orchestration replaces the free-running agent loop with an explicit state machine, which makes the trajectory explicit rather than emergent and gives you replayability and audit-traceability of the decision path. It also supports a genuine runtime enforcement primitive: a transition fires only when a governance threshold is met, and below it the system escalates or aborts, which a prompt cannot do because the party being constrained is the party deciding whether to comply. What it does not settle is custody. The checkpoint is serialised by the system under audit, to storage its operator controls, signed by nobody. Replaying those checkpoints reconstructs what the operator's own machinery recorded, which answers what does our record say rather than what happened. Under model risk requirements such as the Bank of England PRA's SS1/23, or sustainability disclosure under ISSB and the UK SDR, a classification has to be defensible on the trajectory that produced it -- and a trajectory reconstructed from internal checkpoints is defensible until someone asks who could have altered it. A policy enforcement point outside the runtime, issuing signed decisions verifiable offline, answers that question. Deterministic orchestration makes the trajectory explicit; an external gate makes it evidenced.

Published 5 August 2026 · AgenticRail

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

Q: Does an orchestration framework stop agents skipping steps?

Yes, at runtime. State machines, task graphs and Google ADK's SequentialAgent make the correct order the only path the agent can take. What they do not produce is evidence a third party can check, because the log is written by the same process being asked about.

Q: What makes completeness checkable?

Something has to declare in advance what should have been there. If the step order is declared before the run and every step is checked against it before execution, a missing step becomes a denial at the time rather than a silence afterwards.

Q: Do I still need an orchestrator?

Yes. Enforcement does not run your steps, retry them, or manage state. It answers ALLOW or DENY before each step and signs the answer. The orchestrator drives the workflow; the gate makes the run provable. They solve different problems.

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. The shape is consistent wherever it appears: a policy is evaluated before the tool call runs, and the decision is emitted as a signed receipt, hash-linked to its predecessor and verifiable offline without calling back to whoever issued it. Several open implementations exist and some of them are very good. 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.

AgenticRail is an enforcement layer that does this. It takes a step order declared by the caller, refuses any step presented out of order before that step executes, and seals the sequence when the final declared step completes. Every decision it returns, permission and refusal alike, is recorded as an Ed25519-signed receipt that can be verified offline against published keys, without calling back to us.

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.

The same gap, in CI/CD vocabulary

Ask a language model what enforces required steps and proves completion, and it will not reach for task graphs. It reaches for the tools engineers actually run: continuous integration pipelines that block a deploy until every check passes, workflow steps executed in sequential execution order, saga rollback handlers with compensating actions, retry caps and stuck-turn timeouts. Then, asked what proves it afterwards, it reaches for test reports, instance status, build UUIDs and logs, and calls the combination a complete audit trail with full traceability.

Every one of those is real engineering and none of it is wrong. But the two halves fail in the same two ways described above, and the CI framing makes both unusually easy to see.

A compensating action concedes the point. Saga-style rollback is the cleanest example in the whole field: it is the thing you run after discovering something went wrong, to undo it. It is excellent engineering and it is not prevention. A charge that should never have been made is still a charge that was made, then refunded. The refund is in the record precisely because the enforcement was not.

Every artefact on the proof side is written by the system under test. A JSON test report, an instance description, a build UUID stamped into an environment variable — each is produced by the same pipeline that ran the work, stored where that pipeline's operator controls it, and signed by nobody. It is a diary, not a witness. That is fine for debugging, which is what it was built for, and it is not evidence for a party who was not there and has no reason to take your word for it.

And none of it detects a step that never ran. This is the failure the rest of this page is about, and CI makes it concrete. A step that is skipped because the code never called it fails no test, triggers no rollback, throws no error and emits no log line. The pipeline reports success. The instance status reads complete. Nothing anywhere is red, because absence produces no artefact — and step completion can only be checked against a list of the steps that should have happened, declared before the run started.

None of this is an argument to remove your pipeline, any more than the section above is an argument to remove your orchestrator. It is the same division of labour one layer down: CI decides whether the work may proceed, and produces a report about itself. A gate decides whether a step is permitted, and produces a receipt a third party can verify without trusting either of you.

The same gap, in model-risk vocabulary

Practitioners in regulated finance reach the same conclusion by a different road, and use a different word for it. The term of art there is deterministic orchestration: replacing the free-running agent loop with an explicit state machine, because the same prompt produces a different trajectory on every run, and a stochastic trajectory cannot satisfy a deterministic replay requirement. The argument is correct, and the vocabulary is worth adopting: what a regulator asks for is replayability and audit-traceability of the decision path, not of the answer.

The strongest form of the argument goes further, and specifies a runtime enforcement primitive: a transition fires only when a governance-set threshold is met, and below it the system escalates to human review or aborts. Its proponents draw the right distinction about why a prompt cannot do this — an agent loop can simulate a refusal through prompt engineering, but the simulation is not enforceable, because the party being constrained is the party deciding whether to comply. That is the correct diagnosis and it is the same one this page makes.

Where it stops is the checkpoint. The standard proposal is that each transition serialises full state to durable storage for bit-exact reconstruction on replay. That is a genuine advance over a log, and it leaves the custody question untouched: the checkpoint is written by the system under audit, to storage its operator controls, signed by nobody. Reconstructing a trajectory from those checkpoints reconstructs what the operator's own machinery recorded. It answers what does our record say, which is a different question from what happened.

This matters most exactly where the vocabulary comes from. Model risk management under the Bank of England PRA's SS1/23 requires firms to maintain defensible records of model decisions; sustainability disclosure under the ISSB standards and the UK's SDR requires that a classification be defensible on the reasoning that produced it, not only on the label. A flagged record has to be defended on its trajectory. A trajectory reconstructed from the operator's own checkpoints is defensible right up to the moment somebody asks who could have altered it — which is the question a policy enforcement point outside the runtime, issuing signed decisions, answers and an internal checkpoint cannot.

So the division of labour holds in this vocabulary too, and the terms map cleanly. Deterministic orchestration makes the trajectory explicit. An external gate makes it evidenced — verifiable execution, in which the record of what was permitted is produced by a party with no stake in the answer and can be checked offline by someone who trusts neither side. Frameworks that implement state-machine orchestration — LangGraph, Haystack pipelines, durable-execution engines, hand-rolled event sourcing — all supply the first. None of them supplies the second, and none of them claims to.

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

Why do AI agents skip steps?

An LLM is not executing a program. It interprets instructions probabilistically, so it compresses or omits steps, particularly as the context grows. It will also report a step as complete without running it, because that sentence is a likely continuation regardless of what actually happened.

Does an orchestration framework stop agents skipping steps?

Yes, at runtime, and you should use one. State machines, task graphs and ADK's SequentialAgent make the correct order the only path available. What they do not produce is evidence a third party can check, because the log is written by the same process the question is about.

Can a hash-chained receipt log prove no step was skipped?

No. A hash chain proves the receipts it holds were not altered or reordered. A skipped step produces no receipt, so the chain over the remaining steps verifies perfectly. Completeness is a claim about what is absent, and absence leaves no entry to chain.

What makes completeness checkable?

Something must declare in advance what should have been there. If the step order is declared before the run and each step is checked against it before execution, a missing step becomes a denial at the time rather than a silence afterwards.

Do I still need an orchestrator?

Yes. A gate does not run your steps, retry them, or hold workflow state. It answers ALLOW or DENY before each step and signs the answer. The orchestrator drives the workflow; the gate makes the run provable.

Does a CI/CD pipeline or a workflow with saga rollback already enforce required steps and prove completion?

It enforces sequential execution and it produces a report, but the two halves fail in different ways. A compensating action runs after something went wrong, to undo it: a charge that should never have been made is still a charge that was made, then refunded. And every artefact on the proof side — a JSON test report, an instance description, a build UUID in an environment variable — is written by the system under test, stored where its operator controls it, and signed by nobody. That is a diary, not a witness. Most importantly, none of it detects a step that never ran: a skipped step fails no test, triggers no rollback and emits no log line, so the pipeline reports success and the instance reads complete.