The most expensive mistake teams are making with AI agents right now is treating them as microservices with a language model bolted on. The approach is understandable; microservices are the architecture most platform engineers know best, agents feel like services that happen to think, and the migration path looks familiar. But the analogy only holds long enough to lead you somewhere painful.
Microservices changed how software gets built. The idea was to help teams work independently, ship faster and scale efficiently. In those days, shipping software meant one giant codebase compiled together, tested together and released on 12- or 18-month cycles. Then the cloud came along, and teams needed to ship in weeks or days. The only way to do it was to split systems apart and let each piece move on its own schedule.
It worked, but the systems underneath stayed simple in one crucial way: they were deterministic. Distributed systems are hard, but the behavior was predictable. A service received a call and returned a result, and when it failed, it failed in milliseconds and threw an error you could see.
That is the assumption agents break. An agent workflow can run for hours or days, touch a dozen systems, and make a non-deterministic decision at step three that you don’t discover was wrong until step forty. Nothing threw an error, nothing lit up red on a dashboard; the process just quietly went the wrong way and kept going. Where a broken microservice pages you, a misbehaving agent sends a confident, wrong result and moves on.
This is why the microservices playbook both applies and doesn’t, and why “agents are just distributed services” is a trap. Agents do certainly build on microservice foundations, and many of the era’s lessons carry straight over. But the practices that were optional when systems were deterministic and short-lived are now mandatory, and even the ones that carry over don’t carry over cleanly. Treat agentic AI as just another microservice, and you’re making an architectural bet that will come due in the next 12 to 18 months.
Here are the lessons the agent era rewrites, and the ones it simply reinforces.
The Lessons That Get Rewritten
1. Durable execution stops being a pattern and becomes the runtime. This is the primary one, and it’s where the microservices instinct fails quietly. In a deterministic world, you could add resilience later, layering retries and queues around services that mostly completed on their own; the process finishing was the default, and durability was just another pattern. That default is gone. When an agent workflow fails five steps into a multi-day run, detecting that something broke is often harder than recovering once you know, and the resilience you meant to add later never gets added. It has to be part of the runtime from the start.
But here’s the part teams miss: it is not the same durability. The durable execution engines built for the microservices era assumed high concurrency and millisecond steps, payment flows, order processing, thousands of shorter workflows multiplexed per worker and agents violate every one of those assumptions. A single step might be a 45-second model call. Another might pause for hours while it waits on a human, and during that wait the process should be able to die and resume cleanly later, because nobody cares whether the resume takes seventeen milliseconds or two seconds. You cannot even replay a step and expect the same result, because the step is non-deterministic by nature. So the answer isn’t to adopt the durability you skipped; it’s that the durability layer itself has to be rebuilt for a workload it was never designed to carry.
2. Security and governance need a new model, not a stronger boundary. Microservices pushed authentication to the edge, a fence around the building that worked when the actors inside were fixed services you deployed. Agents can start other agents at runtime, which raises questions the boundary model simply can’t answer. Does the sub-agent inherit the same permissions? How do you trace what it did on your behalf three steps later? The model that fits is less a fence and more a series of locked doors, each requiring its own credential, with identity and cryptographic attestation following every step of every workflow, so you can prove not just who called, but what acted and what it was allowed to do. Most teams are still guarding the front door of a building that now rearranges its own rooms.
3. Observability has to reach every step, not just the endpoint. Operators need to retain control, and non-determinism makes that harder than it ever was for microservices. When something breaks in a 100-step workflow, an operator needs to see exactly where it broke and why, not just that it failed. Typically, a status indicator on a dashboard was enough when a service either returned or errored, but it is useless when the failure is a plausible-looking wrong turn ten steps back. Distributed tracing was essential for microservices. With agents, you’re no longer debugging whether a call succeeded; you are reconstructing why an autonomous system made the choice it did. That demands full visibility into every step an agent takes, as a first-class property of the platform rather than a log you grep after the fact. It’s the difference between the application performance monitoring (APM) tools of the microservices era and LLM observability tools in the agentic era.
These Three Demands Have a Name
Treated separately, recovery, per-step identity, and per-step visibility look like three infrastructure projects competing; they aren’t. They’re three faces of one capability the agent era requires, and it’s worth naming, because you can’t build toward something you can’t name.
Call it agentic durable execution: a runtime that automatically recovers from failures, carries autonomous AI agents and deterministic workflows to completion, and provides cryptographic, tamper-proof evidence of what happened. The first two answer the durability problem: the process finishes, while the third answers governance and observability. In a non-deterministic system, proving what an agent did and being able to see and trust it are the same requirement. It is not a feature you add to an agent framework; it is the layer the framework should be standing on.
The Lessons That Carry Straight Over
These three lessons didn’t change. They just matter more, because the cost of ignoring them is higher.
4. Complexity still demands a platform. Around 2010, most teams were stitching together virtual machines with Chef and Puppet, trying to build something that resembled a distributed application. Kubernetes won because it gave teams a platform layer that absorbed that complexity instead of asking every team to rebuild it. The same pattern is repeating now, as every organization races to stitch together agent frameworks and rebuild infrastructure a platform should already provide. The stakes are just higher this time, because the failures are harder to see coming.
5. Vendor lock-in is still costly. Committing to a single cloud provider’s agentic stack seems efficient until that provider has a regional outage and stalls every dependent workflow, and data sovereignty rules, especially across the EU, only add more pressure to a single-cloud strategy. The microservices lesson holds: architecture decisions made for short-term convenience almost always turn into long-term constraints.
6. Open standards still win the long game. The cloud-native projects that lasted, Kubernetes chief among them, were built in the open and governed by communities rather than single vendors, which is why they worked across environments instead of locking teams in. The agent world is already showing the same trait, with standards for how agents communicate and authenticate emerging through open governance rather than proprietary roadmaps. Betting against openness didn’t pay off for infrastructure a decade ago, and there’s little reason to expect it will now.
Why the Timeline is Shorter This Time
Organizations that approached microservices thoughtfully ended up with systems that scaled cleanly, while those that rushed are often still paying down that architectural debt years later. The same is playing out with agentic AI, except the debt comes due faster. With microservices, a bad decision surfaced as a broken deploy or a paged engineer, but with agents, non-determinism compounds silently and autonomously across long-running workflows, so the debt accrues in decisions you can’t see until the blast radius is large.
The lessons are already on the table. The teams that will win the agent era will be those who recognized which lessons carried over, which ones didn’t, and built for agentic durable execution before the debt came due.
from DevOps.com https://ift.tt/dquUNOe
Comments
Post a Comment