Architect the workflow, not the feature
Most enterprise AI fails because it ships features into workflows that weren't designed to receive them. Here's how we sequence the work instead.
The feature trap
When a leadership team asks for “an AI feature,” they are usually describing a symptom. The underlying request is almost always: make this process faster, more accurate, or more boring. Those are process outcomes, and a feature is a poor instrument for reaching them.
Shipping a feature into an unredesigned workflow is the cheapest possible way to look modern while changing nothing. The demo works because the demo controls its inputs. Production does not: the document arrives as a photograph of a screen, the reference data is eleven days stale, and the person who was supposed to review the output has ninety of them in a queue.
The failure is rarely the model. It is that nobody described the process the model was joining, so nobody noticed that the step it automated was not the step that was slow.
Start at the handoff, not at the task
We map workflows at the granularity of a single handoff: the moment work changes hands, changes systems, or changes state. Handoffs are where latency accumulates, where context is lost, and where errors are introduced by re-keying. They are also, conveniently, where the evidence lives — timestamps, ticket transitions, email threads.
Each handoff gets one of three labels. Preserve it, because a human judgement genuinely happens there. Automate it, because it is deterministic movement of data that a person is doing by hand. Eliminate it, because it exists only to verify the step before it, and the verification is cheaper to build into that step than to perform afterwards.
The third category is the one that matters and the one that automation projects consistently miss. A verification step is a symptom of low confidence upstream. Automating the check preserves the low confidence and adds a system to maintain. Removing the cause deletes both.
Why sequence beats tooling
Only after the handoff map exists do we choose models, and only after that do we choose tools. Reversing the order is how organisations end up with a platform decision that constrains an architecture that was never designed.
The practical test is whether you can state, in one sentence and without naming a vendor, what the system will do and how you will know whether it worked. If you cannot, the tooling decision is premature. If you can, the tooling decision is usually easy and often boring — which is the correct feeling to have about infrastructure.
Model selection follows the same discipline. The question is not which model scores highest on a public leaderboard; it is which model clears your accuracy bar within your latency budget, inside your data boundary, at a cost per case you can defend. Those four constraints usually eliminate most of the field before quality is even discussed.
Designing for the day it is wrong
Every workflow that includes a model needs an answer to a question that feature-shaped thinking never asks: what happens when the output is wrong, and how quickly does anyone find out?
This is a design decision, not a monitoring decision. If a wrong answer is caught downstream by a human who was going to read the document anyway, the cost of an error is low and the system can be aggressive. If a wrong answer is committed straight to a system of record that a customer sees, the cost is high and the design needs a review point, a confidence threshold, or both.
Review is expensive and it degrades. A reviewer asked to approve every output stops reading by the second week; a reviewer asked to approve the ten percent the system is least sure about stays sharp. Placing review where it changes an outcome, and removing it where it is theatre, is part of the architecture rather than an operational afterthought.
What good looks like
A well-sequenced engagement produces a workflow with fewer steps, not a workflow with the same steps and a model attached. The deliverable is a process description, an evaluation set, and a deployment plan — in that order.
The evaluation set is the part most teams skip and the part that makes everything else auditable. It is a collection of real cases from the process, with the correct outcome recorded, assembled before anything is built. It is what turns “the model seems better” into a number, and it is the only thing that will tell you six months from now whether a change was an improvement or a regression.
None of this is exotic. It is ordinary process engineering with a new component in the toolkit. The reason it looks like a differentiator is that the industry spent three years treating the component as the project.
Two failure modes to watch for
The first is the pilot that succeeds and never widens. It works because a motivated team hand-fed it clean inputs for eight weeks, and it stalls the moment it meets the queue it was meant to relieve. The tell is that nobody recorded what the inputs looked like during the pilot, so nobody can explain the drop.
The second is the platform bought before the process was understood. The tooling constrains the design, the design is then reverse-engineered to fit the licence, and two years later the organisation is defending an architecture nobody chose. The tell is a requirements document written in vendor vocabulary.
Both are avoidable by the same discipline: describe the process, record a baseline, and agree the success metric before anything is procured or built.
The order, restated
Map the handoffs. Decide which are preserved, automated or eliminated. Record a baseline for the metric you intend to move. Assemble an evaluation set from real cases. Then choose a model, and only then choose the tools around it.
Every step in that order is cheap to do and expensive to skip, and each one produces an artefact somebody else can check. That is the actual argument for the sequence: not that it is more rigorous, but that it is more auditable when the results are questioned.
Feature-first delivery produces a demo and a hope. Process-first delivery produces a workflow, a number, and a way to tell whether the number moved.