Don't automate the workflow you have

Every established workflow records the constraints that shaped it. Approvals exist because someone made an expensive mistake. Handoffs exist because the work crossed a team boundary with a headcount problem. Batching exists because a person could not be interrupted for every request.

Insert a model into step seven of that process and step seven runs faster. The handoffs remain. The approvals remain. Cycle time barely moves, and the program reports a productivity gain that no one in the business can feel.

Start from the outcome

The question is not how to accelerate the current path. It is what the business is trying to produce, and what the shortest defensible route to it looks like now that some of the old constraints have lifted.

That reframing puts existing process ownership on the table, which makes it uncomfortable. It is also where the return is. A workflow redesigned around what is now possible often collapses to a fraction of its original length, and the saving comes from the steps that disappear rather than the steps that run faster.

Decide what belongs to a machine

Once you fix the outcome, the work divides more cleanly than most teams expect. Retrieval, drafting, reconciliation, and classification are work a model can carry from one end to the other. Work that must return the same answer every time belongs in deterministic code, where it has always belonged. A tax calculation is not a reasoning problem.

A smaller set of decisions stays with a person, and you should be able to say why: the cost of being wrong is high, the input is ambiguous in a way that requires accountability, or a regulator expects a person to have reviewed it. Keeping a person in the loop for unstated reasons produces a bottleneck no one can justify.

Write the policy into the design

What the system may do, what it must escalate, and what it must never touch is not a compliance step at the end. It is the boundary the design sits inside, and it constrains the architecture as much as any technical requirement. Writing it late means rebuilding.

Why one team has to do both

Redesigning a workflow requires someone who can sit with the people doing the work and map where effort and judgment go. Deciding what a model carries reliably requires someone who has built and measured these systems. Split those across two firms, or across a strategy team and a delivery team, and the design degrades at the handoff.

That is the argument for a small embedded team rather than a large staged one. The person who understood the problem is still there when it is built.

More field notes