Key takeaways
- A deterministic workflow has explicit states, allowed transitions and finish conditions; identical validated inputs take the same code path.
- AI can sit inside a deterministic workflow when its output is constrained to a schema, checked against rules and unable to choose its own permissions or destination.
- Move a step from model judgment to code once accepted examples reveal a stable rule. Keeping settled logic in a prompt buys variance without adding value.
- Determinism ends at an external boundary unless you verify the destination state. A successful API response alone is not proof that the business effect is correct.
Determinism is a contract for the path
Calling a workflow deterministic does not mean every byte of its output must be identical. Timestamps, generated identifiers and a bounded summary can vary. The contract is narrower and more useful: the workflow has declared states, each state has allowed transitions, inputs are validated, authority is fixed before the run and every terminal state has a testable condition.
The model can propose a value inside that contract. Code decides whether the value is well formed, permitted and sufficiently supported. A model that chooses its own tools, repeats until it feels finished and writes to any destination it discovers is an agentic runtime, even if its prompt contains a numbered list.
| Concern | Deterministic owner | Model may do |
|---|---|---|
| Trigger and identity | Validate event type, business key and version | Nothing |
| Interpretation | Provide allowed labels and evidence requirements | Classify, extract or summarize within the schema |
| Route | Select the next state from explicit rules | Return evidence used by a rule |
| Authority | Grant tools, fields, scope and expiry | Choose only among pre-authorized options |
| External effect | Use an idempotency key, approval state and destination check | Draft the proposed payload |
| Finish | Assert the post-condition or enter a named exception state | Explain an exception for review |
Convert settled judgment with a rule ledger
The useful conversion unit is one decision, not a whole workflow. Review accepted runs and find decisions whose explanation now repeats. If a process owner can state the condition, output and exception without “usually” or “use judgment,” the decision is ready to leave the prompt.
Google SRE describes automation as consistent and quick, while warning that automation applies a mistake just as faithfully as a correct rule. Its account of the evolution of automation is why the ledger includes both a rule and a proof obligation.
| Field | Question |
|---|---|
| Business key | Which real-world item makes two attempts the same work? |
| Rule | What exact condition selects the output? |
| Source fields | Which validated values may the rule read? |
| Output | Which typed value or state transition may it produce? |
| Counterexample | Which accepted case would make this rule wrong? |
| Exception | Where does missing, conflicting or novel input go? |
| Post-condition | What destination fact proves completion? |
Run the old and new decisions against the same case set before switching traffic. Google's testing guidance treats passing tests before and after a change as evidence that specific behavior stayed equivalent. Preserve disagreements; they show either a missing branch or judgment that should remain variable.
A support triage workflow with one variable step
An email arrives with ticket key SUP-4182. Code validates the channel, tenant and required fields, strips unsupported attachments and creates a run keyed by the ticket. A model selects one of six approved intent labels and returns the sentence that supports it.
Code checks the label, confirms the cited sentence exists and applies the routing table. “Account access” plus an identity mismatch always enters needs_identity_review; the model cannot route around that gate. A human either confirms the identity evidence or rejects the request. The write uses ticket:SUP-4182:route:v1 as its effect key, then reads the assigned owner back from the support system.
The model can vary its explanation. It cannot vary the allowed label set, identity rule, approval requirement, destination or number of writes. A second delivery of the email reaches the same completed effect rather than creating a second assignment.
Release only when the fixed path is observable
- Version the contract: instructions, model, schemas, routing rules and tool permissions belong to one release identity.
- Test the boundaries: malformed input, missing evidence, model refusal, tool timeout, duplicate delivery and denied approval each need an expected state.
- Record transitions: keep the state entered, rule or evidence used, actor, time and effect key.
- Reconcile effects: read the destination and compare it with the authorized proposal before marking the run complete.
- Canary narrowly: start with a reversible input class and a stop rule, then expand only after observed cases pass.
Use AI agent evaluation for the case set and slice gates. The deterministic path reduces what must be judged; it does not remove the need to test the boundary around the judgment that remains.
Limitations and when not to use this
- A deterministic route can still encode the wrong business rule. It improves repeatability and diagnosis, not the validity of the policy itself.
- External systems can accept a request and settle into a different state later. Reconciliation and repair remain necessary at every side-effect boundary.
- Do not force genuinely ambiguous, consequential decisions into code merely to claim determinism. Keep a qualified human decision where the rule cannot be stated and tested.
Sources
- The Evolution of Automation at Google — Google, Site Reliability Engineering Accessed 4 August 2026
- Testing for Reliability — Google, Site Reliability Engineering Accessed 4 August 2026
- Evaluation best practices — OpenAI Accessed 4 August 2026
Classify one disputed step
Answer the visible decision rules and export the minimum execution and control contract.
Classify one disputed stepUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.