Moving From Monolithic To Microservices Architecture for Multi-Agent Systems

Muskaan Goyal; Pranav Bhasin

REVIEW 4 major objections 4 minor 1 cited by

Moving From Monolithic To Microservices Architecture for Multi-Agent Systems

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Microservices architecture is the natural fit for multi-agent systems.

desk verdict A competent but entirely derivative short survey of microservices thinking applied to multi-agent systems; fine as a pointer post, not a research result. read the letter →

arxiv 2505.07838 v1 pith:W2NABCRN submitted 2025-05-05 cs.SE cs.AIcs.DCcs.MA

Muskaan Goyal , Pranav Bhasin This is my paper · ORCID

classification cs.SEcs.AIcs.DCcs.MA

keywords microservicesarchitecturemulti-agentsystemsmonolithicModelContextProtocolApplication-to-Applicationagentcommunicationlanguagesorchestrator-workerpatternMAMS

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Multi-agent systems built from LLM agents are hitting the same wall that monolithic applications hit: scaling one component means scaling everything, updating one agent risks breaking others, and one agent's failure can take down the whole application. This paper argues that the microservices playbook developed for traditional software—decentralization, independent deployment, bounded contexts, and explicit communication contracts—applies directly to agent-based systems. It proposes that agents should be deployed as independent services that communicate through specialized protocols like the Model Context Protocol (MCP) and the Application-to-Application (A2A) protocol, which carry intent rather than just data, and it catalogs orchestrator-worker, hierarchical, and MAMS patterns as implementation templates. If the argument holds, teams building complex agent systems can expect per-agent updates, targeted resource scaling, and fault isolation, while taking on distributed state management and latency as their main engineering costs.

What carries the argument

The load-bearing mechanism is the agent-as-service mapping: each agent is treated as an independent, autonomous unit with a well-defined interface, so the microservices principles of decentralization, independent deployment, and bounded contexts carry over to multi-agent systems. The communication layer is named by two protocols: MCP, the client-server "USB-C for AI applications" that connects models and agents to tools, resources, and prompts; and A2A, the agent-to-agent layer whose Agent Card advertises capabilities and whose Task object encapsulates units of work. The MAMS pattern completes the mechanism by distinguishing Agent-Oriented MicroServices, which house communities of autonomous agents, from Plain-Old MicroServices, which expose traditional RESTful APIs, thereby bridging the agent world and the conventional service ecosystem.

What would settle it

Run the same agent workforce as a monolithic MAS and as a microservices MAS on identical hardware and tasks, measuring end-to-end latency, crash blast radius, and time-to-deploy. If the microservices version does not show smaller blast radius or targeted scaling without unacceptable latency overhead, the paper's central claim of enhanced stability and agility is contradicted.

Watch

Extended reading notes

Core claim

The central claim is that microservices architecture is a natural fit for multi-agent systems because agent autonomy, specialization, and update cadence parallel microservice decentralization, bounded contexts, and independent deployment. The paper concludes that adopting microservices for multi-agent systems brings enhanced stability, improved maintainability, and increased agility, with agent communication handled by protocols such as ACLs, MCP, and A2A rather than plain data APIs. It names orchestrator-worker, hierarchical, and MAMS as the architectural patterns through which this vision is realized, and flags distributed state and latency as the obstacles teams must engineer around.

Load-bearing premise

The load-bearing premise is that agents in a multi-agent system are enough like microservices that principles of independent deployment, bounded contexts, and fault isolation transfer directly; if the analogy is weak, the promised stability, maintainability, and agility gains lack a basis.

Editorial extensions

If this is right

Each agent can be updated, rolled back, and redeployed independently, so adopting a newer model or fine-tuned variation does not force a whole-system redeploy.
A failure in one agent is contained instead of cascading; a fatal error in a single agent need not crash every other agent or the entire application.
Resource scaling becomes targeted: only the agent or service under load is scaled, instead of the entire monolith, reducing wasted capacity and cost.
Semantic protocols like MCP and A2A let heterogeneous agents exchange tools, context, and task intentions, enabling interoperability across different vendors and models.
Event-driven variants of the orchestrator-worker and hierarchical patterns let a central agent emit tasks as asynchronous events that workers subscribe to, improving responsiveness as the agent population grows.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper's own comparison stops at conceptual mapping; a testable extension is to run identical agent workloads in a monolithic and a microservices deployment and compare crash blast radius, deploy time, and end-to-end latency, which the added network hops could plausibly worsen.
Read as a roadmap, the MCP–A2A split implies a standardization trajectory: MCP standardizes how agents consume tools and context, while A2A standardizes how agents hand work to one another, so agent contracts could become as interchangeable as REST contracts once both protocols mature.
If the agent-as-service analogy is taken literally, multi-agent systems will inherit the operational scaffolding of microservices—distributed tracing, observability, and state replication—and teams that skip that scaffolding may watch the cascade failures attributed to monolithic MAS reappear in distributed form.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick read: this is a short review article, not a research result. It argues that microservices principles—decentralization, independent deployment, bounded contexts—are a natural fit for multi-agent systems, and it surveys MCP, A2A, ACLs, and a few architectural patterns. The paper is organized and honest about its scope. The body repeatedly conditions benefits on design, and Table 1 actually concedes that agents are stateful and semantic, unlike classic stateless services. It also gets credit for including MAMS and for pointing at primary sources on MCP/A2A rather than just hype.

What is actually new: nothing. The reader's novelty score of 0 is right. The content is a synthesis of existing material, mostly already covered by the linked specs and prior surveys. The paper's job is as a pointer document, and for that purpose it is adequate but not more.

Soft spots, in order of size. First, the conclusion overclaims: 'numerous benefits, such as enhanced stability, improved maintainability, and increased agility' is stronger than the body's own caveats. The paper itself lists state management and latency as open challenges, and it mentions debugging and security only in passing. A review can still conclude that the direction is promising, but this phrasing overshoots. Second, the transfer analogy—microservice autonomy equals agent autonomy—is asserted rather than argued. That may be fine for a review, but it is the load-bearing assumption and it gets no empirical support. The paper is clear about that, so I would not call it fatal. Third, there is citation sloppiness: [13] and [14] are the same reference, and the claim that MCP is gaining traction rests on a single source. The aside about Netflix and Airbnb starting monolithic is unsupported but not load-bearing.

Who this is for: a newcomer who wants a quick map of the microservices-plus-MAS space and a pointer to MCP/A2A. It is not for researchers. It would not change my work and I would not cite it for anything substantive; citing the primary sources is strictly better. As a serious referee matter: I would not send this to peer review as a research paper. It is a modest survey, and its only real problem is that it is redundant with the sources it cites.

Recommendation: no on advancing it through the research pipeline. If the authors want a useful artifact, an annotated bibliography or a tutorial with actual system experience would serve readers better. But do not treat it as broken—treat it as out of its lane.

Referee Report

4 major / 4 minor

Summary. The manuscript is a short review article that argues for moving multi-agent systems (MAS) from a monolithic architecture to a microservices-based architecture. It begins by recalling the limitations of monolithic software and the motivations for microservices, then claims that microservices principles such as decentralization, independent deployment, and bounded contexts are a natural fit for MAS. It reviews communication protocols relevant to such systems, including Agent Communication Languages (ACLs), the Model Context Protocol (MCP), and the Application-to-Application (A2A) protocol, and it describes several architectural patterns such as orchestrator-worker, hierarchical agents, and the Multi-Agent MicroServices (MAMS) pattern. A comparative table contrasts microservices for non-agentic systems with those for agentic systems, and Section 8 lists design challenges. The conclusion states that adopting microservices for MAS has numerous benefits, including enhanced stability, maintainability, and agility, while acknowledging challenges with state, latency, debugging, and security.

Significance. If the central thesis were supported, the paper could serve as a useful practitioner-oriented synthesis of how microservices principles apply to modern LLM-based multi-agent systems. Its strengths include coverage of contemporary protocols (MCP and A2A), a clear comparative table, and an honest acknowledgment in Section 8 that agent statefulness and latency complicate the analogy with conventional stateless microservices. However, the paper is a narrative review without a stated methodology, and its main claim of 'numerous benefits' is asserted rather than demonstrated through evidence synthesis or empirical comparisons. It offers a plausible conceptual starting point, but not a verifiable research contribution.

major comments (4)

[Section 9 vs. Section 8] The conclusion states that teams 'must carefully manage system state, address latency issues, ensure proper debugging capabilities, and maintain security,' but Section 8, titled 'Design Challenges and Considerations,' discusses only state management and latency. Debugging and security are introduced for the first time in the conclusion, so the summary of challenges does not match the body. Either expand Section 8 to substantively treat debugging and security, or revise the conclusion to include only the challenges actually discussed.
[Sections 3 and 9] The central claim that 'Microservices are a natural fit for multi-agent systems' and that 'adopting microservices for multi-agent systems has numerous benefits, such as enhanced stability, improved maintainability, and increased agility' is supported only by analogy and by citations to general microservices or MAS literature ([1], [7]-[9]); no cited source is shown to demonstrate these benefits specifically for a microservices-based MAS. Because this is a review, the conclusion should be tempered to 'potential benefits' or 'hypothesized benefits,' or the authors should provide a synthesis of case studies or empirical comparisons from the literature. As written, the conclusion overstates the evidence that the body actually presents.
[Section 5, references [13]-[14]] The Model Context Protocol (MCP) paragraph cites [14] for the description of MCP as the 'USB-C port for AI applications,' but reference [14] is identical to [13] (Kone, Shimazu, and Nakajima, an agent communication languages paper). MCP is a recent protocol associated with Anthropic, and the cited source does not support the description. This is a load-bearing citation error because MCP and A2A are two of the three protocol families the review highlights, and the MCP description is left unsupported.
[General (review methodology)] The paper does not state any methodology for the review, such as a search strategy, inclusion criteria, or a procedure for selecting the 25 cited sources. Without such a methodology, the selection of references appears anecdotal, and the comparative and synthesis claims cannot be independently checked. For a review article whose main value would be its synthesis, this structural weakness undermines the reliability of the central claims and should be addressed, even briefly, in an introduction or methods paragraph.

minor comments (4)

[Section 6, last paragraph] The Broker Pattern and Blackboard Pattern are mentioned without citations; they should either be supported by references or removed from the discussion as unsupported assertions.
[Section 4, paragraph 4] The phrase 'A critical fatal error' is redundant; consider revising to 'A fatal error in one agent can impact the functionality of all other agents.'
[Reference list] References [13] and [14] are identical; even if the MCP citation had been intended to point to a separate source, the duplication should be corrected.
[Table 1] The agentic-side entries in Table 1 are not all individually supported by the cited references; for example, the Autonomy row cites [18], a single system description, rather than a comparative or foundational source. Please clarify the basis for each row or add appropriate citations.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity identified; the paper is a descriptive review whose claims are appropriately supported by external sources.

full rationale

This paper is a review article rather than an original empirical or theoretical derivation. Its central claim is that adopting microservices architecture for multi-agent systems yields benefits such as enhanced stability, maintainability, and agility. This claim is supported by citing external literature on microservices, multi-agent systems, communication protocols, and architectural patterns. The paper does not fit parameters to data, derive equations, or claim to predict outcomes from a model. The conceptual mapping between agent autonomy and microservice decentralization is presented as an analogy or design rationale, not as a proof of efficacy, and the paper explicitly acknowledges limitations in Section 8, including state management, latency, debugging, and security. The comparative table distinguishes agentic from non-agentic microservices rather than reducing one to the other. No load-bearing step relies on a self-citation, and no cited result is claimed to be derived within the paper. The conclusion's phrasing that adopting microservices has 'numerous benefits' is a summary of the preceding review-level synthesis, not a result that is equivalent by construction to its inputs. Therefore, no circularity is present.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper rests on domain assumptions rather than free parameters or invented entities. It assumes that microservices principles transfer to multi-agent systems, that MCP and A2A are adequate communication protocols, and that the identified challenges can be solved with known strategies. These assumptions come from the review's framing, not from evidence in the paper.

assumptions (3)

domain assumption Microservices principles, including decentralization, independent deployment, and bounded contexts, apply to multi-agent systems.
Section 3 asserts that microservices are a natural fit for MAS based on conceptual parallels, but provides no empirical validation or counterexample.
domain assumption Communication protocols like MCP and A2A provide the needed semantic communication layer for microservices-based MAS.
Section 5 describes these protocols as crucial, but only cites their documentation and overview papers, not evaluations in a microservices MAS context.
domain assumption The challenges of state management and latency in distributed agent systems have known solutions that do not undermine the architecture.
Section 8 lists these challenges but does not offer or cite a specific architecture or benchmark that resolves them.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Moving From Monolithic To Microservices Architecture for Multi-Agent Systems." pith.science (2026). https://pith.science/paper/W2NABCRN

@misc{pith2026250507838,
  author       = {Pith},
  title        = {Pith review of: Moving From Monolithic To Microservices Architecture for Multi-Agent Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W2NABCRN}},
  note         = {Machine review of arXiv:2505.07838}
}

read the original abstract

The transition from monolithic to microservices architecture revolutionized software development by improving scalability and maintainability. This paradigm shift is now becoming relevant for complex multi-agent systems (MAS). This review article explores the evolution from monolithic architecture to microservices architecture in the specific context of MAS. It will highlight the limitations of traditional monolithic MAS and the benefits of adopting a microservices-based approach. The article further examines the core architectural principles and communication protocols, including Agent Communication Languages (ACLs), the Model Context Protocol (MCP), and the Application-to-Application (A2A) protocol. The article identifies emerging architectural patterns, design challenges, and considerations through a comparative lens of the paradigm shift.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Collaborative Evolution of Intelligent Agents in Large-Scale Microservice Systems
cs.DC 2025-08 reject novelty 3.0 of 10

A simulation-based study claims that combining per-service reinforcement learning agents with graph embeddings and an evolutionary strategy-selection step improves coordination and adaptation metrics in microservice systems.

Reference graph

Works this paper leans on

24 extracted references · 19 canonical work pages · cited by 1 Pith paper

[14]

The state of the art in agent communication languages

Kone MT, Shimazu A, Nakajima T. The state of the art in agent communication languages. Knowledge and Information Systems. 2000 Aug;2:259-84

work page 2000
[1]

O'Reilly Media, Inc

Newman S. Building microservices: designing fine-grained systems. " O'Reilly Media, Inc."; 2021 Jul 24

work page 2021
[7]

Autonomy in multi -agent systems: A classification attempt

Carabelea C, Boissier O, Florea A. Autonomy in multi -agent systems: A classification attempt. In International Workshop on Computational Autonomy 2003 Jul 14 (pp. 103 -113). Berlin, Heidelberg: Springer Berlin Heidelberg

work page 2003
[9]

Transition Strategies from Monolithic to Microservices Architectures: A Domain-Driven Approach and Case Study

Seedat M, Abbas Q, Ahmed N, Feroz I, Qureshi A, Amelio A. Transition Strategies from Monolithic to Microservices Architectures: A Domain-Driven Approach and Case Study. VAWKUM Transactions on Computer Sciences. 2024 Jun 3;12(1):94-110

work page 2024
[2]

Microservices: yesterday, today, and tomorrow

Dragoni N, Giallorenzo S, Lafuente AL, Mazzara M, Montesi F, Mustafin R, Safina L. Microservices: yesterday, today, and tomorrow. Present and ulterior software engineering. 2017:195-216

work page 2017
[3]

Multi -agent systems: A survey

Dorri A, Kanhere SS, Jurdak R. Multi -agent systems: A survey. IEEE Access. 2018 Apr 18;6:28573 –93. doi:10.1109/access.2018.2831228

arXiv 2018
[4]

Autogen: Enabling next- gen llm applications via multi-agent conversation

Wu Q, Bansal G, Zhang J, Wu Y, Li B, Zhu E, Jiang L, Zhang X, Zhang S, Liu J, Awadallah AH. Autogen: Enabling next- gen llm applications via multi-agent conversation. arXiv preprint arXiv:2308.08155. 2023 Aug 16

arXiv 2023
[5]

Monolith to microservices: evolutionary patterns to transform your monolith

Newman S. Monolith to microservices: evolutionary patterns to transform your monolith. O'Reilly Media; 2019 Nov 14

work page 2019

Show all 24 references

[6]

Microservices vs

Kamisetty A, Narsina D, Rodriguez M, Kothapalli S, Gummadi JC. Microservices vs. Monoliths: Comparative Analysis for Scalable Software Architecture Design. Engineering International. 2023;11(2):99-112

2023
[8]

Designing multi -agent systems: a framework and application

Park S, Sugumaran V. Designing multi -agent systems: a framework and application. Expert Systems with Applications. 2005 Feb 1;28(2):259-71. World Journal of Advanced Engineering Technology and Sciences, 2025, 15(01), 2119-2124 2124

2005
[10]

Collier R, O'Neill E, Lillis D, O'Hare G

W. Collier R, O'Neill E, Lillis D, O'Hare G. MAMS: Multi -Agent MicroServices. In Companion proceedings of the 2019 world wide web conference 2019 May 13 (pp. 655-662)

2019
[11]

Performance evaluation of microservices communication with REST, GraphQL, and gRPC

Niswar M, Safruddin RA, Bustamin A, Aswad I. Performance evaluation of microservices communication with REST, GraphQL, and gRPC. International Journal of Electronics and Telecommunication. 2024 Jun 20;70(2):429- 36

2024
[12]

Communication protocols in multi -agent systems: a development method and reference architecture

Pitt J, Mamdani A. Communication protocols in multi -agent systems: a development method and reference architecture. InIssues in agent communication 2000 Jan 1 (pp. 160 -177). Berlin, Heidelberg: Springer Berlin Heidelberg

2000
[15]

Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions

Hou X, Zhao Y, Wang S, Wang H. Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. arXiv preprint arXiv:2503.23278. 2025 Mar 30

2025 arXiv
[16]

[cited 2025 Apr 21]

Announcing the agent2agent protocol (A2A) [Internet]. [cited 2025 Apr 21]. Available from: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

2025
[17]

GitHub - google/A2A: An open protocol enabling communication and interoperability between opaque agentic applications

Google. GitHub - google/A2A: An open protocol enabling communication and interoperability between opaque agentic applications. [Internet]. GitHub. 2025 [cited 2025 Apr 22]. Available from: https://github.com/google/A2A

2025
[18]

Magentic-one: A generalist multi -agent system for solving complex tasks

Fourney A, Bansal G, Mozannar H, Tan C, Salinas E, Niedtner F, Proebsting G, Bassman G, Gerrits J, Alber J, Chang P. Magentic-one: A generalist multi -agent system for solving complex tasks. arXiv preprint arXiv:2411.04468. 2024 Nov 7

2024 arXiv
[19]

Confluent

Four Design Patterns for Event -Driven, Multi-Agent Systems [Internet]. Confluent. 2025 [cited 2025 Apr 22]. Available from: https://www.confluent.io/blog/event-driven-multi-agent-systems/

2025
[20]

HiSOMA: A hierarchical multi -agent model integrating self -organizing neural networks with multi -agent deep reinforcement learning

Geng M, Pateria S, Subagdja B, Tan AH. HiSOMA: A hierarchical multi -agent model integrating self -organizing neural networks with multi -agent deep reinforcement learning. Expert Systems with Applications. 2024 Oct 15;252:124117

2024
[21]

Data management in microservices: State of the practice, challenges, and research directions

Laigner R, Zhou Y, Salles MA, Liu Y, Kalinowski M. Data management in microservices: State of the practice, challenges, and research directions. arXiv preprint arXiv:2103.00170. 2021 Feb 27

2021 arXiv
[22]

Microservices -based application systems

Chandramouli R. Microservices -based application systems. NIST Special Publication. 2019 Aug;800(204):800 - 204

2019
[23]

A Comprehensive Study of the Transition from Monolithic to Micro services -Based Software Architectures

Mooghala S. A Comprehensive Study of the Transition from Monolithic to Micro services -Based Software Architectures. Journal of Technology and Systems. 2023;5(2):27-40

2023
[24]

Using multi -agent microservices (mams) for agent -based modelling

Jagutis M, Russell S, Collier RW. Using multi -agent microservices (mams) for agent -based modelling. International Workshop on Engineering Multi-Agent Systems 2023 May 29 (pp. 85 -92). Cham: Springer Nature Switzerland

2023
[25]

Distributed systems

Tanenbaum AS, Van Steen M. Distributed systems. CreateSpace Independent Publishing Platform; 2017 Feb

2017

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [14]

The state of the art in agent communication languages

Kone MT, Shimazu A, Nakajima T. The state of the art in agent communication languages. Knowledge and Information Systems. 2000 Aug;2:259-84

work page 2000

[2] [1]

O'Reilly Media, Inc

Newman S. Building microservices: designing fine-grained systems. " O'Reilly Media, Inc."; 2021 Jul 24

work page 2021

[3] [7]

Autonomy in multi -agent systems: A classification attempt

Carabelea C, Boissier O, Florea A. Autonomy in multi -agent systems: A classification attempt. In International Workshop on Computational Autonomy 2003 Jul 14 (pp. 103 -113). Berlin, Heidelberg: Springer Berlin Heidelberg

work page 2003

[4] [9]

Transition Strategies from Monolithic to Microservices Architectures: A Domain-Driven Approach and Case Study

Seedat M, Abbas Q, Ahmed N, Feroz I, Qureshi A, Amelio A. Transition Strategies from Monolithic to Microservices Architectures: A Domain-Driven Approach and Case Study. VAWKUM Transactions on Computer Sciences. 2024 Jun 3;12(1):94-110

work page 2024

[5] [2]

Microservices: yesterday, today, and tomorrow

Dragoni N, Giallorenzo S, Lafuente AL, Mazzara M, Montesi F, Mustafin R, Safina L. Microservices: yesterday, today, and tomorrow. Present and ulterior software engineering. 2017:195-216

work page 2017

[6] [3]

Multi -agent systems: A survey

Dorri A, Kanhere SS, Jurdak R. Multi -agent systems: A survey. IEEE Access. 2018 Apr 18;6:28573 –93. doi:10.1109/access.2018.2831228

arXiv 2018

[7] [4]

Autogen: Enabling next- gen llm applications via multi-agent conversation

Wu Q, Bansal G, Zhang J, Wu Y, Li B, Zhu E, Jiang L, Zhang X, Zhang S, Liu J, Awadallah AH. Autogen: Enabling next- gen llm applications via multi-agent conversation. arXiv preprint arXiv:2308.08155. 2023 Aug 16

arXiv 2023

[8] [5]

Monolith to microservices: evolutionary patterns to transform your monolith

Newman S. Monolith to microservices: evolutionary patterns to transform your monolith. O'Reilly Media; 2019 Nov 14

work page 2019