Agent or Not? Earning the Right to Use Agency

Koko: Here is the one instinct this entire lesson is built around: autonomy is something you earn with evidence, not a default you reach for. If you leave today with nothing else, leave with that.

Max: Okay, so the instinct isn't 'when in doubt, go agentic.' It's almost the opposite.

Koko: Exactly the opposite. The doctrine is called minimum sufficient agency. There is a ladder of solution types, and the job is to start at the bottom rung and climb only when the rung below it provably can't meet the outcome, or the exceptions, or the quality bar — at a better risk-adjusted cost.

Max: Walk me through the ladder. How many rungs?

Koko: Six, from least to most powerful. Deterministic automation. A single model call. A retrieval assistant — grounded question-answering over approved documents. A fixed LLM workflow. A bounded single agent. And a multi-agent system.

Max: So where does 'agent' actually start on that ladder?

Koko: After rung four. The first four are not agents at all. And this matters more than people realize, because the test isn't how much AI is involved. The test is who controls the path.

Max: What do you mean by who controls the path?

Koko: If code decides the sequence of steps, it's a workflow — no matter how many models it calls. Only when the model itself is selecting and sequencing its next steps at runtime, inside hard limits and explicit stop conditions, do you actually have an agent.

Max: So a really elaborate prompt chain with five model calls is still just a workflow.

Koko: Still a workflow. Test the control path, not the vocabulary. A lot of teams call a coded prompt-chain an agent and then wonder why it behaves nothing like one.

Max: That's a trap I can already imagine falling into, especially when a client's leadership is asking for something that sounds agentic.

Koko: Which is exactly where a useful memory line helps. Try this one: workflows decide the path, agents decide part of the path, tools do the work, and policies decide what is allowed. Four different jobs. Confusing them is how the trouble starts.

Max: So workflows decide the path, agents decide part of the path, tools do the work, policies decide what is allowed. Yeah, those really are four different things.

Koko: Keep those four separate in your head and you'll catch a lot of design errors before they get built.

Max: You mentioned a detective analogy earlier. What's that about?

Koko: You don't hire a detective to check whether two plus two equals four. You use a calculator for the arithmetic and you save the detective for the cases that genuinely need investigating. Agency is the detective — expensive, powerful, and completely wasted on the easy stuff.

Max: And most enterprise work is arithmetic.

Koko: Most of it, yes. The mistake is treating every problem like it needs a detective just because a detective sounds impressive in a steering committee deck.

Max: Okay, give me a concrete example. Because in the abstract this sounds obvious, but in the room with a client it probably isn't.

Koko: Take a freight company. Customers dispute invoices. The whole inbox looks like one problem because it arrives in the same envelope. But it isn't.

Max: What are the different cases?

Koko: The same charge billed twice on one invoice. That's a rule. Deterministic automation resolves it — no model at all, just logic. Then there's the customer who asks why a line item is what it is. The answer lives in the rate sheet. That's retrieval. Grounded question-answering. Still not an agent.

Max: What's the case that actually earns an agent?

Koko: A pallet arrived damaged, the customer sends photos, they want a partial credit. Now you have judgment over unstructured evidence pulled from multiple systems. That's where a bounded agent starts to earn its keep.

Max: Same inbox, three different rungs.

Koko: Exactly. And the senior move is naming those rungs out loud before you build anything.

Max: How does that actually play out in a client engagement? Say I'm advising the controller of a global manufacturer who's been told to deploy AI agents across the financial close.

Koko: The senior move is not to design the agent. It's to walk the process inventory and name a rung for each step.

Max: What does that look like for a financial close?

Koko: Reconciliations and schema checks are deterministic. Variance narratives are single model calls. Policy lookups are retrieval. And maybe — maybe — one genuinely ambiguous investigation queue justifies a bounded agent.

Max: So most of the close is below the agent line.

Koko: Usually, yes. And that inventory — every process, its rung, and the reason the rung below it fails — that becomes a defensible decision artifact. Something you can take to an investment committee or a board.

Max: Versus 'we built an agent because leadership asked for one.'

Koko: Which is not a defensible artifact. The consultant who can name the smallest sufficient rung, and defend it, is doing the work everyone else is skipping.

Max: Here's the temptation though. The client's board wants an agentic transformation. They want to look AI-forward. Isn't there pressure to just put an agent on the whole function and figure it out later?

Koko: That's the trap, stated perfectly. A close cousin of it is 'start at the top — go multi-agent now and simplify later if you have to.' Both are backwards.

Max: Because simplifying later almost never happens.

Koko: It almost never happens, and the complexity you added on the way up is now load-bearing. Minimum sufficient agency says start at the simplest rung and climb only with evidence. Picking the rung that demos best is exactly the mistake this competency exists to prevent.

Max: So the instinct is: name the rung out loud, then force the simpler rung to explain why it fails before you climb.

Koko: That's the practice. Say it explicitly: 'this is retrieval, because the answer lives in read-only docs and nothing gets changed.' 'This is a workflow, because the steps are the same every time and code can decide the order.' If you can't articulate why the rung below can't do the job, you haven't earned the climb.

Max: And you said name the evidence in advance — what does that mean?

Koko: Before you build, say out loud what you'd have to see to justify climbing a rung. The exception volume. The ambiguity level. The quality miss. If that evidence never shows up, the simpler design was the right answer all along.

Max: So it's not just about the rung you pick — it's about being able to say in advance what would change your mind.

Koko: That's what makes it defensible. Anyone can pick a rung. The senior call is being able to say: here is the rung, here is why the one below it fails, and here is what we'd need to see before we go higher. That's the whole doctrine.

Koko: So we've established the ladder — deterministic at the bottom, full autonomy at the top. Now the question is what you're actually paying every time you step up a rung.

Max: And I'm guessing it's not just money.

Koko: It's four things, and they all travel together. Cost, latency, unpredictability, and a bigger security surface. Every single rung, all four. You don't get to pick two.

Max: Okay, walk me through them.

Koko: Start with cost. An agent that reasons in a loop is spending compute on every decision. And that's on top of the build cost, the evaluation harness you need to trust it, and the ongoing operations to keep it from drifting. A lookup costs a fraction of a cent and never needs a prompt rewrite.

Max: Right, and the lookup doesn't call you at two in the morning.

Koko: Exactly. Latency is next. A reasoning loop is slower than a query. A deterministic answer comes back now. An agent deliberates. That might be fine. It might be a customer-experience problem. But it's always a cost.

Max: What about unpredictability? Because sometimes that's the whole point — you want the model to figure something out.

Koko: That's the right tension. Unpredictability is a feature when you genuinely need judgment. It's a defect when you needed the same exact answer every time. A probabilistic loop can take a path you didn't foresee. When that's valuable, great. When it's a compliance workflow, not so great.

Max: And the security surface?

Koko: This one catches people off guard. The moment you give a model tools and autonomy over untrusted inputs — say, customer emails — you have opened a new attack surface. A crafted message can try to talk the agent into an action it shouldn't take.

Max: Like someone writing an email specifically to manipulate the agent.

Koko: Exactly. And if your tool permissions are too broad, that goes from an annoyance to an incident very fast. Over-permissioned tools are the thing that turns a clever jailbreak attempt into an actual breach.

Max: So every rung up is really four line items on the bill, not one.

Koko: Four line items, and you own all of them the moment you choose that design. That's what I mean when I say autonomy is inherited liability. You don't get more capability and leave the risk behind. It comes with.

Max: Okay, but here's the thing. If you're building AI systems for a client, isn't adding the autonomy just being safe? Future-proofing it so you're not rebuilding in a year?

Koko: That is the most seductive wrong answer in this entire course. Say it back to yourself slowly: you are inheriting an agent's uncertainty and its whole security surface today, to hedge against a maybe tomorrow.

Max: When you put it that way, you're paying a real cost now for a hypothetical benefit.

Koko: Real cost, real risk, real ops burden. And its equally seductive sibling is the phrase 'the agent just handles it.' Which quietly means no owner, no defined control path, and no answer when something goes wrong. Autonomy purchased to be safe is the least safe thing on the table.

Max: So the punchline is what exactly?

Koko: Correctly rejecting an agent is a top-tier skill. Anyone can bolt on autonomy — that's easy, that's impressive-looking in a demo. Choosing deterministic automation or a fixed workflow when that's genuinely the smallest sufficient design is the outcome this course rewards most.

Max: Because you avoided the cost and risk you never needed.

Koko: Right. Think about it like a good advisor telling a client to walk away from a bad deal. That advisor is adding value, not withholding it. The value is in the restraint. Recommending the simpler solution is the same move.

Max: So the instinct to build — what does that actually look like in practice?

Koko: You bring a defensible non-agent alternative to every design review. Even when you end up choosing the agent. If you can't articulate the cheaper design you rejected and why you rejected it, you don't actually understand the one you picked.

Max: That's a good forcing function. You have to do the work of ruling out the simpler thing.

Koko: It's the discipline. The disciplined no. And it's the thing that separates someone who's building responsibly from someone who's just building.

Max: Let me push on the professional-services angle, because this comes up constantly in our world. A deal team is doing diligence on a target that's marketing an AI agent platform as its main differentiator. The tempting read is to score the agentic architecture as sophistication and let it support a richer multiple. Is that wrong?

Koko: It's the tempting read. The senior read is to pressure-test whether the work underneath even needs an agent.

Max: Meaning what, exactly?

Koko: Meaning: if the target has wrapped a deterministic, rule-stable process in an autonomous loop, that is not a moat. That's inherited run-rate cost, latency the customers are probably feeling, and an unmanaged security and compliance surface.

Max: So in the IC memo, that's a red flag rather than a premium.

Koko: Potentially a significant one. The question isn't 'did they build an agent.' The question is 'did the problem require one.' If the answer is no, you're looking at complexity the business doesn't need, paying for it every month, and inheriting the risk that comes with it.

Max: And on the value-creation side — say you've just acquired a portco and you're trying to protect EBITDA. What's the move there?

Koko: The EBITDA-friendly answer is often the boring one. Every rung up the ladder is a line on the run-rate. The deterministic and retrieval designs protect margin. They also keep the audit story and the security story simple, which matters a lot when you're trying to sell that business in three to five years.

Max: So a defensibly simpler competitor with lower total cost of ownership is a real finding in diligence.

Koko: It's a real finding, not a consolation prize. If the competitor is doing the same job for less cost and less risk because they didn't over-engineer it, that is a structural advantage.

Max: And the consultant who spots that — who can say 'you don't need the agent here' — that's actually the senior call.

Koko: That is exactly the senior call. Here's the cheaper design. Here's how it protects your EBITDA. Here's what it does to your risk posture. That's protecting the client. That's the value. Saying yes to the agent when the problem doesn't need one is not sophisticated — it's just expensive.

Max: So the trap is mistaking architectural complexity for architectural quality.

Koko: That's the trap. Complexity is visible. It looks like work. Restraint is invisible — it looks like nothing happened. But nothing happening, when nothing needed to happen, is the whole point. Minimum sufficient design isn't a limitation. It's the goal.

Koko: So here is the thing nobody says out loud about what we just built with Northwind's dispute queue. We never said yes or no to 'should we use an agent for disputes.' We drew a map. Each stream got its own answer.

Max: Right, the invoice status lookup went deterministic, no model at all. The duplicate charge was a rule. Explaining a line item was retrieval. Routing tickets was a single classifier call. And only the genuinely ambiguous stuff — damaged goods, novel disputes — got the bounded agent with the approval gate.

Koko: Exactly. And when you line them up, roughly half the queue is correctly served by a non-agent design. That is not a consolation prize. That is the point.

Max: But here is the temptation. When a client asks 'can we put an agent on the whole inbox,' it feels like the bold move. One solution, one story for the steering committee.

Koko: And that is precisely the wrong call. You have just put arithmetic — invoice lookups, duplicate flags — on a probabilistic path. The cases you had perfectly nailed with a rule are now occasionally wrong. The easy sixty percent of the queue is over-built, and you have made it less reliable, not more.

Max: So the instinct to reward is: right-size each stream separately, not the whole function at once.

Koko: That is the one. Think of it as staffing a project. You do not put your most expensive partner on every line item in the work plan. You match each task to the cheapest resource that can do it reliably, and you reserve the senior judgment for the work that actually requires it. An agent is your senior partner. Invoice lookups do not need a senior partner.

Max: I like that. And it also means that sometimes the right-sizing splits a stream that looked like one thing into two paths.

Koko: Yes — and those are the ones that catch people out. Supplier onboarding at that same freight company is a good example. The clean majority of vendors pass automated checks. Deterministic, no model needed. But a meaningful minority have mismatched bank details or ambiguous ownership that need someone to read documents, cross-check sources, and decide case by case. One process, two designs. The deterministic path for the clean majority, and a bounded agent for the exceptions — with a human approving the actual vendor creation and any bank-detail change.

Max: So the trap is treating a mixed stream as one thing and reaching for one tool.

Koko: Right. The senior move is to ask: is there a clean majority here that deserves a cheaper, more reliable path? Almost always, the answer is yes.

Max: Okay, so once you have mapped the streams and right-sized each one, when does the answer actually become multi-agent? Because I can already hear the client asking: should we show the board something more advanced?

Koko: That framing — 'show the board we are advanced' — is exactly the trap. Multi-agent is not a maturity badge you award yourself. It is an architectural tradeoff you reach for only when a real specialization problem, a context isolation problem, or a genuine cross-boundary ownership problem defeats a single agent. Not before.

Max: So what does that actually look like when it is justified?

Koko: Northwind's own example: a global financial close spanning many legal entities, multiple currencies, and different local rules, where the regional investigations genuinely conflict and have to be reconciled across a real ownership boundary. That can justify multiple coordinating agents. But only with that evidence. If one agent could hold the context, one agent is the smaller, preferred choice.

Max: Because every extra agent is coordination cost you now have to manage.

Koko: And a bigger failure surface. Every handoff between agents is a place where things can go wrong silently. You do not add that unless the alternative is genuinely worse.

Max: So the instinct is: treat multi-agent as almost never your first move. Justify it with a real ownership boundary, not a slide deck.

Koko: Exactly. And the trap is the maturity-badge version: we should build a multi-agent system to demonstrate progress. That is how you get coordination overhead and a larger blast radius on a problem a single agent could have handled quietly.

Max: Okay. Now let me press on the professional-services version of this, because this is the room I am usually in. A hundred-day value-creation plan at a PE-backed services roll-up. The thesis is shared-services efficiency. The temptation is to pitch one flagship AI agent across the whole shared-services center — impressive on a slide.

Koko: And almost certain to stall. In build, in cost, in governance. You have just made your hundred-day plan dependent on a single complex system that nobody has run before at this company's scale.

Max: So what is the senior deliverable instead?

Koko: A portfolio of right-sized solutions. Most of the volume handled deterministically or with retrieval and fixed workflows. A couple of bounded agents pointed only at the true-judgment queues — complex disputes, exception-heavy onboarding. And a map: every stream, its rung, its owner, its controls.

Max: That map is actually what makes it defensible to the investment committee.

Koko: Because it connects to the numbers they underwrote the deal on. Faster, cleaner dispute resolution pulls down days sales outstanding — that frees working capital. The cheaper rungs protect EBITDA. Right-sizing the inbox is not a technical nicety. It is how the disciplined non-agent call becomes a number the board can see.

Max: And it protects the value-creation timeline from a stalled mega-build.

Koko: Which is the other thing the investment committee cares about. A hundred-day plan that slips because the flagship agent is still in build is a very uncomfortable conversation.

Max: Alright. Let me try to land the handful of things I am carrying out of this whole lesson.

Koko: Go for it.

Max: First: use the minimum sufficient rung. Deterministic if you can, retrieval if you need it, a fixed workflow before you reach for an agent, and an agent only when the work genuinely requires dynamic judgment under uncertainty.

Koko: That is the ladder, yes.

Max: Second: the no-agent call is a senior call. Saying 'this stream belongs on a deterministic path' is not risk aversion — it is better engineering.

Koko: And often higher reliability, lower cost, and easier auditing. A trifecta.

Max: Third: right-size each stream separately. The answer to 'should we use an agent' is almost never one yes or one no — it is a map.

Koko: And sometimes that map splits a single stream into two paths, because most of the volume is clean and only the tail needs judgment.

Max: Fourth: multi-agent is a tradeoff you justify, not a trophy you award. Real specialization, real context isolation, real ownership boundaries — that is the evidence you need. Not a slide about maturity.

Koko: And in professional services specifically: the map is the deliverable. Every stream, its rung, its owner, its controls. That is what survives a board review and a hundred-day timeline.

Max: Honestly, the reframe that stuck with me most is the staffing analogy. You do not put your most expensive partner on every task. You match the task to the cheapest resource that can do it reliably, and you reserve the senior judgment for what actually requires it. Agents are expensive partners. Use them where they earn it.

Koko: And when you do use one, you bound it — tools, hard limits, a human approval gate on anything consequential. Agency is a design choice you earn, not a default you accept.

Max: Agent or not — it is a question worth asking every single time.

Koko: Every single time. Alright — that is the full lesson. You have the instincts. Now go use them. If you want to keep going, the guided journey and the hands-on labs are waiting for you at KokoAI Academy — koko knows dot A I. You have everything you need to build things that actually work.