Redesign the Workflow Before You Automate It

Koko: Here is the one instinct this entire lesson is built around: you redesign the work before you choose the technology. Not after. Not in parallel. Before. If you take nothing else away today, take that.

Max: Okay, but I feel like I've heard some version of that in every software project forever. Why does it hit differently with AI agents?

Koko: Because an agent is wet concrete. Whatever process you point it at, you set in place. Think about a cow path. A trail wanders across a field because of a fence that was taken down years ago — the fence is long gone, but the animals still walk the old route out of habit, and people follow the animals. If you pour concrete along that wander, you have permanently automated a detour that nobody needs. The right move is to take down the metaphorical fence first, then pave the straight line.

Max: So automating a broken process just makes the mess run faster.

Koko: Faster, and now it runs faster with your name on it. That's the trap. And the tempting version of that trap — the one I hear from every client — is: can't we just wrap the AI around the current process and let it figure out the mess? Skip the painful redesign, ship something faster.

Max: That does sound efficient on the surface.

Koko: It's exactly backwards. The model will dutifully reproduce the re-keying, the waiting, the inconsistency. You've spent real money to automate the detour. So the first move is always to map the real workflow — not the tidy version in the process document, the one that actually happens.

Max: And those two things are different.

Koko: Almost always. The documented process is the myth. The mapped process is the truth. And the gap between them is where every automation quietly fails.

Max: Okay so what does a real map cover? What am I actually capturing?

Koko: Nine things, end to end. The triggers that start the work. The tasks performed. The decisions made. The data and systems touched. The tools used. The controls that must hold. The handoffs between people. The exceptions that break the happy path. And the outcomes that count as done.

Max: That's thorough. I notice exceptions are on that list explicitly.

Koko: Deliberately. Design for the exceptions first, not the happy path. The missing photos, the conflicting weights, the out-of-policy ask — that's where disputes actually live. The clean case is the easy five percent.

Max: Right, the happy path takes care of itself. It's the edge cases that blow things up.

Koko: Exactly. Now once you have the honest map, you run four verbs over it in order before a single task goes to a model. Eliminate, simplify, standardize, and make deterministic.

Max: Walk me through those on something real.

Koko: Let's use Northwind — it's a fictional distributor with a dispute resolution process we'll keep coming back to. You map the dispute workflow honestly and you find the analyst re-keys shipment weight into a second system by hand. And they wait on a manager's email to approve any credit over two hundred dollars. Those two things alone explain most of the delay.

Max: So eliminate the re-key by integrating the two systems, and standardize the approval threshold into a written rule instead of a manager's inbox.

Koko: You just cut a large chunk of the delay, and no model was involved. That's the point. Then you look at the dispute types and you find that clean duplicate charges — same charge billed twice on one invoice — are a completely fixed rule. There's no judgment required.

Max: So route those to deterministic automation entirely. Off the agent.

Koko: Off the agent entirely. What's left for the agent is only the genuinely ambiguous work. You are shrinking the agent's job on purpose.

Max: I like that framing. Give the agent the smallest possible piece.

Koko: That's the instinct to carry. The agent should inherit the smallest, cleanest, most standardized slice of the process that only it can do — after you've stripped everything a rule, an integration, or a deleted step could handle for free.

Max: Okay, and what does standardize look like in practice on that map? Because eliminate and make deterministic feel concrete, but standardize feels a little vague.

Koko: Great place to push. At Northwind, every analyst assembles a different evidence bundle for a damaged-shipment claim. One pulls the bill of lading, another chases the photos, a third calls the terminal. Same dispute type, three different evidence packets arriving at the decision point.

Max: So the model is also having to figure out what information it even has before it can reason about the actual dispute.

Koko: Exactly. So you redesign that into a single fixed evidence checklist — named systems, set order — so every dispute of a given type arrives with the same complete packet. That's standardize and make deterministic working together. And it's the highest-leverage move on the map.

Max: Because a model reasoning over clean, consistent, complete input is a fundamentally easier thing to build.

Koko: And cheaper. You're not paying for a model that also has to go hunting for evidence. You've done that work upstream, in the process design, where it belongs.

Max: Let me bring this into my world for a second. In professional services — say a global consumer-goods manufacturer where we're doing an order-to-cash redesign, drowning in deductions and disputes — this is process work we already know how to do. Current-state map, eliminate the duplicate reconciliations, standardize the deduction codes. So the agent conversation comes at the end, scoped to whatever judgment-heavy residue is left.

Koko: That's exactly right. And you already have the toolkit for the first three verbs. The mistake I see smart teams make is they arrive at the client, the client hands them a process document, and they take it at face value.

Max: Right, the client says the process is documented, so we can skip straight to the automation design.

Koko: And that is the trap, stated cleanly. The documented process is the myth. You still have to go map what actually happens, because the gap between the document and reality is precisely where the automation will fail quietly and expensively.

Max: Quietly is the scary word there. It doesn't blow up loudly, it just produces subtly wrong outputs.

Koko: With your name on the engagement. So: map the real workflow first. Eliminate, simplify, standardize, make deterministic. Hand the agent the residue. That's the doctrine, and everything we build on top of it in this lesson follows from that sequence.

Koko: So we've got the redesigned workflow on paper. Process is cleaner, steps make sense. But there's still a gap, and it's the one the technology literally cannot fill for you. You have to answer it before you touch a model.

Max: Which is what, exactly?

Koko: Who is in charge of each decision. That's the authority matrix, and it's the second artifact you produce in this redesign work. For every decision in the flow, you name four things: who decides, who reviews or approves, who is accountable when something goes wrong, and when the whole thing escalates out of the flow entirely.

Max: Okay, that sounds like a RACI chart.

Koko: It is exactly a RACI chart. You draw those for human org designs without blinking. An agent is just a new actor on that same grid. It gets a row, like any other role, with explicit rights and explicit limits.

Max: So I just drop the agent into the existing RACI and I'm done?

Koko: Not quite. The trap is letting the agent quietly occupy several rows at once — proposing, and approving, and executing. The moment you do that, you've collapsed segregation of duties the instant you automate it. One row. Defined rights. Hard stops.

Max: Right, because on a human team you'd never let one person both propose and approve a payment. You're saying the agent doesn't get a pass on that just because it's software.

Koko: Exactly. And here's the phrase that should make every builder nervous: the agent handles it. It sounds like a feature. It is actually a liability. Because the moment something goes wrong, accountability evaporates. Nobody's name is on the decision.

Max: The matrix is how you put a name on it.

Koko: Before you need it. Not during the incident. That's the whole point. Look at how this reads on the Northwind example. The agent may read records and propose a credit. That is its decision right, and it stops there. A human with the authority to bind the company approves anything above a standardized threshold. Anything touching a damaged-goods insurance claim escalates out of the agent's lane entirely — different risk, different owner.

Max: Propose, never unilaterally pay.

Koko: That's the instinct. Give the agent the narrowest decision right that still lets it do useful work, and name the accountable human for every consequential step before the agent ever runs.

Max: Okay, but here's where I'd push back in a real engagement. If we've done the testing and the agent is hitting, say, ninety-five percent accuracy on these credit proposals, why do we still need an approval gate? At some point isn't that just friction?

Koko: That is the seductive version of wrong, and I want to be direct about it. Accuracy is not accountability.

Max: Say more.

Koko: The gate on a consequential, binding action is not there because you distrust the model's arithmetic. It's there so that when a wrong credit goes out — and one eventually will — there is a named human who owned the approval and a control that can catch it. Decision rights are part of the design. You cannot bolt them on after the incident.

Max: So high accuracy in testing doesn't retire the need for the control. It just tells you the control won't fire very often.

Koko: Perfectly put. The rarity of the exception is not an argument for removing the check. It's an argument for keeping it.

Max: So how does this land in the actual work we do? Because in a consulting or PE context, authority matrices sound like org design, not agent design.

Koko: It is org design. That's the point. This is target-operating-model work. And it lands hardest on a private-equity value-creation plan, specifically mid-integration, when a portfolio company has just been carved out of its former parent.

Max: Why is a carve-out the sharpest case?

Koko: Because decision rights are genuinely unsettled at that moment. Who can now bind the new company? What are the new approval thresholds? Where does segregation of duties sit after roles were consolidated in the carve-out? Those answers didn't transfer cleanly. And when a carve-out thins the finance team, you often end up with the same person who both proposes and approves. That's a segregation-of-duties gap in the human org.

Max: And if you automate before you fix it, the agent cements the gap.

Koko: You've automated ambiguity into the foundation of the new company. That's a hundred-day-plan problem you've just locked in permanently.

Max: So redrawing the authority matrix is actually a standalone deliverable on the hundred-day plan, before any agent work starts.

Koko: In its own right. Treat the agent as one more actor you're placing on the new operating model. It gets least-privilege rights and its own escalation lines, just like a new hire would. It is not a shortcut around the org design.

Max: Here's the trap I'd probably fall into though. The portfolio company already has an approvals policy. Spending limits, authorization levels, all written down. So I tell the client the agent just follows the existing policy and we move on.

Koko: And that policy points at people and thresholds that may no longer exist.

Max: Oh. The carve-out changed who actually holds the authority.

Koko: The VP of Finance at the parent who sat at the top of that approval chain is gone. The limits were set against a balance sheet that's now different. The policy is a document describing an org that no longer exists. You have to re-establish the decision rights for the redesigned org first. Then, and only then, you let the agent take a defined seat inside them.

Max: So the sequencing is: settle who owns what in the new structure, write that into the authority matrix, then place the agent on the grid with a specific row and specific limits.

Koko: That's the whole module in one sentence. The phrase that ties it together: the agent is a new actor on an operating model that has to be designed first. It doesn't dissolve the org design question. It adds a row to it.

Max: And if you skip that step, you don't have an efficient new company. You have an automated version of the confusion.

Koko: At speed. Which is the one thing you definitely didn't need more of.

Koko: So we've got the process map and the decision rights sorted. The last artifact is the one that decides whether anyone actually believes your business case.

Max: The numbers. The ROI slide.

Koko: Exactly — but specifically a counterfactual and a measurable value baseline. And this is where the most well-intentioned teams go wrong.

Max: How so?

Koko: They credit the agent for value the redesign already delivered. Remember Northwind — removing the re-key, standardizing the approval threshold. That cut days out of the cycle time. With no model involved at all.

Max: Right, just cleaner process work.

Koko: So if you only measure the process after the agent goes live and hand the agent the entire before-and-after improvement, you've mismeasured badly. Most of that gain was the redesign.

Max: Okay, but I've definitely seen slides that say something like — the pilot cut handling time forty percent, so the agent's ROI is forty percent. That's the tempting version, right?

Koko: That is the slide that gets written constantly, yes. And an investment committee will discount it, or reject it outright, because you can't trace where the forty came from.

Max: Because a big chunk of that forty was the eliminated re-key and the cleaner threshold.

Koko: Exactly. A value claim you can't decompose is a value claim that doesn't survive diligence. Full stop.

Max: So what does the counterfactual actually fix?

Koko: It forces you to ask: what would have happened without the agent — specifically, against the redesigned-but-still-manual process. And then you credit the agent only for its marginal contribution over that line.

Max: So the comparison isn't old messy process versus agent. It's clean redesigned process versus clean redesigned process plus agent.

Koko: That's it. Think of it like a drug trial with a control arm. If everyone in the study also changed their diet, you cannot claim the whole recovery for the pill.

Max: The redesign is the diet change.

Koko: The redesign is the diet, the agent is the pill, and the counterfactual is the control arm that lets you tell them apart. Without it, you're reporting an effect you genuinely cannot attribute.

Max: And in our world — PE deal teams, Fortune 500 CFOs — that attribution question is going to come.

Koko: It's the first question. For a private-equity deal team, the counterfactual baseline is the thing they will underwrite. A value-creation plan that says agents deliver X in savings gets torn apart in the investment committee unless X is baselined, attributed, and traceable.

Max: This much from redesign, this much marginal from automation.

Koko: Measured against a stated pre-change starting point. Give them a clean baseline and an honest split, and the number holds. Give them a blended forty percent, and it evaporates under the first hard question.

Max: Same thing in a Fortune 500 finance-ops case, I'd imagine — the CFO needs something the finance team can reconcile.

Koko: Precisely. An unattributed claim is the fastest way to lose the room with a CFO. And here's the other side of the ledger people forget — be honest about the full cost.

Max: Model spend, human review, rework when it's wrong.

Koko: All of it. The controls you built in the last module. A cheaper-looking automation that gets bounced back by a reviewer half the time can cost more per resolved dispute than the manual process it replaced.

Max: So the number to show the committee isn't gross time saved.

Koko: It's value per accepted outcome. That's the honest denominator.

Max: Okay, so the instinct here is: measure the baseline first, then attribute honestly — the redesign gets its share, the agent gets its share.

Koko: Neither steals the other's credit. That's the discipline.

Max: Now — when do you capture that baseline? I'm tempted to say wait until the redesign settles, so the numbers are stable before you start measuring.

Koko: And that is the last trap. If you baseline after the redesign, you've already thrown away the ability to see what the redesign itself was worth.

Max: You'd silently fold the redesign's gains into the agent's column.

Koko: You'd never even notice. Capture the true current-state baseline before you touch anything. Before the redesign, before the agent, before you've changed a single handoff.

Max: Measure first, then change. Got it.

Koko: Alright, let's pull it all together. Three modules, three artifacts. What did we build?

Max: A process map that asks which steps genuinely need a model — not which steps could technically use one. Then a decision-rights layer that names who owns each agentic action, with controls that hold the process when something goes wrong. And now a counterfactual baseline that separates the redesign's value from the agent's marginal contribution.

Koko: That's the whole test. A redesign is only defensible when every agentic step that survives has a justified reason a model must do it, a named human who owns it, a control that holds it, and a measurable outcome you can actually attribute.

Max: And the agent comes at the end of that process, not the beginning.

Koko: It comes last. And it comes smaller than anyone expected.

Max: Which sounds like a let-down until you realize a smaller, well-attributed, actually-survives-diligence number is worth more than a big blended claim that collapses in the room.

Koko: Exactly. The instincts to carry forward: map before you automate, settle decision rights before you deploy, and baseline before you touch anything. Those three in order, every time.

Max: Fix the process, settle the rights, set the baseline — then build the agent.

Koko: That's the discipline. And if you want to keep sharpening it — the guided journey and the labs that let you practice all of this live are waiting for you at KokoAI Academy on koko knows dot A I.

Max: I will be there.

Koko: You already know more than most people who are building right now — go put it to work.