I did a deep research dive into the economics. I expected the story to be about expensive tokens and infrastructure bills. It is not. The story is about a trap.

Everything that makes agents cheaper to build is making them more expensive to run.

I am calling it the Deflation Trap. It runs through every layer of what I have been mapping as the Agent Cost Stack.

The Jevons Layer

Per-token costs have dropped roughly 1,000× in three years. GPT-3-equivalent inference fell from $60 to $0.06 per million tokens. The decline runs at roughly 10× per year, faster than Moore’s Law.

And yet total AI spending surged 320% in 2025. Average enterprise LLM spending nearly tripled from $2.5 million to $7 million per company.

This is Jevons paradox applied to intelligence. When inference gets cheaper, usage does not stay flat — it explodes. Agentic workflows with dozens of reasoning steps per task. AI on every customer interaction. Use cases that were uneconomical last quarter become default this quarter. Demand is super-elastic.

The math of agentic loops makes it concrete. Agents operate in multi-turn reasoning where every turn reprocesses the entire conversation history. Turn 10 costs 10× what a single generation does. Cumulative spend across 10 turns is 55×. Reasoning models generating thousands of internal thinking tokens can require up to 100× more compute than a single pass. One complex agentic task can burn $5–$8 in inference alone.

Mitigations exist. Context caching from major providers cuts input costs 75–90%. Model routing — sending most queries to cheap models and only complex ones to frontier — cuts costs 35–85%. Semantic caching reduces redundant calls 20–73%. These make the growth curve manageable. They do not flatten it.

The cheaper the tokens get, the more tokens get used.

The Infrastructure Layer

The floor has collapsed. Serverless vector databases start under $25 a month. Object-storage-first options run at $70 per terabyte versus $1,600–$3,600 for RAM-based incumbents. Production RAG systems have been documented running for under $10 a month.

The $7,000–$21,000 monthly figure in enterprise analyses reflects enterprise procurement, not technical necessity. The actual range by agent complexity:

• Simple FAQ or support bot: $50–$500/mo

• RAG-based knowledge agent: $200–$2,000/mo

• Multi-step agent with tool calling: $500–$5,000/mo

• Enterprise multi-agent system with compliance: $5,000–$30,000/mo

A collapsed floor means more projects get greenlit. More projects get greenlit means more production systems to maintain. The infrastructure cost per agent went down. The total infrastructure bill went up.

The trap here is premature optimization — architecting for scale that does not exist yet. Know the actual volume before committing to architecture.

The Drift Layer

This is the layer most teams underestimate because it does not show up in a pricing calculator.

Agents are nondeterministic. A demo that works 80% of the time is impressive. A production system that fails 20% of the time is a liability. And agents drift. Prompt behavior decays. Model providers ship silent updates that change output quality. In long-lived sessions, system prompts receive roughly 1% of attention weight in large context windows, causing agents to gradually ignore their own instructions. Retrieval accuracy drops 15–30% as context stretches.

Budget 10–20 hours of engineering time per month on prompt tuning and behavior testing. That is $1,000–$2,500 a month per agent. This cost holds regardless of how cheap the tokens get. Automated evaluation frameworks agree with human judgment at only fair-to-moderate levels — they are force multipliers for human review, not replacements.

The cost here is not compute. It is attention. Human attention to a system that will not stay where you put it.

The Migration Layer

Between early 2025 and early 2026, major providers executed 15+ distinct model deprecation events. Major agent frameworks shipped multiple architecturally breaking versions. A survey of 1,837 engineering leaders found that 70% of regulated enterprises rebuild their agent stack every three months or faster.

AI coding tools make individual migrations 10–20× faster. But migrations now happen quarterly instead of annually. Total maintenance spend stays stubbornly similar. The composition shifts from manual labor to AI tooling costs plus expanded review cycles. And the productivity gains themselves may be illusory: METR’s randomized controlled trial found that experienced developers using AI coding tools perceived themselves as 20% faster but were actually 19% slower on real-world tasks — a 39-point perception gap. If the tool that is supposed to make migrations cheap is not actually making them faster, the math gets worse.

This is where the trap is most visible. More gets built on shifting ground because teams believe AI tools make it cheap to migrate. The per-migration cost feels lower. The number of migrations rises. Net cost: flat at best. Net complexity: up.

The defense: architect for replaceability from day one. Abstract the model layer. Budget 1–2 model migrations per year, each consuming 1–2 engineering weeks.

The Governance Layer

The EU AI Act is enforced starting August 2, 2026. It is real. But the cost most teams should worry about is not compliance — it is paralysis.

The Act uses a risk-tiered structure. The heavy burden risk management systems, conformity assessments, documentation maintained for ten years applies exclusively to high-risk systems under Annex III: HR screening, credit scoring, healthcare decision support, law enforcement. Only 5–15% of AI systems qualify. Annual compliance costs for those: roughly €29,000 per system. A Jira summarizer, a customer support bot, an internal knowledge agent none of these are high-risk.

Minimal-risk systems face no specific obligations beyond AI literacy. Limited-risk systems, including chatbots and virtual assistants, face only transparency requirements. One requirement is non-negotiable across all tiers: Article 50 requires that any system interacting with people discloses it is AI. A disclosure banner. A first-message label. Low-cost design change, easy fine if you miss it. Bake it in from day one.

The real governance cost for most teams is not the regulation — it is the months of delayed launches while legal reviews whether a low-risk agent needs high-risk treatment. If you are building in Annex III domains, budget for governance. If you are not, do not let regulatory anxiety kill a high-ROI project.

On the US side, govern agents with the same access controls you apply to employees. That principle holds regardless of jurisdiction.

The Pattern

The cost stack varies by an order of magnitude depending on agent complexity. A support bot on serverless can run for a few hundred dollars a month. An enterprise multi-agent system with compliance can run $20,000+. But the 65–75% operational share holds across both. The absolute numbers change. The ratio does not.

Every reduction in the cost of building creates more systems that need the expensive work of running. Tokens get cheaper, so architectures consume more. Infrastructure gets cheaper, so more projects ship. Migrations get cheaper per instance, so they happen more often.

Klarna learned this the hard way. The build was a success story. The run was an overcorrection that required hiring humans back. The long tail of nuanced, high-empathy interactions, refund disputes, billing confusion, frustrated customers who needed to feel heard, could not be cost-optimized away. The agent was not the problem. The budget that ignored the run was.

What to Do Before You Build

Five things to budget for before writing the first prompt:

1. Model the run cost, not the build cost. If 65–75% of your total spend will be operational, your business case should be mostly about ops — not the sprint to ship.

2. Measure your actual token volume before optimizing. Context caching and model routing are powerful, but premature optimization is its own cost. Know the volume first.

3. Budget human hours for drift. 10–20 hours per agent per month. Automated evals help. They do not replace the human in the loop.

4. Abstract the model layer on day one. You will migrate at least twice a year. Make it a configuration change, not a rewrite.

5. Classify your risk tier early. Five minutes with the Annex III list can save months of legal review. If you are not high-risk, move.

Every efficiency in building is a tax on running. The only way through the Deflation Trap is to budget for the run before you start the build.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

The premise came from a research paper. “The Orchestration of Multi-Agent Systems” provides a framework for building coordinated AI systems, and it cites a motivating claim: distributed collectives of smaller, specialized agents often outperform a single all-purpose deployment. Instead of one AI doing everything, you break the problem into parts, give each part to a specialist, and coordinate them through an orchestrator.

It sounds right. The way a hospital works. The way an engineering team works. Specialization plus coordination equals better outcomes.

But sounding right is not the same as being right.

So I tested it.

Three agents. One finds flights and hotels. One builds the itinerary. One tracks the budget. A deterministic Python orchestrator coordinates them, enforces budget gates, and controls what each agent can see. Real flight prices from web search, not training data. About 1,500 lines of Python, no frameworks, every design decision visible. The point was to understand orchestration by building it.

The paper formalizes orchestration as seven responsibilities planning, policy, execution, control, state, knowledge, and quality, each mapping to a method or component in the code. The five most important:

class Orchestrator:
    def plan(self, goal) -> list[Task]:       # Pi: decompose the goal
    def check_policy(self, category, price):   # Phi: enforce constraints
    def _execute_task(self, task, agents):      # E: dispatch to agents
    def _prefetch_search_data(self):           # K: fetch real prices
    def _assemble_plan(self) -> TripPlan:      # Q: validate and assemble

The most important design decision is what each agent can see. One shared notebook, three different windows into it. The notebook is a Pydantic model with a get_view method the paper’s observation function that returns a typed dataclass per agent.

class SharedNotebook:
    def get_view(self, agent_name) -> ScoutView | PlannerView | BudgetView:
        if agent_name == "scout":
            return ScoutView(
                budget_limits=...,          # flight/hotel/activity ceilings
                flight_search_results=...,  # raw search data
                hotel_search_results=...,
            )   # does NOT include: itinerary, decisions, other agents' outputs

        elif agent_name == "planner":
            return PlannerView(
                confirmed_bookings=...,     # only APPROVED decisions
                per_day_budget=...,         # remaining ÷ days
                attraction_search_results=...,
            )   # does NOT include: rejected options, raw prices

        elif agent_name == "budget":
            return BudgetView(
                all_prices=...,             # every price from every source
                running_total=...,
                budget_ceiling=...,
            )   # does NOT include: activity names, preferences

        else:
            raise ValueError(f"Unknown agent: {agent_name}")

Scout never sees what the Planner decided. Budget never sees which temples were chosen. Each agent gets only what it needs to do its job.

Then I built a single-agent version. Same model, same search data, same instructions. One prompt that does everything at once. I ran both systems across three cities (Tokyo, Paris, Bangkok), two runs each, and compared what they found.

The sample size is small. Two runs per city gives you direction, not proof. But the patterns were consistent enough to be worth sharing.

The single agent was faster every time. About 100 seconds versus 130. It used fewer tokens. About 10,000 versus 14,500. On pure efficiency, the generalist wins.

But then I looked at the flight prices.

For Paris, both systems found the same $1,199 flight. Dead tie, both runs. The SFO to Paris route has limited options. When the answer is obvious, specialization adds nothing.

For Tokyo, the single agent found cheaper flights. $946 average versus $1,144. Multi-agent is not always better. My read on why: Tokyo is a well-known route with a moderate number of carriers. The search results contained enough information for a generalist to find the best option without deep analysis. But the multi-agent system’s rigid pipeline introduced information loss at each handoff. Specifically, a method called _approve_best_options picks flights[0] from Scout’s sorted list and marks everything else as rejected before Budget ever sees the alternatives. The orchestrator pre-decides the winner. Call it the Lossy Handover problem: if your orchestrator is too rigid, it dumbs down the specialists. The single agent saw everything at once and acted as its own soft orchestrator, weighing all options simultaneously. Structure helped in Bangkok. In Tokyo, it got in the way.

For Bangkok, the multi-agent system found flights at $293. The single agent picked $885. Consistent across both runs. A $592 difference on a $1,500 budget trip. (All prices are search-reported via Tavily, not verified bookings. The exact numbers will differ if you run this tomorrow. What matters is the gap and what caused it.)

Bangkok has dozens of carriers, multiple layover options through Asian hubs, and a wide spread of price points. When Scout’s only job is analyzing flight options, it digs deeper. It found a route the single agent missed entirely. The single agent was juggling flights, hotels, itinerary, and budget at the same time. It picked a reasonable option and moved on.

That is the pattern.

Here is the data across all six runs:

Averages across two runs per city. All prices from Tavily web search, not verified bookings.

The multi-agent system used 40-50% more tokens every time. It was slower every time. But for Bangkok it saved $592 on a $1,500 trip. The token overhead cost maybe fifty cents.

It is not about task complexity in the abstract. It is about search space. When there are many valid options spread across a large space, a specialist who does nothing but search will find things a generalist misses. When the answer is obvious or the space is small, the overhead is not worth it.

There were other findings worth noting.

Restricting what each agent can see (what multi-agent theory calls the observation function) reduces context size substantially. Budget does not need to process itinerary descriptions. Scout does not need to see rejected options. Less context, smaller prompts, lower cost. I did not run a controlled experiment isolating this variable, but the multi-agent token counts (averaging around 14,500 across all runs) are spread across four sequential calls, each with a focused prompt. A single prompt carrying all the context for all three roles would be larger than any one of them.

But the cost savings is not the most interesting part. The observation function is also a least-privilege boundary. Budget cannot see which temples were chosen or what the traveler’s personal interests are. It sees prices. That is all it needs and all it should have. In a system where agents might be backed by different models, different providers, or different trust levels, controlling what each agent can see is not just an optimization. It is a security and privacy decision. The same pattern that reduces token cost also enforces data isolation.

Here is how state flows through the system.

A note on the plumbing. The paper specifies two protocols underneath the diagram above. MCP (Model Context Protocol) controls tool access: only the orchestrator calls MCP servers, and agents only analyze data that was pre-fetched for them. A2A (Agent-to-Agent) is the message schema. Every inter-agent communication is a typed Pydantic model with a message_type (TASK_ASSIGN, APPROVE, REJECT), a confidence score, and a provenance chain. When Budget flags a flight, it returns a structured REJECT with confidence 0.95 and a list of reasons, not free text. That structure is what lets the orchestrator make deterministic decisions instead of parsing natural language.

I tested this directly. I injected a fake “$200 SCAM Air 999” flight into the search results for a Tokyo trip where real flights cost $800-1,200. The Budget agent flagged it with three warnings: the price was unrealistic for the route, the spending was near category limits, and the carrier name was suspicious. A specialist whose only job is checking numbers catches things a generalist might miss while multitasking. Interestingly, even the single agent did not use the scam price; the LLM had its own sense of realistic pricing. But the multi-agent system caught it earlier, at the budget gate, before it could reach the Planner at all. Defense in depth.

The paper warns about coordination overhead. I measured it directly in a head-to-head run on the same Tokyo trip:

The real cost is not in the messages between agents. It is in the latency of four sequential API calls and the context window space used to give each agent its filtered view of the world. The 130% token overhead is the coordination tax. Whether that tax is worth paying depends entirely on what the specialist finds.

I expected the premise to be right in a straightforward way. Multi-agent should beat single-agent.

It does. But only sometimes.

For Bangkok, the coordination tax was maybe fifty cents in extra tokens. The flight savings was nearly six hundred dollars. For Paris, the multi-agent system added cost and time for zero benefit. For Tokyo, the single agent did better.

The paper itself is a framework paper, not a benchmark paper. It gives you a vocabulary for decomposing orchestration into planning, policy, execution, control, state, knowledge, and quality. That decomposition is worth learning regardless of whether you end up building multi-agent or not.

I am not the only one finding this. A Towards Data Science analysis called it “The Multi-Agent Trap”, the tendency to treat every problem as a multi-agent problem when a well-prompted single agent would suffice. GitHub’s engineering blog put it bluntly: most multi-agent workflow failures come down to missing structure. The pattern I saw in my trip planner, structure helps when the search space is large, hurts when it is not appears to be general.

But the performance premise that motivates the framework needs a qualifier. Build multi-agent when the search space is large enough that focused attention finds what divided attention misses. When the cost of overlooking the best option exceeds the cost of looking twice.

For everything else, one agent is enough.

Paper: “The Orchestration of Multi-Agent Systems.” arXiv:2601.13671, January 2026.

I’ve been thinking about what it means to build software right now.

Not the mechanics of it. The models are capable. The tools are there. The barrier to shipping something has never been lower.

I mean the thinking behind it.

Because here’s what I keep coming back to. A generation of talented developers is about to build products shaped entirely by what AI can do today. They will look at the current state of the models, the current interfaces, the current capabilities and build for that. Ship fast, get users, feel the momentum.

And then the models will evolve. Faster than the roadmap expected. And the product built for today becomes the wrong answer for tomorrow.

That’s the trap the moment sets.

The mistake is building for the model, not the problem

When you pick up a powerful new tool, the temptation is to build something that shows off what it can do. This isn’t new. Early mobile apps were just desktop websites made smaller. Early cloud software was just on-premise software moved online.

The same thing is happening now. Products that are, at their core, a UI around a prompt. Clean. Functional. Sometimes impressive. But the value lives entirely in the model underneath and that model is not yours.

When the next model ships, and it will ship sooner than you think, what you built becomes a feature someone else offers for free.

If the model getting stronger makes your product weaker, you were never building a product. You were building a demo.

Ask a different question before you start

Most founders start with: what can I build with AI?

The better question is: what problem gets harder to solve as the world gets more complex and how do I sit in the middle of that in a way that compounds over time?

That question changes everything.

It moves you away from the interface and toward the workflow. Away from the feature and toward the process. Toward what the model cannot do alone, which is understand the specific, messy, human context of a particular industry.

The model knows everything about the average. It knows almost nothing about your specific customer’s specific situation. That gap is where you build.

What loses value. What doesn’t.

Software that manages lightweight engagement, scheduling, email workflows, basic coordination, is easy to migrate and easy to replace. An AI-native competitor can move that data in days and offer something better on top of it.

What keeps its value is software sitting inside complex workflows where the data is hard to replicate and built up over years of real operational use. Construction scheduling. Manufacturing supply chains. Property maintenance logs. The kind of data that doesn’t exist anywhere else because it was never meant to be shared. Because it lived in a process, not a database.

That’s the line.

You already have the advantage

Here’s what I think developers underestimate about this moment.

You already think in systems. You understand how things connect, where things break, what happens at scale. That instinct, applied not just to code but to how an industry actually operates, is exactly what this era needs.

The most defensible products being built right now are not the most technically impressive. They are the ones where someone understood a domain deeply enough to encode how it actually works. The exceptions. The edge cases. The judgment calls that happen between the steps. Into a system that gets smarter every time someone uses it.

That is builder’s work. Not just engineering. Thinking.

Build something that learns

Your product is not the features. It is what the system learns as people use it.

When a user corrects the output, that’s signal. When the system handles an edge case it hasn’t seen before, that’s signal. When a decision gets made inside the platform, that’s signal. That accumulated understanding of how a specific domain operates, that is the asset. Not the code.

No foundation model trained on the average of the internet will ever have it.

Own the workflow where the real work happens. Make your system the place where the truth of the business lives. And then let it learn.

What you build on day one matters less than what your system knows on day one thousand.

A generic agent can book the plumber. Only your system knows which plumber showed up last time, what it cost, and whether the problem came back. That memory is the moat. Not the capability.

The models will get stronger. Build for that.

A stronger model should make your product more powerful, not obsolete.

If the AI is the product, if the value is the generation, the summarization, the interface, a stronger model replaces you. That is a fragile position to be in.

But if the AI is the engine, if the value is the proprietary context, the workflow, the domain knowledge you have built up, a stronger model makes your engine more powerful. You get better without doing anything.

Build with the model. Not on it.

Don’t marry the engine either

One more thing, because this is where even careful builders get it wrong.

Treating AI as the engine is right. But don’t bolt yourself to a single engine.

The gap between the leading models has narrowed faster than most people expected. OpenAI, Anthropic, Google, they are closer to each other than they have ever been. And open-source models have caught up in ways that also give you something proprietary models don’t: full control of your data, no dependency on someone else’s pricing or terms.

Build a layer between your product logic and the model. Route the right tasks to the right model. Swap them out as the landscape shifts. The ability to always use the best tool at the right cost, without being locked in, is itself a competitive advantage.

Build the engine room, not the engine.

And if the inference cost is slowing you down right now, don’t let it stop you. There is no world where token costs stay this high. Every wave of compute has gotten cheaper faster than anyone expected. Build the right system. The economics will catch up.

Go where the model was never taught

The sharper version of “go where AI adoption is slow” is this: go where the training data never existed.

The plant manager who knows which supplier runs late in Q4. The process refined over twenty years on a specific floor. The supply chain nuance that lives in phone calls and institutional memory. That knowledge was never written down, never online, never in any training set.

The SMB running three shifts has heard of ChatGPT. They just don’t know how to make it work for their operation. Nobody has built for them. The big platforms are chasing enterprise. The funded startups are chasing legal and healthcare. The manufacturing floor is not in any of those conversations.

That is the opening. Go there first.

At the end of it

You are building something that helps a person simplify a hard process and you are using the most powerful tool in the history of software to do it.

Keep it that simple in your head.

Not “I am building an AI product.” Not “I am disrupting a vertical.” You are making something hard, easier. For a real person. In a specific situation. That the model alone cannot solve.

And when the AI gets it wrong and it will, your product needs to be the system that’s accountable. In manufacturing, in property management, in any operation where mistakes have real consequences, the winner isn’t the smartest model. It’s the one the customer trusts to own the outcome.

The developer who stays anchored to that, who doesn’t get seduced by what the model can do and loses sight of the actual human on the other side, is who builds something that lasts.

Go build. But build for the person, not the prompt.

Disclaimer: The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

AI hasn’t eliminated the role of the developer.

It has clarified it.

For a long time, software development was closely tied to writing code. Progress was measured in features shipped or lines written. AI changes that dynamic. When code can be generated quickly and at scale, the value of the developer shifts upstream, toward thinking, deciding, and guiding.

Clarity Is Built, Not Found

When I began working with AI coding agents, I expected speed to be the primary benefit. What stood out instead was how much it forced clarity. Early ideas weren’t incorrect, but they were often imprecise. When vague intent was passed to an agent, the output reflected that ambiguity immediately.

Iteration stopped being just a development loop and became a way to refine intent. Each prompt required answering basic questions: what problem is being solved, who it is for, and what “done” actually means.

Clarity wasn’t a prerequisite to building, it emerged through the process.

AI doesn’t replace thinking; it accelerates feedback on unclear thinking.

Architecture Still Matters (Even More Now)

As clarity formed, the instinct was to move faster. AI makes experimentation inexpensive. Different stacks and architectures can be explored quickly. But speed does not remove responsibility.

Decisions still carry tradeoffs across scalability, reliability, maintainability, cost and security. Security, in particular, is a day-zero concern.

Coding agents made it easier to pressure-test assumptions early: how systems behave at scale, where trust boundaries exist, what fails silently, and what becomes costly over time. Agents can surface options, but judgment remains human.

Architecture still matters perhaps more now than before because mistakes compound faster.

Quality Ownership Scales With Output

Another shift was the increased emphasis on quality. When an agent can generate large volumes of code quickly, blind trust becomes risky. Code review and testing moved from periodic activities to continuous ones.

Testing stopped feeling like overhead and became a guardrail.

I’ve caught more subtle bugs and security issues earlier in the process than I ever did before not because the agent is smarter, but because it forces me to review, question, and validate every assumption.

Increased output required increased ownership of quality.

Humans Are Still the Bottleneck

There is a human constraint that AI does not remove: fatigue.

AI compresses effort significantly, enabling large amounts of work in a single session. Momentum can be productive, but unmanaged momentum degrades judgment. Agents do not get tired; humans do.

Knowing when to pause and return with fresh context remains essential. Sustainable velocity matters more than heroic bursts of output.

Refactoring Without Fear

At the same time, refactoring became less intimidating.

When intent is clear, behavior is understood, and tests exist, rewriting becomes transformation rather than reinvention. Switching stacks becomes another iteration rather than a risk.

Confidence comes from reversible decisions.

From Code Producer to Decision-Maker

A conversation with a doctor reinforced this perspective. While AI can suggest multiple treatment options, choosing the appropriate one is where experience matters.

That distinction mirrors the evolving role of the developer.

AI can propose architectures and implementations. Determining which option fits the problem, the system, and the users and owning the outcome remains a human responsibility.

In the age of AI, developers shift from being primarily code producers to decision-makers. AI generates possibilities; it does not choose purpose.

Critical Thinking Is the Real Skill

If there is one thing AI can begin to replace, it is unexamined thinking not intelligence, but complacency masquerading as confidence.

AI executes exactly what is asked. The quality of the outcome is bounded by the quality of the reasoning behind the request.

This elevates the importance of critical thinking, security awareness, and system-level understanding. Developers become guides and guardians, shaping how systems should be built, not just what gets built. QA and UAT are no longer isolated phases but continuous responsibilities.

What you ask is what will be built.

What you clarify is what will be delivered.

Looking Ahead

This is still an early stage. What we see today is the current state. The future will evolve further, and some responsibilities may shift again.

What will not disappear is the need for judgment, context, and critical thinking.

AI does not replace developers.

It raises the bar.

And the developers who adapt, who think clearly, decide deliberately, and guide systems responsibly, will shape what comes next.

Learn to Learn Fast