AI vs Deterministic Workflows

By Piotr Wolanski·12 OCT 2025·9 min read

Everyone wants to build agents at the moment. I understand why. You give a model an objective, some tools, the relevant information, and it decides what to do next. That is a genuinely powerful idea. It is also being applied in a lot of places where it should not be.

In many cases an agent can complete a workflow. That is no longer the interesting part. What I care about is which decisions require probabilistic reasoning, and which should remain deterministic by design. Once you are touching production data, permissions, approvals and records that actually matter, this stops being academic.

Use probabilistic intelligence where ambiguity creates value, but retain deterministic control wherever the system already knows what must be true. That is the whole essay, really. The rest is how that looks in a real system.

Two kinds of problem

Models are good at the messy stuff: unfamiliar documents, badly structured information, competing evidence, picking a tool, writing a useful recommendation. Conventional software is often terrible at this. Too many possible inputs, rules you cannot write down, a next step that depends on context you will not get into a decision tree.

Production systems also contain a completely different class of problem. Permission is binary. A record is there or it is not. The same calculation on the same inputs should not drift. You do not get to move from one state to another until the preconditions have actually been met.

Those are system invariants. I would rather put them in software than ask a model to rediscover them on every run. Making a deterministic decision probabilistic does not make the system smarter. It just makes it less predictable.

When the prompt becomes the product

A very common pattern right now is: expose a pile of tools, describe the goal, and let the model decide what to call and in what order.

For research, debugging, exploration, I think this is excellent. The moment those tools can change something that matters, I become much less comfortable. Two similar requests take different paths. A required step gets skipped because the model decided it was unnecessary. Incomplete evidence gets treated as enough. Sometimes it even calls the right tool with the wrong arguments.

The usual fix is to make the prompt longer. I have watched this happen. Another paragraph. Another “always remember to…”. Another list of edge cases. At some point you are no longer guiding reasoning. You are writing the application in English.

Prompts are not state machines. They are not authorisation systems. They are not substitutes for deterministic control. That is where I stop.

Put the model inside the workflow

I would rather put AI inside a workflow I already understand than let the model own the workflow.

AI reasoning sits inside a system workflow: validate state, reason, verify, pass a deterministic gate, then act and audit.

The model still does the valuable work: interpretation, synthesis, classification, recommendation, generation. Software around it decides whether that output is allowed, whether the transition is valid, and whether the action can actually run. Suggesting the next step and being allowed to take it are not the same job.

This is the distinction I keep coming back to. A model can look at a document and conclude that a requirement appears to be satisfied. Fine. That does not mean it should be able to mark the requirement complete. The same applies to recommending an approval, drafting a change, or pointing at an action. If the result actually matters, I want two different parts of the system answering two different questions: what looks right, and whether it is valid and permitted right now.

There is no technical reason those have to be the same component. In systems I actually have to operate, I prefer that they are not.

Do not give the agent a back door

If a human and an agent can cause the same state change, they should go through the same validator. I would not enforce three preconditions in the UI for a person and then describe those preconditions in a prompt for the agent. The rule needs to sit underneath both. Button, API, tool call, cron job. Same question: is this transition allowed.

Otherwise you end up with a serious product for humans and a shortcut for the model. I have seen that pattern more than once. The agent should not get extra authority just because it arrived through tools instead of a button. The same gate on every surface.

Check what comes out of the model

Most of the guardrail conversation is about what goes into the model. In production I worry at least as much about what comes out. Something can be syntactically valid, even schema-valid, and still violate an invariant. I have seen updates that quietly drop fields, and objects that would be fine in general and are not fine in this state.

So I let the model generate, then I decide whether to admit the result. Structurally valid, authorised, complete, safe to commit. If not, it does not go in. Document edits, extracted fields, workflow transitions, tool calls. Same idea. Generate first. Admit second.

I also do not treat every model conclusion as fact the moment it appears.

AI interpretation becomes a provisional result, then verification, then authoritative state.

Let it live as a provisional result first. Then validate it, cross-check it, or have a person look at it. That matters most when the model is interpreting evidence rather than creating something new. It can tell you what it thinks. You still decide what you are willing to treat as true.

Do not use a model to rediscover what you already know

If the system already has the answer in a deterministic form, I would not ask a language model to reconstruct it. If a calculation is defined, compute it. If the transitions are known, encode them. If there is a schema, validate against it. If there are permissions, enforce them.

There is very little upside in having a probabilistic model re-derive a precise rule on every execution. You lose reproducibility and you do not gain intelligence. Use the model where the path is actually unclear. Everywhere else, write the rule.

Autonomy is not on or off

I do not find it useful to call a system “autonomous” or “not autonomous”. Autonomy sits on individual actions.

Autonomy increases from read and interpret through recommend, draft and validated action, up to full autonomy.

An agent can have a lot of freedom while reading and almost none when it wants to change state. Drafting a whole document and being unable to publish it is not incomplete automation. In a lot of enterprise systems, the useful work is in that middle band: recommend, draft, act with validation. Full autonomy is the expensive end of the budget, not the default.

I would not begin with “build a fully autonomous agent”. I would begin with a workflow whose behaviour I understand and can actually evaluate. Once that exists, it is much easier to see where people are spending time because the input is ambiguous. Put the model there. Measure it against the baseline. Give it more authority only where that evidence supports it.

A manual process becomes a structured workflow, then AI-assisted, then recommendation, then validated action, then bounded autonomous execution.

Autonomy should be earned through demonstrated reliability. Not assumed at the start because the demo looked good.

Chains fail even when each step looks fine

This matters more as soon as you have a sequence of steps. Take a boring example. Ten stages, each succeeding independently at 0.98. The chance that all ten succeed is about 0.98¹⁰ ≈ 0.817.

Real agents are messier than that. Failures are not independent. Some are recoverable. Sometimes the model notices and corrects itself. Even so, small uncertainties can accumulate across long execution chains. I do not think of reliability as a property of the model. It is the whole thing: validation, retries, state, isolation, permissions, logs, recovery. A very good model in a weak system is still a weak system.

A model can write a beautiful explanation and leave the application in the wrong state. It can also be terse and have done the job perfectly. For production AI, I care more about whether:

the correct tool was selected
the correct arguments were supplied
appropriate evidence was consulted
permissions were respected
the expected state transition occurred
failures remained bounded

Those are ordinary engineering questions. They do not go away because the model can reason. The model is one component. It should not become the definition of the system.

When I actually want an agent

None of this is an argument against agents. There are problems where you cannot specify the path in advance. Research is the obvious one: you do not know which source has the evidence, whether the first hypothesis survives, or how many searches you will need. Debugging is similar. Looking at a defect may mean opening an unknown number of files, running tests, reading the failures and changing your mind.

In those cases I give the model much more room, because discovering the path is itself part of the problem. If the path is already known, asking it to rediscover that path every time is not intelligence. It is just extra uncertainty.

A lot of the current competition is about the model: better reasoning, better tool use, more context, longer runs. That matters. In production the interesting problems are usually more boring: who owns state, who is allowed to change it, and how you recover when the model is wrong.

A demo asks whether the model can complete the task. A production system has to ask what happens when it cannot. If you are putting this into production, the job is not to maximise autonomy. It is to put it where it is actually useful, and keep deterministic control everywhere the system already knows enough to behave with confidence.

The system should retain control.