You have agents everywhere. Three in your CRM handling leads, pipeline, and quotes. Another cluster in HR managing onboarding, leave, and compensation. A few more in your ERP tracking procurement, inventory, and payments. They all need to collaborate — but should every interaction between them travel across the network?
The answer is no. And the architecture that solves this is simpler than you think: SOMA inside, A2A outside.
SOMA — Single Org Multi Agent — is the pattern of co-locating tightly coupled agents within a single runtime. A2A — Google’s Agent-to-Agent protocol — is the standard for federating agents across systems over the network. They’re not competitors. They’re complementary layers. One gives you speed. The other gives you reach.
This post breaks down both patterns, shows where each excels, and explains why the winning enterprise architecture uses both.
What Is SOMA?
SOMA (Single Org Multi Agent) is an architectural pattern where multiple agents operate within the same runtime, server, or organizational boundary. They share:
- Memory — direct access to the same state, no serialization needed
- Context — conversation history, user session, and business data available to all agents instantly
- Execution environment — function calls between agents are in-process, not over the wire
Communication between SOMA agents happens via in-memory message passing, shared event buses, or direct function invocation. There is no network hop. No HTTP handshake. No JSON serialization/deserialization overhead. No authentication tokens exchanged between agents.
This isn’t tied to any one vendor or framework. Whether you’re using LangGraph with multiple nodes in one process, CrewAI agents in a single crew, AutoGen agents in a group chat, or any platform’s native multi-agent orchestration — if the agents share a runtime and communicate without network calls, that’s SOMA.
What Is A2A?
A2A (Agent-to-Agent) is Google’s open protocol for agent interoperability across systems. It defines how agents discover each other, exchange messages, and collaborate over the network using standard web technologies.
The core components:
- Agent Card — a JSON metadata file (typically at
/.well-known/agent.json) that describes an agent’s capabilities, skills, and endpoint URL. Think of it as a service discovery manifest for agents. - JSON-RPC over HTTP — the communication layer. Agents send tasks to each other as structured JSON-RPC requests.
- Task lifecycle — each interaction is modeled as a Task with states (submitted, working, completed, failed). Tasks can contain Messages with Parts (text, files, structured data).
- Streaming & Push — supports Server-Sent Events for streaming responses and push notifications for long-running tasks.
A2A is designed for the scenario where agents live in different systems, run on different infrastructure, and are maintained by different teams. It solves cross-boundary interoperability — but that interoperability comes at a cost.
The Performance Gap
Here’s what happens when two agents need to collaborate:
Under SOMA (same runtime):
- Agent A calls Agent B’s function directly
- Data is passed by reference or shared memory
- Response is immediate — microseconds
Under A2A (over the network):
- Agent A serializes the request to JSON
- HTTP connection established (TLS handshake if first call)
- Authentication token attached and validated
- Request transmitted over the network
- Agent B deserializes the request
- Agent B processes and serializes the response
- Response transmitted back over the network
- Agent A deserializes the response
That’s a minimum of 50–200ms per interaction in a well-optimized system. In real-world conditions with DNS resolution, load balancers, retries, and geo-distribution — it can be significantly more.
| Dimension | SOMA (Internal) | A2A (Federated) |
|---|---|---|
| Latency | Microseconds (in-process) | 50ms–500ms (network round-trip) |
| Context sharing | Direct memory / shared state | Serialized JSON payloads |
| Auth overhead | None (same trust boundary) | Token validation per call |
| Failure modes | Process-level only | Network partitions, timeouts, retries |
| Data freshness | Always current (same source) | Potentially stale (eventual consistency) |
| Scalability | Vertical (single runtime) | Horizontal (distributed systems) |
| Coupling | Tight (shared deployment) | Loose (independent lifecycle) |
Neither is universally better. The question is: which interactions deserve the fast path, and which need the reach?
The Answer: Domain-Based SOMA Clusters Federated via A2A
The enterprise pattern that emerges is a two-layer architecture:
Inner layer — SOMA clusters grouped by business domain. Agents that frequently collaborate and share data live together in one runtime.
Outer layer — A2A federation connecting SOMA clusters across domains. Each cluster exposes a single facade agent to the network.
Let’s make this concrete.
CRM SOMA (Sales Domain)
Three agents that constantly interact on shared pipeline data:
- Lead Qualification Agent — scores inbound leads, enriches contact data, determines routing
- Pipeline Agent — manages opportunity stages, updates forecasts, flags stalled deals
- Quote & Proposal Agent — generates quotes, applies discount rules, routes for approval
These agents are deeply interdependent. When a lead converts, the pipeline agent creates an opportunity and the quote agent pre-loads pricing templates — simultaneously. When a deal stage changes, the lead agent re-scores related contacts and the quote agent checks if the existing proposal needs revision.
Under SOMA, this coordination is instant. The pipeline agent’s state change triggers the other two agents in the same execution cycle. No waiting. No serialization. No risk that one agent acts on stale data because the update hasn’t propagated yet.
Under pure A2A, that single deal-stage update would require at minimum two network round-trips to notify the other agents, plus two more to get their responses. At 100–200ms per hop, a workflow that should take milliseconds now takes close to a second — and that’s the optimistic case without retries.
The CRM SOMA exposes one facade — a “Sales Domain Agent” — to the enterprise A2A layer. External systems don’t talk to the lead agent or the quote agent directly. They talk to the Sales Domain Agent, which internally orchestrates its three specialists.
HR SOMA (People Operations)
Three agents sharing employee data in a single runtime:
- Onboarding Agent — provisions system accounts, schedules orientation, assigns training paths
- Leave & Attendance Agent — processes PTO requests, validates against policy, updates calendars
- Compensation Agent — runs salary benchmarks, models bonus scenarios, flags equity gaps
When a new employee is onboarded, all three agents act in concert: the compensation agent sets the salary band, the leave agent provisions PTO balance based on the offer terms, and the onboarding agent sequences everything into a first-week schedule. This is one atomic operation internally — no partial states, no race conditions.
The HR SOMA exposes a “People Ops Agent” to A2A.
ERP SOMA (Finance & Supply Chain)
- Procurement Agent — manages purchase orders, evaluates vendors, negotiates contract terms
- Inventory Agent — monitors stock levels, triggers reorders, optimizes warehouse allocation
- Accounts Payable Agent — matches invoices to purchase orders, schedules payments, flags discrepancies
When inventory drops below threshold, the procurement agent fires immediately (same process) to generate a PO, and accounts payable pre-stages the expected invoice match. Three agents, one shared data context, zero network overhead.
The ERP SOMA exposes a “Finance & Supply Chain Agent” to A2A.
The Full Enterprise Architecture
┌─────────────────────────────────────────────────────────────────────┐
│ ENTERPRISE A2A ORCHESTRATOR │
│ (discovers Agent Cards, routes cross-domain tasks) │
└──────────┬──────────────────────┬───────────────────────┬───────────┘
│ A2A (HTTP/JSON-RPC) │ A2A (HTTP/JSON-RPC) │ A2A (HTTP/JSON-RPC)
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌──────────────────────┐
│ Sales Domain │ │ People Ops │ │ Finance & Supply │
│ Agent (facade) │ │ Agent (facade) │ │ Chain Agent(facade) │
├─────────────────┤ ├─────────────────┤ ├──────────────────────┤
│ CRM SOMA │ │ HR SOMA │ │ ERP SOMA │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌────────────────┐ │
│ │ Lead │ │ │ │ Onboarding │ │ │ │ Procurement │ │
│ │Qualification│ │ │ │ Agent │ │ │ │ Agent │ │
│ └──────┬──────┘ │ │ └──────┬──────┘ │ │ └───────┬────────┘ │
│ │in-mem │ │ │in-mem │ │ │in-mem │
│ ┌──────┴──────┐ │ │ ┌──────┴──────┐ │ │ ┌───────┴────────┐ │
│ │ Pipeline │ │ │ │ Leave & │ │ │ │ Inventory │ │
│ │ Agent │ │ │ │ Attendance │ │ │ │ Agent │ │
│ └──────┬──────┘ │ │ └──────┬──────┘ │ │ └───────┬────────┘ │
│ │in-mem │ │ │in-mem │ │ │in-mem │
│ ┌──────┴──────┐ │ │ ┌──────┴──────┐ │ │ ┌───────┴────────┐ │
│ │ Quote & │ │ │ │Compensation │ │ │ │ Accounts │ │
│ │ Proposal │ │ │ │ Agent │ │ │ │ Payable │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └────────────────┘ │
└─────────────────┘ └─────────────────┘ └──────────────────────┘
Same Server Same Server Same Server
(no network hops) (no network hops) (no network hops)Now consider what happens when a cross-domain workflow fires — say, a closed-won deal needs to trigger onboarding for a new customer success resource and a procurement order for implementation services:
┌─────────────────────────────────────────────────────────────┐
│ CROSS-DOMAIN WORKFLOW: Deal Closed │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Pipeline Agent detects deal closed-won │
│ └─→ [IN-MEMORY] Quote Agent finalizes contract terms │
│ └─→ [IN-MEMORY] Lead Agent updates account scoring │
│ │
│ 2. Sales Facade Agent sends A2A task to HR │
│ └─→ [NETWORK - 1 hop] People Ops Agent receives │
│ └─→ [IN-MEMORY] Onboarding Agent provisions CSM │
│ └─→ [IN-MEMORY] Compensation Agent sets contractor │
│ │
│ 3. Sales Facade Agent sends A2A task to ERP │
│ └─→ [NETWORK - 1 hop] Finance Agent receives │
│ └─→ [IN-MEMORY] Procurement Agent creates PO │
│ └─→ [IN-MEMORY] AP Agent stages expected invoice │
│ │
├─────────────────────────────────────────────────────────────┤
│ TOTAL NETWORK HOPS: 2 │
│ TOTAL IN-MEMORY CALLS: 6 │
│ │
│ Pure A2A equivalent: 8 network hops for the same workflow │
└─────────────────────────────────────────────────────────────┘Six out of eight agent interactions happen in-memory. Only two cross the network — the irreducible minimum for cross-domain coordination. That’s a 75% reduction in network calls compared to a pure A2A architecture where every agent is independently addressable.
Why This Hybrid Wins
Performance — the vast majority of agent-to-agent interactions (within a domain) stay on the fast path. Only cross-domain calls pay the network tax.
Fault isolation — a network failure between CRM and HR doesn’t break the internal coordination of your sales agents. Each SOMA is independently resilient.
Reduced attack surface — only facade agents are exposed to the network. Internal agents are unreachable from outside their SOMA boundary. Fewer endpoints to secure, audit, and monitor.
Team autonomy — the CRM team owns their SOMA cluster end-to-end. They can add, remove, or refactor internal agents without touching the A2A contract. The facade agent’s interface is the only external dependency.
Simpler observability — cross-domain tracing involves 2–3 A2A hops, not 8–10. Internal agent coordination is a single trace span. Debugging is drastically simpler.
Cost efficiency — fewer network calls means lower infrastructure costs. No need for service mesh complexity between agents that sit in the same process.
When to Use What
Pure SOMA — when all your agents serve one domain, are maintained by one team, and share one data source. Don’t introduce A2A overhead between agents that will never be consumed by external systems.
Pure A2A — when you’re integrating agents from completely different vendors, clouds, or organizations with independent deployment lifecycles. A2A is the only game in town for true multi-vendor interop.
Hybrid SOMA + A2A (the enterprise default) — when you have multiple domain-specific agent clusters that need to collaborate across boundaries. This is the architecture most enterprises will land on: tight SOMA clusters internally, A2A federation externally.
Design Principles for the Hybrid Model
- Group by data affinity — agents that read/write the same data belong in the same SOMA. If they share a database, they share a runtime.
- One facade per SOMA — expose exactly one Agent Card per domain cluster. The facade handles routing, authorization, and protocol translation for its internal agents.
- Keep A2A interactions coarse-grained — a cross-domain A2A call should represent a complete business intent (“onboard this customer”), not a chatty sequence of fine-grained operations.
- Design for independent failure — each SOMA must handle its own failures without waiting for A2A responses. Use async task patterns (A2A’s task lifecycle supports this natively) for cross-domain workflows.
- Version at the facade — internal SOMA agents can evolve freely. The facade agent’s A2A contract (its Agent Card capabilities) is what needs versioning and backward compatibility.
Conclusion
SOMA gives you speed and cohesion within a domain. A2A gives you reach across the enterprise. The winning multi-agent architecture doesn’t choose between them — it layers them.
Build tight, fast agent clusters with SOMA for domains that demand real-time coordination. Expose those clusters as A2A endpoints for cross-domain workflows that need interoperability. You get microsecond performance where it matters most, and standards-based federation where it matters at all.
The enterprise of the future isn’t one giant monolithic agent, and it isn’t a hundred independently deployed agents all chattering over HTTP. It’s a handful of well-designed SOMA clusters, each a high-performance team of specialists, federated through A2A into a coherent whole.
SOMA inside. A2A outside. Fast where it counts. Open where it must be.