🎥 The YouTube version is also available:
Which AI Agent Framework Should You Choose? OpenAI, Claude, AutoGen, or LangGraph?
In recent years, multi-agent systems have become one of the most discussed topics in the AI industry.
With the emergence of OpenAI Agents SDK, Claude Agent SDK, AutoGen, LangGraph, and many other frameworks, the idea of multiple AI systems collaborating to perform complex business tasks has become a reality.
However, this trend did not appear overnight.
Many of today’s multi-agent systems have inherited architectural concepts that have been refined in the software industry over the last two decades through microservices architecture. At the same time, multi-agent systems have introduced an entirely new set of challenges that traditional microservices were never designed to address.
In this article, we will explore four questions:
- What problems did microservices solve?
- What problems did multi-agent systems solve?
- What challenges still remain in multi-agent systems?
- Why is a Runtime OS necessary?
The First Generation: Monolithic Systems
Traditional enterprise systems were primarily built as monolithic applications.
ERP System
├── Customer Management
├── Inventory Management
├── Accounting
├── Procurement
├── Sales
└── Billing
All functionality was implemented inside a single, large application.
As systems continued to grow, several problems emerged:
- A change in one component affected the entire application.
- Deployment became increasingly difficult.
- System failures affected a larger portion of the platform.
- Dependencies between development teams continued to increase.
The Second Generation: The Emergence of Microservices
To solve these problems, the software industry introduced Service-Oriented Architecture (SOA) and eventually microservices.
Order Service
↓
Inventory Service
↓
Payment Service
↓
Shipping Service
Instead of building one large application, organizations began dividing functionality into smaller, independent services that could be developed, deployed, and scaled separately.
Five Problems That Microservices Solved
| Challenge | Microservices Solution |
|---|---|
| Large codebases | Functional decomposition |
| Difficult deployments | Independent releases |
| Scalability limitations | Service-level scaling |
| Cascading failures | Failure isolation |
| Team dependencies | Service ownership |
Microservices fundamentally transformed software development.
However, an important limitation remained.
Microservices Cannot Make Decisions
Consider a simple customer discount policy.
if customer_type == "VIP":
discount = 20
else:
discount = 10
This is rule-based processing.
But what about questions such as:
- What is the customer’s purchasing history?
- What are competitors currently offering?
- What is the current inventory level?
- Are there contractual constraints?
- Are there any legal risks?
Traditional microservices cannot synthesize these factors and make contextual decisions.
They execute predefined rules.
They do not reason.
Multi-Agent Systems Did Not Evolve Directly from Microservices
This is where a common misunderstanding begins.
Multi-agent systems did not directly evolve from microservices.
Their origins lie in distributed artificial intelligence research.
Research in this field focused on:
- Autonomous agents
- Cooperation
- Negotiation
- Consensus building
- Distributed problem-solving
In other words:
Microservices evolved from software engineering.
Multi-agent systems evolved from artificial intelligence research.
These are two different evolutionary paths.
LLMs Connected the Two Worlds
The arrival of large language models dramatically changed the situation.
Traditional systems followed a relatively simple execution model.
Input
↓
Rules
↓
Execution
LLM-based agents introduced a completely different workflow.
Observation
↓
Reasoning
↓
Planning
↓
Tool Selection
↓
Execution
For the first time, software components could reason about what should be done instead of simply executing predefined instructions.
Agents Began Using Existing Microservices as Tools
Modern enterprise systems rarely replace their existing infrastructure.
Instead, AI agents interact with existing enterprise services.
Sales Agent
↓
CRM API
Pricing Agent
↓
Pricing Service API
Inventory Agent
↓
Inventory Service API
Legal Agent
↓
Contract Service API
Microservices did not disappear.
A new intelligence layer was simply added on top of them.
Today’s enterprise architecture increasingly resembles a three-layer model.
AI Layer
Sales Agent
Legal Agent
Pricing Agent
Risk Agent
↑↓
Enterprise APIs
CRM
ERP
Inventory
Billing
SCM
↑↓
Infrastructure
Kubernetes
Docker
Service Mesh
Databases
What Multi-Agent Systems Solved
1. Distributed Expertise
Sales Agent
Legal Agent
Risk Agent
Finance Agent
Different agents can specialize in different domains.
2. Dynamic Decision-Making
Instead of following predefined rules, agents can reason according to changing conditions.
3. Autonomous Task Execution
Agents can independently:
- Investigate
- Analyze
- Plan
- Execute
This dramatically expands what enterprise software can accomplish.
But Multi-Agent Systems Introduced New Problems
Who Makes the Final Decision?
Sales Agent
"We recommend a 15% discount."
Who ultimately approves that recommendation?
Who Authorizes Execution?
AI Agent
↓
Sign a contract
AI Agent
↓
Execute a payment
AI Agent
↓
Send an email
How much authority should an AI agent have?
Who Is Accountable?
Sales Agent
↓
Pricing Agent
↓
Legal Agent
↓
Execution Agent
If something goes wrong, who is responsible?
Who Performs the Audit?
Can we later determine:
- Why a decision was made?
- Which data was used?
- Who approved it?
- Why execution was authorized?
Current agent frameworks provide execution environments.
However, they do not fully address the governance of decision-making.
This Is Why We Need a Runtime OS
The purpose of a Runtime OS is not simply to manage agents.
Its purpose is to govern decisions.
Signal
↓
Evaluation
↓
Decision
↓
Human Gate
↓
Command Permit
↓
Execution
↓
Decision Trace
What Does a Runtime OS Provide?
| Challenge | Runtime OS Solution |
|---|---|
| Who makes decisions? | Decision Authority |
| Who approves decisions? | Human Gate |
| Who authorizes execution? | Command Permit |
| Who is accountable? | Delegation Contract |
| How are decisions audited? | Decision Trace Ledger |
| How do we prevent uncontrolled behavior? | Fail-Closed |
Conclusion
I organize the evolution of enterprise systems as follows:
Monolith
↓
Microservices
(Distributed Processing)
↓
Multi-Agent Systems
(Distributed Intelligence)
↓
Runtime OS
(Governed Decision-Making)
In other words:
Microservices distributed computation.
Multi-agent systems distributed intelligence.
Runtime OS governs distributed decisions.
In the future, the most important question in enterprise AI will not be:
“Which agent framework should we choose?”
The real question will be:
“Who is responsible for what?”
This is no longer simply an AI problem.
It is an organizational design problem.
References
- Moving From Monolithic To Microservices Architecture for Multi-Agent Systems (arXiv)
- Multi-Agent AI Systems: Evolving From Microservices to Modular Intelligence (TEKsystems)
- Multi-Agent Reference Architecture (Microsoft)
- The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems (arXiv)
Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
This topic is part of the Chinoba Knowledge Base.
コメント