AI Agent 为何在重演 2019 年微服务的错误

O'Reilly Radar· Shania Rasheed Nalagath·2026-11-09 19:55· 2 小时前AI 评分63

Why AI Agents Are Repeating 2019’s Microservices Mistake

AI 导读

作者复盘一次多智能体工作流的质量滑坡：每个 Agent 都按设计运行，却因摘要 Agent 丢弃了一个低信号字段导致下游给出错误推荐，排查耗时三周。

正文 · 原文

Microservices changed how we build software by breaking large applications into smaller, independently deployable services. That made systems easier to develop and scale, but it introduced a different class of problems: The behavior of the whole system got harder to see. AI agents are now following a similar path. A workflow that once lived inside a single application gets split across several agents, each responsible for one task. Individual pieces may work exactly as designed while the overall workflow gradually produces worse results. The difference is that agents make these systems far faster and cheaper to create, which makes it easier to repeat the same architectural mistake at a much larger scale.

I learned this the hard way. My name was on the design doc. Splitting that workflow across three agents was a reasonable call, and I would still defend most of the reasoning. But if you’d asked me that afternoon how we would find out when the thing quietly stopped working, I had no answer.

Months later, in a quality review, a reviewer noticed something felt off before any of our instrumentation caught it. Latency looked fine, error rates were flat, and every service in the chain returned what it was supposed to return. What we had was a slow decline in output quality, and it took about three weeks to trace.

The first agent handed a set of documents to the next one for summarization. The summarizer dropped a field it had judged to be a low signal. A downstream agent then made a confident recommendation without that field. Every agent did what it had been designed to do, and the result was still wrong. I should have anticipated it, because I’d been on the product side through the microservices years and had seen this pattern before.

The hangover we already paid for

Breaking down monoliths was a good decision for most teams, but one thing was forgotten. Decomposition did not make the difficult parts of the system disappear. It moved them into the gaps between services, where the people accountable for the overall product could no longer see them. The bill landed around 2019, and it landed on the delivery schedule rather than the incident channel. Teams were running hundreds of services with limited tracing and no contract versioning, and the real symptom was slower delivery. Shipping took longer than before, because engineers spent their weeks picking through those services.

Agents are running the same arc faster, because standing one up takes an afternoon and a prompt instead of a repo and a deploy pipeline. When creating an agent is that cheap, product teams make agents without asking anyone, and nobody keeps track of what the agents are and what they’re doing.

What breaks, and what it costs you

This isn’t only my experience. Cemri and coauthors annotated more than 1,600 execution traces across seven popular multi-agent frameworks and built a taxonomy of 14 recurring failure modes (MAST, NeurIPS 2025). Most of what goes wrong traces back to how the system was specified and how its agents coordinated, not to the models inside it.

Inventory sounds trivial and isn’t. Service sprawl at least showed up in your Kubernetes manifests. Agents get created inside product surfaces and workflow tools, and inside somebody’s weekend automation of their own job. You don’t find out what you have until a compliance reviewer asks which automated system touched a given decision, and then it’s too late.

The visibility gap cost us three weeks. When an agent calls an agent that calls a retrieval layer that calls another agent, and every hop has a model deciding what to pass forward, you need trace context that survives the whole path. Most stacks log prompts and completions per call and stop there. You get each hop and never the chain, and it was the chain that failed.

Compounding confidence is the failure that worries me most. Distributed systems fail loudly, which turned out to be a blessing nobody appreciated. A service throws a 500 and the caller knows to stop. Agents fail quietly and fluently, so when an upstream agent produces a summary that’s plausible and wrong, the downstream agent gets no signal and reasons confidently on top of it. By the time the result reaches the user, it conveys a level of confidence that the initial evidence does not support.

API contracts drifted when someone changed the response format without versioning it, and we built machinery to catch that at build time. Agent contracts drift when someone edits a system prompt. In that case there’s no schema diff and no type check. Nothing breaks until a downstream agent starts getting different output and adapts to it without telling anybody.

What carries over from microservices

A registry is the cheapest thing to build and the first thing everyone skips. When building microservices, we kept a service catalog with an owner and a scope for each service. For agents, we need that same record plus an explicit list of what each agent is allowed to call.

Tracing carries over nearly unchanged, since correlation IDs were invented for this exact problem. OpenTelemetry’s GenAI semantic conventions give you the vocabulary, and an agent run comes out as a span tree instead of a pile of unrelated log lines:

Had we been emitting those spans, the summarizer span and the recommender span would have sat side by side in one trace, and the missing field would have been a diff instead of a three-week hunt. These conventions are still moving, so keep the attribute names behind a thin mapping layer of your own.

Finding the missing field in a trace would have shortened the investigation. I’d also want a test that caught its omission before a prompt change reached production. That’s where I’d apply the contract-testing discipline from microservices: define what the downstream agent depends on, then check that an upstream change preserves it. For the summarizer in this workflow, the evaluation would need to check whether its output retained the information the recommender needed. I’d version the prompts and require changes to pass those evaluations before release. There’s early evidence it pays: SEMAP, a protocol-layer method applying behavioral contract modeling and lifecycle verification on Google’s A2A infrastructure, reported up to roughly 70 percent fewer failures on function-level coding tasks when scored against MAST.

The trust boundary is the thing I’ll argue about in a design review. In 2019 we learned that a service doesn’t get trusted just because it lives inside the perimeter, which is most of what service meshes were for. The agent version is that an agent doesn’t get broad tool access just because we built it and we’re nice people. What an agent is allowed to do belongs in a policy layer the model can’t talk its way past, not in a system prompt asking politely.

Cost is where the analogy between microservices and agents fails. A microservice stuck in a retry loop costs you CPU and an alert at 3 am. An agent stuck in a loop costs real money on every turn and doesn’t saturate in any way that makes itself obvious. This one lands on the product owner instead of infrastructure, because it surfaces as unit economics rather than an outage, which means the PM ends up justifying the number at the end of a billing cycle.

What I ask before approving a split

None of this argues against multi-agent systems, which earn their keep the same way services did. My argument is that operational practices should evolve alongside architecture, without repeating the five-year lag of the previous transition. The person accountable for delivering the product is usually best placed to ensure that happens.

Hence, I push on four things. Can we follow one request all the way through and reconstruct what each agent decided and why? If not, we’re building something we won’t be able to debug. What happens when an upstream agent is wrong, and not whether it can be? If the honest answer is that the next agent carries on as normal, we haven’t designed a failure mode. We’ve designed a failure and left it running.

Who owns this agent, and where is its tool access enforced? A system prompt isn’t enforcement. What does this cost at ten times today’s volume, and what shuts it off when the number goes wrong? I ask that one early, because nobody volunteers it.

The teams that managed service decomposition most effectively incorporated tracing and contract testing into the build from the outset. These practices helped them understand how services interacted and verify that changes preserved expected behavior. That work is a sprint or two now, and a great deal more than that once you’re running 40 agents and someone asks which of them touched a customer’s data.

来源：O'Reilly Radar · oreilly.com