How should an AI automation be designed?

The design starts by locating the judgement. Walk the process and ask, at each step, whether the decision could be written down. Nearly always one or two steps resist — reading what a customer meant, deciding whether two records describe the same thing, drafting something in the right register — and everything else is conditions, lookups and transformations. That map is the design: the resistant steps get a model, the rest gets code.

The second element is the boundary around the model step. Its output should be constrained to something checkable — one of a set of values, a structure with required fields, a reference that must resolve — and validated before anything downstream sees it. This is what stops a bad model output propagating into the deterministic part, and it converts an unbounded failure into a rejected item.

The third is what happens to a rejected item, which must be decided at design time rather than discovered. A queue for a person, a default path, a retry, a notification: any of these is fine and none of them is the default. The default, if nobody chooses, is that the item is dropped or passed through, and both are discovered later by their consequences.

The fourth is the trigger and the state. Something starts the run, something records what has been processed, and something prevents the same item being handled twice. This last one is unglamorous and it is where a large share of production problems live: a workflow that reprocesses on restart, or that misses items that arrived during a failure, will produce duplicates or gaps that look like model errors and are not.

The fifth is observation from the first day rather than after the first incident. Counts of items in and out, rejections by reason, cost per item, and a sample of outputs retained for inspection. All of these are trivial to add during the build and awkward to retrofit, and without them the first question anyone asks about the workflow will be unanswerable.

Finally, design the manual path deliberately rather than leaving it as whatever people did before. Every automation has exceptions, and the exception path is where the work actually goes when the automation is working well. If it is undefined, exceptions accumulate somewhere nobody owns, and the automation looks successful while the business absorbs a growing pile of unhandled cases.