When to use a workflow and when to let the agent think

There is a strong temptation at the start: if the agent can reason, let it reason about everything. Explain the goal, hand it tools, let it figure things out. It is seductive because it is very little code.

It is also the fastest way to build a system that works eighty percent of the time and that nobody can debug.

The rule we use

After a fair amount of trial and error, it settled here:

If the step can be described precisely, it belongs to the workflow. Buying a domain, generating a contract, issuing an invoice, publishing a change. These have an order, they have preconditions, and they have a clear definition of done. They do not need judgement: they need to execute correctly every time.

If the step requires interpreting something ambiguous, it belongs to the agent. Understanding what a client means when they write "hey, I want something more modern." Deciding whether a photo works for a hero section. Writing a section in the brand's voice.

The classic mistake is crossing them. Letting the agent decide the order of phases, which is information you already have, or writing rigid rules to interpret human language, which is exactly what rules cannot do.

The seam

The interesting part happens at the boundary. Our flow is deterministic: phase one, phase two, phase three, each with its tasks. But inside a task there can be an agent working with complete freedom.

That gives you a valuable property: when something goes wrong, you know which task it was in. You are not debugging "the agent," which is a box where a thousand things happen. You are debugging the task "write the services section," which has an input, an output, and an acceptance criterion.

The difference between those two situations, measured in diagnosis time, is hours versus minutes.

Determinism where it counts

There is one place we do not negotiate: money and client data. Charging, issuing, deleting, publishing outward. Those operations are never decided by a model. They are decided by the workflow, and at most the model prepares content that a person or a rule then approves.

This is not distrust of the model. It is that the cost of being wrong there is not symmetric: weak copy gets rewritten, an incorrectly issued invoice costs a relationship.

What it looks like in practice

A change request for a client's site arrives over chat. The agent interprets what they want, which is the ambiguous part. The workflow handles the rest: creates the task, assigns it, verifies the site still responds after the change, publishes, and reports back. If anything fails at any point, the workflow knows how to roll back, because that is written down.

The interpretive work goes to whoever can interpret. The repetitive work goes to whoever never gets tired and never improvises. Put that way it sounds obvious, but it takes a while to arrive at the split and a fair amount of discipline not to cross it when you are in a hurry.