Editor's note: This is an analysis/opinion piece published by O'Reilly Radar, whose parent company sells training and books on software architecture and AI. Readers should weigh the commercial interest behind the source accordingly.
Teams designing AI agent architectures risk re-running a mistake the software industry made with microservices around 2019, according to an analysis published by O'Reilly Radar under the title "Why AI Agents Are Repeating 2019's Microservices Mistake."
The core argument is straightforward. Microservices made large applications easier to develop and scale by splitting them into small, independently deployable services — but the price was visibility. Once a request crosses a dozen services, understanding what the system as a whole actually did becomes genuinely hard, and organisations spend years rebuilding the tracing and observability they lost during decomposition. O'Reilly's analysis contends that AI agent systems are now travelling the same road: a workflow that once lived inside a single application is being carved into specialised agents that hand work to one another, and the same class of blind spots is appearing.
Why this iteration may be worse
The critical difference, and the crux of the piece, is non-determinism. Distributed systems are deterministic: given the same inputs, they behave the same way, so distributed traces record faithfully what happened and why. Large language model runs are not. The same prompt can produce different outputs, tool calls can be selected or skipped on a given run, and a trace of one execution tells you almost nothing about what the system will do next time. Traces of LLM workflows are inherently incomplete, which means the observability tooling that eventually rescued the microservices era may be structurally insufficient here — making this second iteration harder to recover from, not merely a repeat of the first.
A signal with no microservices equivalent
One concrete, actionable insight stands out: cost. In microservices, architectural sprawl typically surfaced first in the incident channel — latency, cascading failures, on-call pain. In agent systems, sprawl shows up on the cloud invoice first. Every agent hop means billed inference, and token spend per workflow is an early-warning signal teams can watch in near real time. A rising cost-per-completed-task is often the first visible symptom that a decomposition has gone too far.
What this means for teams scoping agent architecture
That trade-off is one many organisations — including those in Hong Kong's regulated industries, where the auditability of automated decisions is a standing concern regardless of this article — will weigh heavily when deciding how finely to split an agent system. The practical guidance amounts to a deliberate sequencing:
- Start with a modular monolith. Split agents only where a genuine boundary exists, not for its own sake.
- Instrument prompts, tool calls and token spend from day one, not after the first incident.
- Define versioned contracts at agent handoffs so that a change in one agent cannot silently break another.
- Budget for evaluation harnesses in CI; if you cannot test behaviour, you cannot debug it.
- Assign explicit ownership per boundary — the microservices era showed that unowned services decay fastest.
When not to decompose
The strongest conclusion is a negative one: decomposition is not automatically progress. If a workflow can be understood, tested and audited inside a single loop, splitting it buys deployability at the cost of visibility — and in a regulated context, that visibility may be the more valuable property. The analysis suggests treating multi-agent design as an answer to a specific scaling or ownership problem, not as the default shape for AI systems.
The full O'Reilly Radar analysis is available at the source URL above.
編者按：本文為 O'Reilly Radar 發表的分析／評論文章，其母公司有售軟件架構及 AI 相關培訓課程與書籍。讀者宜留意來源背後的商業利益。
O'Reilly Radar 以《Why AI Agents Are Repeating 2019's Microservices Mistake》為題發表分析，指設計 AI agent 架構的團隊有重蹈軟件業約於 2019 年在 microservices 上犯下錯誤的風險。
核心論點相當直接。Microservices 將大型應用程式拆分成細小、可獨立部署的服務，令開發與擴展變得更容易——代價則是可見性。一旦一個請求橫跨十餘個服務，要理解整個系統實際上做了什麼便真正變得困難，機構往往需花數年時間，重新建立在拆解過程中失去的 tracing 與 observability。O'Reilly 的分析認為，AI agent 系統如今正走同一條路：原本存在於單一應用程式內的工作流程，正被切割成專門的 agent，彼此交接工作，而同類型的盲點亦再次出現。
為何本次迭代可能更嚴重
關鍵差異——亦是文章的重點——在於非確定性（non-determinism）。分散式系統是確定性的：輸入相同，行為便相同，因此 distributed traces 能忠實記錄發生了什麼及其原因。大型語言模型的運行則不然。同一個 prompt 可以產生不同輸出，tool call 在某次執行中可能被選用或略過，而一次執行的 trace 幾乎無法告訴你系統下次會做什麼。LLM 工作流程的 trace 本身便不完備，這意味著最終拯救了 microservices 時代的 observability 工具，在此處可能結構上不足——使這第二輪迭代更難恢復，而不只是第一輪的重演。
一個 microservices 沒有對應物的指標
有一項具體且可操作的洞察格外突出：成本。在 microservices 中，架構失控通常最先在事故頻道浮現——延遲、連鎖故障、on-call 之苦。在 agent 系統中，失控則先出現在雲端帳單上。每一次 agent 跳轉都意味著計費的 inference，而每個工作流程的 token 支出是一項團隊可以近乎即時監察的預警信號。每完成一項任務的成本持續上升，往往是拆解走得太遠的第一個可見症狀。
對界定 agent 架構的團隊意味著什麼
這項取捨，是許多機構——包括香港受規管行業的機構（在這些行業中，自動化決策的可審計性向來是關注點，與本文無關）——在決定 agent 系統應拆分得多細時，會慎重權衡的。實務指引可歸結為一套有意識的先後次序：
- 由 modular monolith 開始。只在真正存在邊界之處才拆分 agent，不為拆而拆。
- 由第一天起便監測 prompts、tool calls 及 token 支出，而非等第一次事故之後才做。
- 在 agent 交接處定義有版本控制的合約（contract），令一個 agent 的改動不會無聲地破壞另一個 agent。
- 在 CI 中為 evaluation harness 預留資源；如果無法測試行為，便無法 debug。
- 為每個邊界指派明確的 owner——microservices 時代的經驗顯示，無人負責的服務腐化得最快。
何時不應拆解
最有力的結論是反面的：拆解並非自動等於進步。如果一個工作流程可以在單一 loop 內被理解、測試及審計，拆分它便是以可見性換取可部署性——而在受規管的情境下，可見性往往是更有價值的特性。分析建議，應將 multi-agent 設計視為針對特定擴展或權責問題的答案，而非 AI 系統的預設形態。
完整的 O'Reilly Radar 分析可於上方 source URL 閱覽。