The very expensive router

The agentic AI pitch goes like this: LLMs can reason, so let's give them tools and let them do things. Connect them to APIs, databases, file systems, email. Let them take actions in the world. The term "agentic" became the defining buzzword of 2025, and it shows no signs of fading in 2026.

Here's what happened next. The LLMs couldn't reliably do things. They hallucinated tool calls. They ignored system prompts. They deleted what they shouldn't have touched and left untouched what they should have changed. The models that could write a convincing essay about database management would, when given actual database access, do things no sane engineer would allow.

So the industry did what it always does. It built guardrails.

Advice, then physics

The first guardrails were advice. System prompts that said "never delete production data." Instructions that said "always ask for confirmation before sending." These are speed limit signs. They address the driver, not the road.

LLMs ignored them. Not always, not even most of the time, but enough to be dangerous. Enough that nobody sane would give an LLM unsupervised access to anything that matters.

The response was to move from advice to constraint. Typed schemas that reject malformed tool calls. Approval flows that require human sign-off. Permission systems that physically prevent access to destructive operations. Sandboxed environments where the worst-case outcome is bounded.

This is where the smartest thinking in the agentic space has landed. Jay Springett's recent "Hard Worlds for Little Guys" essays are a good example: drawing on fifty years of interactive fiction design, he argues for promoting constraints from advice into physics. A speed limit sign can be ignored; a speed bump cannot. Build the constraint into the road, not into the driver's instructions. It's the same intuition behind typed tool schemas, sandboxed environments, and every "shift left on safety" argument in the agent ecosystem.

But there's a problem with the metaphor that reveals a problem with the whole approach.

Speed bumps aren't physics

A speed bump doesn't physically prevent you from going fast. You can drive over a speed bump at 60 mph. You'll destroy your suspension, but the bump doesn't stop you. What it does is teach you. You hit it once at speed, you experience the consequence, and you slow down next time. A speed bump is a teaching mechanism. It works through negative feedback, not physical impossibility.

A bowling bumper rail is actual physics. The ball literally cannot go in the gutter. The constraint is absolute. But bumper rails have a cost that speed bumps don't: they prevent you from learning to bowl. A kid who bowls with bumper rails forever never develops the skill to keep the ball in the lane. The constraint that prevents failure also prevents growth.

The framing is "physics over advice." But the interesting question isn't which one to use. It's what happens after you've used it. Advice doesn't work because LLMs ignore it. Physics works but prevents adaptation. And here's where the whole agentic movement gets stuck, because nobody is asking the obvious next question: what kind of constraint teaches?

There's no good physical-world metaphor for this. A constraint that adapts to demonstrated competence doesn't exist in roads or bowling alleys. It only exists in software. And almost nobody is building it.

The contradiction

Set the metaphors aside. Here's the logic of the agentic movement, stated plainly:

Step 1: We observe that LLMs can't reliably follow simple instructions. A system prompt that says "don't do X" is insufficient because the model sometimes does X anyway.

Step 2: We conclude that we need harder constraints. Typed tool schemas, permission boundaries, human-in-the-loop approval.

Step 3: Within those constraints, we give the LLM a menu of tools and trust it to choose the right one for the situation. We trust it to decompose a complex task into subtasks. We trust it to decide when to ask for help and when to proceed autonomously.

Notice what happened between steps 2 and 3. In step 2, we acknowledged the LLM can't reliably follow the instruction "don't delete the database." In step 3, we trusted it to evaluate a novel situation, select from multiple possible actions, and execute a multi-step plan. We moved from "it can't follow simple advice" to "let's trust it with complex judgment."

The defense here is that these operate at different levels. The constraints handle the dangerous stuff (can't drop a table), and the LLM only makes choices within the safe zone (which query to run). Fair enough. But watch what happens to that safe zone over time. Every time the LLM makes a bad choice within the "safe" space, the response is to shrink the space. Restrict the parameter ranges. Add validation. Pre-define the acceptable workflows. The levels-of-abstraction defense is technically correct at any given snapshot, but the dynamic is what matters: the safe zone converges toward a space so small that the judgment required to navigate it is trivial.

You can watch this happen in real time with customer service agents. Version one: the LLM has access to the full ticketing system and can compose freeform responses. It occasionally refunds $10,000 to the wrong customer or promises things the company can't deliver. Version two: refund limits, approved response templates, escalation triggers. Version three: the LLM picks from a menu of pre-written resolution paths based on ticket classification. By version four, the "agent" is a natural language classifier feeding a decision tree. The flexibility that justified using an LLM in the first place has been engineered out of the system.

The same pattern plays out in coding agents. Early versions let the LLM run arbitrary shell commands and edit any file. After enough incidents of deleted directories and corrupted configs, the tools get scoped: approved file paths, sandboxed execution, mandatory diffs for review. Each round of constraint pushes the agent closer to an autocomplete engine with extra steps.

Choice-making is harder than instruction-following. Following the instruction "use tool A when the user asks about their calendar" is easier than evaluating an ambiguous user request, determining which of twelve available tools is most appropriate, constructing the right parameters, interpreting the result, and deciding what to do next. If the model fails at the easy version, the hard version doesn't get easier just because you've removed the dangerous options.

The answer, of course, is that it often doesn't. So we add more constraints. We reduce the tool set. We narrow the acceptable parameter ranges. We add validation at every step. We pre-define workflows and let the LLM choose between them rather than compose actions freely.

Follow this logic to its endpoint. Each round of constraint narrows the action space. The tool menu gets smaller. The permitted operations get more specific. The pre-built workflows get more rigid. Eventually, the action space is so narrow that the LLM is choosing between three pre-defined paths, each of which is a deterministic sequence of API calls. At that point, you have a very expensive if/else statement.

The circle

Here's the full loop:

Deterministic automation: reliable but rigid. Can't handle novel situations. Can't adapt.

"We need AI flexibility!" leads to LLM agents: flexible but unreliable. Can handle novelty but might hallucinate the wrong tool call or ignore a critical constraint.

"We need guardrails!" leads to Heavily constrained LLM agents: less unreliable, but also less flexible. The constraints that prevent failure also prevent the adaptability that was the whole point.

More constraints lead to Deterministic automation with an LLM in the middle: rigid, reliable, and expensive. The LLM contributes natural language understanding and some routing judgment, but the action space is narrow enough that a much smaller, cheaper model could handle most of it.

The industry completed a circle. It started with deterministic automation, added an LLM for flexibility, constrained the LLM until the flexibility disappeared, and arrived back at deterministic automation that costs significantly more to run. The LLM in the middle is doing expensive next-token prediction to select between options that could be resolved with pattern matching.

Look at the actual products. Most "AI agents" are workflow automation platforms. The tools are deterministic, the APIs are deterministic, the databases are deterministic, and the one non-deterministic component is the LLM making the routing decision. The unreliable part is the part making choices. Everything else would work fine without it.

The question nobody is asking

The entire agentic discourse is about the shape of the cage. Harder constraints or softer ones. More tools or fewer. Tighter approval flows or wider autonomy. Physics or advice. Every proposed solution is a different configuration of the same architecture: a frozen model operating within static boundaries.

Here's the question that's missing: what if the system actually learned from its mistakes?

Not "learned" in the marketing sense. Not periodic fine-tuning, not RLHF on curated examples, not prompt optimization from golden samples. Learned in the operational sense.

The objection here is obvious: "We do learn from outcomes. It's called RLHF." And RLHF is real. It genuinely improves models between versions. But RLHF is population-level learning on a batch timescale. It takes thousands of human preference signals, aggregates them, and produces a better model for all users weeks or months later. What it doesn't do is help this agent on this task based on this outcome right now. If the agent chose the wrong tool for your specific request, RLHF will not prevent it from making the same mistake on your next request. It might prevent it for the next model generation, trained on enough similar examples, deployed on its own schedule. That's a different category of learning entirely.

The agent chose tool A and it failed. Next time it encounters a similar situation, it's less likely to choose tool A. The agent successfully completed a three-step workflow for a particular type of request. Next time it recognizes that request type, it's more confident in that workflow. The constraint boundary reflects demonstrated competence, not a static configuration someone set in a YAML file.

Research prototypes have demonstrated the principle. Voyager accumulates a skill library in Minecraft. Reflexion writes verbal self-critiques after failures and feeds them into future attempts. These are real, and they work in their narrow domains. But no production agent platform has absorbed these ideas. The standard stack can't, because every layer assumes a frozen model. The research proves the concept while the industry ships the opposite. Every agent handles its 1,000th task with the same capabilities and the same constraints as its 1st. All improvement comes from humans. Humans updating the prompts, humans refining the tool schemas, humans tightening the guardrails. The agent itself is a static participant in a process that changes only when someone manually changes it.

The reason the agentic movement is going in circles is that it's trying to solve a learning problem with architecture. Better cages don't make the thing inside the cage smarter. Harder physics don't teach the agent to bowl. The exit from the loop isn't a better configuration of constraints. It's a system where the constraints reflect what the agent has actually demonstrated it can do.

Why the industry can't see this

The agentic AI ecosystem is built on a specific stack: LLM providers offer models via API, framework developers build orchestration layers, and product companies assemble tools and workflows on top. Every layer of this stack assumes a frozen model. The LLM provider ships a fixed model. The framework routes requests to that fixed model. The product wraps the fixed model in a fixed set of tools.

Learning from interaction would require a layer that doesn't exist in this stack. Not a bigger context window stuffed with interaction history, and not a vector database of past conversations retrieved by similarity. Something structurally different: a component that sits between the model and the tools, tracks whether its decisions actually worked, and adjusts future behavior based on what it finds.

But building a system where interaction drives learning is harder than anything else on the agent roadmap. Harder than adding tools, writing better prompts, or implementing approval flows. So the industry keeps iterating on the cage.

Where this goes

The agentic movement will produce useful products. Natural language interfaces to existing workflows have genuine value. Nobody should dismiss that.

But the trajectory is clear. "AI agent" as a category will quietly converge toward what it actually is: natural language automation. The LLM handles parsing and routing. Everything else is deterministic. The marketing will still say "intelligent agent" and "autonomous AI," but the architecture will be a routing layer with a language model at the front door.

And the circle will keep turning. The frameworks will change, the buzzwords will rotate, but the loop stays the same. Because the question the industry refuses to ask is not "how do we build a better cage?" It's "can the thing inside the cage grow?" And if it can't, you don't have an agent. You have a very expensive router, and everyone's arguing about the enclosure.

The exit from the loop was never a better constraint. It was always learning.