The demo always works.
Someone wires up an agent over a weekend. It reads an invoice, matches it to a PO, flags the exception, drafts the chase email. In Monday’s meeting it does in four seconds what used to take an AP clerk most of a coffee break, and the room lights up. Ship it.
I’ve been in that room more times than I can count, and the room is never wrong about the agent. The agent is great. What the room is wrong about is what happens next.
What happens next is that everyone else builds one too. Six months on, the same company is running dozens of agents. A sourcing agent. A contract-clause checker. Three separate invoice agents, built by three teams who never spoke. I read a case study recently where one manufacturer proudly reported it had stood up twelve agents, four of them fully custom, as if the count itself were the achievement. Each of those agents passes its own tests. Each does its job. And yet cycle times are down while realized savings haven’t budged, nobody can say why a supplier got auto-approved last Tuesday, and the integration queue for the next agent is now a quarter long.
Nothing is broken. Everything is working. And the business is quietly running up a tab it can’t see on any dashboard.
That tab is agent debt. If you spent the last decade fighting technical debt in software, you already know the shape of this. You just haven’t met the agentic version yet, and it compounds faster, hides better, and sends its bill to a different department.
What it actually is
Here’s the definition, and I’ll stand behind it for the rest of this piece:
Agent debt is the compounding operational liability an enterprise takes on when it deploys task-doing AI agents faster than it can govern, orchestrate, and tie them to business outcomes — the procurement-and-operations equivalent of technical debt in software.
One disambiguation first, because the phrase is getting crowded. Engineers have started saying “agent debt” to mean the mess that coding agents leave in a codebase: the brittle 20% they skip, the architecture they quietly drift away from between sessions. Fair enough. That’s a software problem and it has its own literature. I’m pointing at something bigger and further upstream: the debt that accrues in your operating model when autonomous agents start running real business processes. Same metaphor, different floor of the building. The engineers’ version slows your developers. This one erodes your outcomes.
The metaphor is worth getting right, because the original was sharper than most people remember. When Ward Cunningham coined “technical debt” back in 1992, he wasn’t talking about sloppy code. He was talking about the distance between what your software does and what you’ve since learned it ought to do. A little debt is fine, even shrewd, as long as you pay it back before the interest gets ahead of you. The first shortcut was never the problem. The problem was leaving a hundred of them unpaid until changing anything cost more than it was worth.
Move that up a level and you’ve got agent debt: the distance between what your agents do and the outcomes your business actually needs. And like Cunningham’s version, no single agent is the culprit. It’s a crowd of agents, each doing something locally reasonable, inside a structure that was never designed to add them up.
Where it Comes From
The origin story barely varies, and it’s architectural, not careless.
You start with narrow agents because narrow agents are easy. A task is a clean, bounded thing: “pull the line items,” “draft the RFP,” “check this clause against policy.” It demos on a Friday. It’s a unit one team can own end-to-end. So that’s what gets built, over and over: task-shaped agents.
But your business isn’t task-shaped. It’s outcome-shaped. Nobody gets paid to “pull line items.” They get paid to close the books clean, capture the savings the team negotiated, keep the company out of regulatory trouble. Outcomes run across agents, across teams, across the seams between systems.
Which means the instant you have a second agent, you’ve manufactured a problem that didn’t exist with one: who owns the space between them? The invoice agent is correct. The payment agent is correct. The outcome you actually wanted, a correct and compliant payment that lands on time, lives in the handoff. And no agent owns the handoff. Everything passes, and the thing you cared about still doesn’t happen. Locally correct, globally broke.
The reason this is inevitable rather than just unlucky is that every working agent recruits the next one. The demo magic is real and it’s a little addictive. One narrow win gets read as proof the whole approach scales, so every team goes and builds their own. Nobody ever decides to take on agent debt. They decide to ship a parade of obviously-good agents, and the debt is just what that parade leaves behind when there’s no orchestration underneath it.
How the Architecture Writes the Check
This is the part worth slowing down on, because the size of your eventual bill has surprisingly little to do with how clever your agents are. It tracks four architectural decisions instead.
The first is wiring. Connect agents point-to-point, each one lashed directly to source systems and to each other, and your integration surface grows with roughly the square of the agent count. Two agents, one seam. Ten agents, a tangle. Anyone who lived through the microservices sprawl of the 2010s feels this in their teeth. It’s the same combinatorial mess that drove everyone toward shared buses and service meshes, except now the “services” are non-deterministic. The eleventh agent is harder to add than the first, not easier, and that curve only bends one way.
The second is memory, or the lack of it. Agents that don’t share persistent context rebuild their understanding of the world on every run. With no common memory and no written spec, two agents end up reasoning from different assumptions about the same supplier, the same threshold, the same contract, and they drift apart quietly over weeks. Drift is the agentic cousin of config sprawl. Not one dramatic failure. A thousand small divergences that, added together, make the whole system impossible to reason about.
The third is non-determinism, and this is the expensive one. Old-school workflow orchestration was deterministic. Step A produced a known output, step B ate it, and you could test every branch because you knew every branch. Agent chains don’t work like that. Each agent carries some probability of doing almost the right thing, and those probabilities multiply down the line. A 95%-reliable agent sounds wonderful right up until it’s the fourth handoff in a sequence, where your end-to-end reliability has quietly slid to around 80%. Worse, because every individual step “worked,” the failure is nearly impossible to trace. The workflow doesn’t stop. It just occasionally does the wrong thing, silently, and bills you for it later.
The fourth is incentives. When each agent is tuned to nail its own narrow objective, you get a slow-motion prisoner’s dilemma. Every agent, optimizing for its own success, finds little ways to push cost or risk onto the rest of the system. The contract agent moves fast and clean; the compliance agent inherits whatever it skipped. Each piece looks great in isolation, which is precisely why the whole gets more fragile as you add pieces.
There’s a diagram a lot of us remember from the machine-learning years. In 2015 a Google team published a paper on the hidden technical debt of ML systems, and the image that stuck was a tiny box marked “ML Code” drowning in enormous boxes for everything around it: data plumbing, configuration, monitoring, serving. The lesson was that the model was the small part.
Agents are the same picture with an even smaller box. The agent itself, the prompt and the model call and the tool definitions, is the easy 5%. Whether you’re piling up debt is decided almost entirely by the other 95%: orchestration, shared memory, governance, observability, the integration fabric. Which is the one line I’d put on a wall if I could only keep one:
Agents are cheap. The space between them is expensive.
Hold onto that, because it explains the thing happening across our entire category right now.
Now they’re Selling you The Shovel
Here’s where I get a little annoyed.
Almost every major source-to-pay suite has shipped some flavor of a do-it-yourself agent studio. A no-code, drag-and-drop, build-your-own-agent canvas. The pitch is irresistible and lands in every boardroom: don’t wait on a roadmap, you build the agents, one per team, as many as you like. It demos beautifully. It expands seats and consumption. And it is, structurally, a machine for manufacturing agent debt at industrial scale.
Read more: Pioneering Procurement: Building Your First Agentic AI Use Case
Think about what a DIY studio actually optimizes for. The rewards count. The success metric the vendor quietly cares about is agents created, because that’s what drives expansion. So you get the very thing we just diagnosed, except now it’s a feature: every team spinning up its own narrow, task-shaped agents, point-wired, stateless, each one locally correct, with nobody anywhere owning the outcome. That manufacturer with twelve agents, four custom? That’s not a cautionary tale to the studio vendor. That’s a case study. That’s the slide.
Then comes the second half of the move, and once you see it, you can’t unsee it.
The same vendors are standing up forward-deployed engineering teams. FDEs, borrowed straight from the AI-native playbook, sometimes literally embedded on your premises. The framing is “we’ll help you get value from your agents.” The reality, often, is a paid human cleanup crew for the debt their own studio encouraged you to take on. Some vendors are refreshingly open that their real differentiator is software plus a standing services arm; others dress the same arrangement in newer language. Either way, look at the shape of it. Sell the customer a tool that maximizes agent sprawl. Then sell the customer the engineers to untangle the sprawl. The disease and the cure, same invoice, recurring.
I’m not saying these studios are useless or that the engineers aren’t talented. They’re often excellent. I’m saying the incentive is upside down. A business model that profits from agent count and then profits again from agent cleanup has no reason to ever help you carry fewer, better-orchestrated agents. The debt isn’t a bug in that model. It’s the annuity.
(That dynamic deserves its own teardown, and it’s getting one. We’re writing a full piece on the DIY-studio-plus-FDE play next. This is the trailer.)
Why it’s Worse than Tech Debt
If the comparison stopped at “it’s like technical debt,” I’d be calm about it, because we eventually got good at tech debt. We built refactoring, test suites, CI, a whole discipline. Agent debt is harder, and on three specific counts it’s worth being honest about why.
The interest rate is higher. Technical debt sits still until you touch it. A bad module doesn’t rot further over the weekend on its own. Agent debt does, because the agents are autonomous. They keep acting, keep drifting, keep making decisions inside the flawed frame whether or not anyone’s watching.
It bills the wrong department. Tech debt shows up as slower engineering velocity. Painful, but contained, and visible to exactly the people who can fix it. Agent debt shows up as savings leakage, compliance exposure, and a decision no one can defend when the auditor asks. That lands on the CPO and the CFO, written in a language the team that built the agents may never read.
And it’s invisible by design. Every agent passes its own test. That’s the trap in one sentence. The whole danger of agent debt is that the local light stays green while the global outcome quietly goes red, and there’s no single broken thing to point a finger at, so it grows until the bill arrives all at once.
You Don’t Pay it Down by Adding Agents
When the outcomes won’t land, the reflex is to build another agent. An orchestrator to herd the others. A reconciliation agent to mop up the drift. Don’t. You can’t borrow your way out of debt, and you can’t agent your way out of agent debt. One more agent is one more box in the expensive space between the boxes, and if you bought it from a studio whose business depends on box count, you’ve just made a payment on the wrong loan.
You pay it down by changing the frame the agents live in. Orchestrate instead of proliferate: one coordinating layer that answers for the outcome, not a swarm of point bots each answering for a task. Architect so the system’s success metric is realized savings or clean compliance rather than tasks completed. Build governance and observability into the platform instead of bolting them on after agent number eleven. Give the agents shared, persistent context so they stop re-deriving the world and drifting away from each other.
Put plainly: agents that only do tasks accrue agent debt, and an architecture built for outcomes pays it down. That’s the whole reason we built Zycus Agentic AI around Intake-to-Outcomes rather than around a catalog of bots and a studio to crank out more of them. Not because orchestration demos better, because it doesn’t. A single clever agent always wins the demo. It’s that the demo is where agent debt is conceived, and the outcome is where it finally comes due.
So next time an agent dazzles the room in four seconds, ship it. I mean that. Just ask the quieter question first: who owns the outcome this agent is now part of? And if you’re being handed a build-your-own-agent studio with a forward-deployed cleanup crew on standby, ask the even quieter one: whose balance sheet does my agent debt actually sit on, and who’s profiting from it staying there?
If the honest answer to the first question is “nobody yet,” you didn’t ship an agent.
You opened a line of credit.
Agent debt is the operating-model cost of deploying agents faster than you can orchestrate them toward outcomes. For the practitioner’s field guide, including a self-assessment you can run on your own stack, read Do You Have Agent Debt? A CPO’s Self-Assessment and the Agent Debt glossary definition. The full teardown of the DIY-studio-and-FDE model is coming next.
Related Reads:
