When teams first introduce AI into their operations, the pitch usually stops at "assistant" — a chat surface, a summariser, a smarter search box. It is a comfortable frame because it does not force anyone to change the underlying process. The useful reframe is different: an operational workflow is a system with inputs, decisions, and side effects, and once those decisions become legible to code, the whole shape of the work is available for redesign.
That distinction matters because it changes what you are optimising for. An assistant helps a person get through today's queue faster. A re-architected workflow reshapes what the queue is.
Workflows as observable systems
The first job on any engagement is not modelling — it is making the current workflow observable. Where does the work start? Who catches errors when they escape the tool? Which decisions are recurring templates and which are genuinely one-off? Most operations teams live inside a mesh of Slack messages, spreadsheet rows, and CRM stages. That mesh is legible to humans but opaque to code. Before you can improve it, you have to trace it.
Architecting workflows, not features
With the map in hand, the architecture question shifts from "where can AI help?" to "which decisions should the system make on its own, and which should surface for review?" The temptation is to draw a single big flowchart. The pattern that actually holds up in production is smaller: reusable steps that agree on data shape and error semantics, so that when one link breaks the surrounding links keep flowing.
- Prefer explicit hand-offs between steps over shared mutable state.
- Log every decision the system made and the reason it made it — not just the outcome.
- Design guardrails as first-class steps, not as post-hoc validators.
- Ship one thin end-to-end path before you build the second one.
The teams that ship durable AI work are the ones that treat evaluation as a first-class feature, not a launch-week checklist.
Once the shape is right, model choice becomes a downstream decision. The model does the job the workflow was designed to hand to it. If the workflow is well-formed — inputs are typed, decisions are logged, guardrails are enforced — swapping models is a one-line change, and every team we have worked with has done exactly that at least once.
We treat every engagement as an exercise in this reframing. The visible artefacts are the same as any AI project — retrieval, tools, evals — but the underlying work is architectural. That is the layer where reliability lives, and it is the layer that survives the next model release.