AI workflow automation: design the chain by the way it breaks

Traditional automation has a property that we rarely appreciate until it is gone: it stops when it is confused. A parser that meets an unexpected format throws. A step that cannot find a field halts the run. Somebody gets an alert, the job sits in a failed state, and the damage is bounded by the fact that nothing continued.

Put a language model in the middle of that chain and you lose the property entirely. Given an input it cannot handle, the model does not stop. It produces something reasonable looking from whatever it can make of the input, and hands it to the next step. The next step accepts it, because it has the shape that was expected. Nothing anywhere signals a problem.

By the time anyone notices, the wrong output has been filed, sent, or acted on, and there is a stretch of history to go back through.

That difference is the entire design problem. Building a chain that works when everything is well formed is straightforward. Building one whose failures are visible is the actual engineering.

Rule one: constrain the output shape, then validate it

Ask for a fixed structure, and check that structure before the next step runs.

This sounds like a formatting concern and it is not. A step that emits free prose into a field another step reads as a value will, eventually, emit prose you did not want, and the receiving step will do something with it. A schema check at the boundary converts that from a silent corruption into an explicit failure at the moment it happens.

Validate the type, the presence of required fields, and where you can, the plausibility of values. A date in the far future, an amount with the wrong order of magnitude, an empty string where a name was required: these are cheap to check and they catch a surprising share of real problems.

Rule two: give every step permission to refuse

A step that must always produce an answer will always produce one, including when it has nothing.

So build in an explicit way out. Let a step return a value meaning I cannot do this one, and route those to a human queue. This is the single highest value change available in most chains, because it converts a category of invisible errors into a small, visible list that somebody works through.

In practice this means the prompt must permit refusal, the schema must have a slot for it, and the downstream logic must handle it as a normal outcome rather than an exception. If any of the three is missing, the refusal path does not exist and the step will invent instead.

Rule three: log the input next to the output

When a bad result surfaces weeks later, the only way to understand it is to see what went in.

Storing only outputs makes failures unexplainable, and an unexplainable failure repeats, because nobody can identify the class of input that caused it. Store both, keep them long enough to matter, and make them searchable by the identifier a human would actually have to hand when the complaint arrives.

This is also how you find out whether your chain has been quietly wrong for a while, which is a question worth being able to answer.

Where to put the human

The useful placement is not a general approval step at the end, which becomes a rubber stamp within two weeks. People cannot sustain attention on a stream of items that are almost always fine.

Better placements are narrow. At the refusal queue, where a person only sees the cases the chain flagged. At the point where the output first becomes irreversible, such as before something is sent externally or written to a system of record. And at a sampled review, where a small random share of successful runs gets looked at properly, precisely because those are the ones nothing else checks.

The question to answer before you build

Decide what happens if the chain is wrong and nobody notices for a week.

If the answer is that a handful of drafts need redoing, build it. If the answer involves money moved, a client told something false, or a record that other work now depends on, then the chain needs a person inside it, not a better prompt. No amount of prompt engineering converts an unbounded failure into a bounded one, and treating it as a prompt problem is how bounded failures become unbounded ones.

The chains that survive contact with real inputs are the ones designed by someone who assumed, from the start, that a step would go wrong quietly. That assumption is correct, and building on it costs far less than discovering it later.