A user asks:
“Review this supplier invoice, verify that everything looks correct, and prepare it for payment.”
From the user’s perspective, this is one request.
But imagine the system decides to use several AI agents:
User
|
v
Orchestrator Agent
|
+----------+----------+
| | |
v v v
Invoice Risk/Policy Supplier
Agent Agent Agent
| | |
v v v
Invoice Policy Supplier
System System System
At first glance, this looks like a simple extension of an AI agent.
Instead of one agent, we have several.
But something more interesting has happened.
We have introduced multiple decision-making participants into a distributed workflow.
And once those participants communicate, maintain state, call tools, depend on one another, and react to failures, many of the problems we already know from distributed systems come back.
Timeouts.
Retries.
Duplicate work.
Stale information.
Partial failure.
Ordering.
Concurrency.
Inconsistent state.
And now there is another problem:
Different agents may reach different conclusions about the same business situation.
That is where multi-agent architecture becomes interesting.
Multiple Agents Do Not Mean Multiple Independent Chatbots
It is easy to think about a multi-agent system as:
Agent A
Agent B
Agent C
But that is not really the architecture.
The important question is:
What relationship exists between them?
Consider:
Agent A
|
v
Agent B
|
v
Agent C
Agent A depends on the result from Agent B.
Agent B depends on information from Agent C.
Now imagine Agent C becomes unavailable.
Agent B cannot complete.
Agent A cannot complete.
The original user request is affected.
This looks much less like a collection of independent AI components.
It looks like a distributed dependency graph.
And that is the first mental model I would use:
A multi-agent system is not simply multiple agents. It is a distributed system whose participants can make decisions.
That distinction matters.
The Agent-to-Agent Call Is Still a Distributed Boundary
Suppose one agent asks another:
Invoice Agent
|
| "Is this invoice valid?"
v
Validation Agent
The calling agent may expect:
VALID
But what happens if the response times out?
Invoice Agent
|
| request
v
Validation Agent
|
| VALID
X
response lost
The validation agent may have completed the work.
The invoice agent does not know that.
It sees:
UNKNOWN
That is the same distributed-systems problem we have seen before.
The fact that both participants happen to be AI agents does not change the underlying network semantics.
A timeout does not mean failure.
A missing response does not mean the operation did not happen.
And a retry does not automatically mean a new business operation should occur.
What If Two Agents Disagree?
This is where multi-agent systems introduce something more interesting.
Imagine:
Invoice Agent
|
+----> "Invoice appears valid"
|
v
Risk Agent
|
+----> "Transaction requires review"
Now we have two conclusions.
Which one is correct?
The answer should not be:
“Ask another LLM.”
The architecture needs to define who owns the decision.
For example:
Agents
|
Recommendations
|
v
Business Policy
|
v
Deterministic Result
The agents can provide different interpretations.
The business boundary determines what actually happens.
This is another version of the principle from reliable financial architecture:
Reasoning can be distributed. Authority should not be ambiguous.
The Coordinator Is Not Automatically the Authority
A common architecture is:
Coordinator
|
+------------+------------+
| | |
v v v
Agent A Agent B Agent C
The coordinator decides what each agent should do.
It may look like the coordinator owns the workflow.
But it should not automatically own the underlying business truth.
For example:
Coordinator:
"Payment should be approved."
That is still a recommendation.
The financial system should determine:
Payment:
AUTHORIZED
or:
Payment:
REJECTED
The distinction remains:
Agent Decision
|
v
Proposed Action
|
v
Business Rules
|
v
Authorization
|
v
Financial System
Adding more agents does not remove this boundary.
It makes it even more important.
Agents Can Have Different Views of Reality
Consider three agents.
Invoice Agent
"Invoice = $50,000"
Risk Agent
"Customer exposure = $80,000"
Payment Agent
"Available funds = $40,000"
All three statements may have been correct when they were retrieved.
But the information may have been obtained at different times.
Now the system has:
Agent A
|
| state at T1
v
Agent B
|
| state at T2
v
Agent C
|
| state at T3
This is not simply an AI problem.
It is a consistency problem.
The agents may be reasoning over different snapshots of the same underlying world.
That leads to an important principle:
Agent context is a view of state, not ownership of state.
The authoritative system remains authoritative.
The Most Dangerous Word in Multi-Agent Systems: “Done”
Imagine the coordinator asks three agents to perform work:
Agent A ✓
Agent B ✓
Agent C ?
Agent C has not responded.
Is the overall operation:
FAILED
No.
It may be:
IN_PROGRESS
Or:
UNKNOWN
Or:
WAITING_FOR_AGENT
The exact state depends on the business process.
The important thing is that the architecture should not collapse all uncertainty into failure.
This is especially important when an agent may already have performed an external operation before its response was lost.
Parallelism Creates Another Problem
Multi-agent systems naturally encourage parallel execution.
For example:
Coordinator
|
+-----------+-----------+
| | |
v v v
Invoice Risk Supplier
Agent Agent Agent
That looks efficient.
But now all three agents may be operating concurrently.
Suppose:
Invoice Agent
reads invoice
Risk Agent
reads customer exposure
Supplier Agent
updates supplier information
At the same time, another workflow changes the underlying business state.
Now the agents may complete based on different versions of reality.
This is a familiar concurrency problem.
The fact that the workers are intelligent does not make concurrent state changes safe.
Parallel Does Not Mean Independent
Consider:
Agent A ---> Customer State
Agent B ---> Customer State
Agent C ---> Customer State
All three agents may believe they are performing independent work.
But perhaps all three are making decisions about the same customer.
Now we have to ask:
- Who owns the state?
- Can these operations happen concurrently?
- Are they ordered?
- Are they idempotent?
- Can one invalidate another?
- What happens if one succeeds and another fails?
These are architectural questions.
Not model questions.
Multi-Agent Systems Can Amplify Failure
A single agent might make one tool call.
A multi-agent system can multiply activity.
Imagine:
User Request
|
v
Coordinator
|
+----> Agent A
| |
| +----> Tool
|
+----> Agent B
| |
| +----> Tool
|
+----> Agent C
|
+----> Tool
Now imagine the downstream service is slow.
Each agent may retry.
The coordinator may retry the agents.
The agents may retry their tools.
Suddenly:
1 user request
|
v
3 agents
|
v
multiple tool calls
|
v
multiple retries
The system can create a large amount of downstream traffic from a single user action.
This is the same retry amplification problem we have seen in distributed systems.
The architecture therefore needs bounded execution.
Retry Ownership Becomes Important
Suppose:
Coordinator
|
v
Risk Agent
|
v
Risk Service
Who retries?
The coordinator?
The risk agent?
The risk service?
All three?
If every layer independently retries, the system can produce:
Coordinator retry
|
+--> Agent retry
|
+--> Service retry
One logical operation can become many physical requests.
A better architecture establishes clear ownership of retries.
The principle is simple:
A retry should be an explicit part of the operation’s semantics, not an accidental property of every layer.
Idempotency Still Matters
Imagine an agent performs:
Create Payment
The response is lost.
The agent retries.
Then the coordinator retries the agent.
Then the agent retries again.
Without a durable operation identity, the system may see:
Payment A
Payment B
Payment C
when the business intended:
One Payment
That is why an operation should have a stable identity:
workflow_id
operation_id
payment_intent_id
idempotency_key
The agents may retry.
The receiving system must still understand whether those requests represent the same logical operation.
Agents Should Not Pass Financial Truth to Each Other as Authority
This is another subtle problem.
Suppose:
Agent A:
"Balance is $100,000."
Agent B uses that information.
Then:
Agent B:
"Payment of $80,000 is safe."
But the balance may have changed.
Agent B should not treat Agent A’s statement as authoritative financial truth.
Instead:
Agent A
|
v
Information / Recommendation
|
v
Business Boundary
|
v
Authoritative Financial State
The authoritative system should validate the current state when the consequential operation occurs.
This prevents one agent’s stale context from becoming another agent’s false certainty.
Multi-Agent Communication Needs Contracts
When services communicate, we normally think about contracts.
For example:
Request
Response
Error
Timeout
Version
The same discipline is useful between agents.
An agent should not simply return a paragraph saying:
“I think the invoice is probably okay.”
A workflow needs structured outcomes.
For example:
VALIDATED
REJECTED
REQUIRES_REVIEW
UNKNOWN
And potentially:
reason
correlation_id
workflow_id
timestamp
source
The exact structure depends on the domain.
The principle is more important:
Agent communication should have explicit business semantics, not just conversational semantics.
Natural Language Is Not a Workflow Contract
An agent might say:
“The supplier looks legitimate and the invoice appears safe to pay.”
That may be useful to a human.
It is not necessarily a reliable machine contract.
A workflow needs something closer to:
supplier_status = VERIFIED
invoice_status = APPROVED
payment_allowed = TRUE
The model can help produce those conclusions.
But the system should distinguish between:
Explanation
and:
Authoritative State
That distinction becomes critical as agents become more autonomous.
What Happens When One Agent Changes Its Mind?
An agent may initially conclude:
APPROVE
Then retrieve additional information:
REVIEW_REQUIRED
Which decision is authoritative?
The architecture needs a durable workflow state.
For example:
PROPOSED
|
v
VALIDATING
|
v
REVIEW_REQUIRED
The fact that an agent previously suggested approval should not override the current workflow state.
This is why durable state machines remain useful even when decision-making becomes dynamic.
Agents Need Boundaries Too
There is a tendency to give every agent broad capabilities.
For example:
Invoice Agent
|
+--> Read invoices
+--> Modify invoices
+--> Execute payments
+--> Contact suppliers
That is unnecessarily powerful.
A better design is:
Invoice Agent
|
+--> Read invoice
+--> Validate invoice
And perhaps:
Payment Agent
|
+--> Propose payment
while:
Financial System
|
+--> Authorize
+--> Execute
+--> Record
The principle of least authority applies to agents just as it applies to traditional services.
An agent should have the minimum capabilities required for its role.
The More Agents You Add, the More Important Ownership Becomes
Consider:
Coordinator
|
+-------------+-------------+
| | |
v v v
Invoice Risk Payment
Agent Agent Agent
| | |
v v v
Invoice Risk Payment
System System System
Now ask:
Who owns:
- invoice state?
- risk state?
- payment state?
- workflow state?
- authorization?
- final financial truth?
If the answer is:
“The agents collectively know it.”
that is a warning sign.
A reliable system needs explicit ownership.
The Coordinator Itself Becomes a Failure Domain
The coordinator often looks like:
Coordinator
/ | \
/ | \
Agent A Agent B Agent C
But what happens if the coordinator crashes after:
Agent A ✓
Agent B ✓
Agent C started
When it restarts, it needs to know what actually happened.
It should not simply start everything again.
Again, durable workflow state matters:
Agent A COMPLETED
Agent B COMPLETED
Agent C IN_PROGRESS
The coordinator is therefore not just an AI component.
It is also part of the workflow infrastructure.
Multi-Agent Systems Resemble Sagas
This is where multi-agent architecture connects naturally to distributed transaction architecture.
Consider:
Workflow
|
+--> Agent A
|
+--> Agent B
|
+--> Agent C
|
+--> Financial Operation
Each step may have:
success
failure
timeout
retry
compensation
escalation
The workflow therefore starts looking like a Saga.
The agents may dynamically determine which actions are appropriate.
But the workflow still needs to know:
What happened?
What is pending?
What failed?
What can be retried?
What can be compensated?
What requires human intervention?
AI does not replace these concepts.
It participates inside them.
Multi-Agent Does Not Mean More Autonomous
This is an important distinction.
You can have:
One agent
with significant autonomy.
And you can have:
Five agents
with tightly constrained responsibilities.
The number of agents does not define the level of autonomy.
A better definition is:
Autonomy is the ability to act independently within defined business boundaries.
A multi-agent system should therefore not become:
Many agents
+
Many tools
+
Unlimited authority
It should become:
Many specialized decision-makers
+
Clear responsibilities
+
Explicit boundaries
+
Durable workflow state
+
Controlled authority
The Interesting Question Is Not “Why Multiple Agents?”
There is a lot of discussion around whether one agent is better than multiple agents.
I think the architectural question is different:
What responsibility becomes clearer by separating the agents?
For example:
Invoice Agent
|
+--> Invoice interpretation
Risk Agent
|
+--> Risk analysis
Supplier Agent
|
+--> Supplier investigation
Payment Agent
|
+--> Payment workflow
The separation can make responsibilities clearer.
But if all four agents simply perform the same kind of reasoning over the same data, the additional complexity may not buy much.
More agents are not automatically better architecture.
Decomposition Has a Cost
Every additional agent introduces another participant.
That can mean:
another call
another timeout
another context
another failure
another retry
another dependency
another state transition
another observability dimension
Suppose one request requires:
Agent A
|
v
Agent B
|
v
Agent C
|
v
Agent D
The user sees one request.
The system has created a chain of dependencies.
The architecture should therefore ask:
Does this additional agent reduce complexity somewhere else, or merely move complexity into communication?
That is a question experienced distributed-systems engineers naturally ask.
Observability Becomes More Important
Traditional distributed tracing might look like:
Request
|
+--> Service A
|
+--> Service B
|
+--> Database
A multi-agent workflow can become:
Request
|
v
Agent Run
|
+--> Agent A
| |
| +--> Tool
|
+--> Agent B
| |
| +--> Tool
|
+--> Agent C
|
+--> External Service
Now an incident investigation may need to answer:
- Which agent made the decision?
- What information did it use?
- Which agent called the next agent?
- Which tool was invoked?
- Which operation actually committed?
- Which response was lost?
- Which retry occurred?
- Which workflow state changed?
Useful identifiers might include:
request_id
workflow_id
agent_run_id
agent_id
tool_call_id
operation_id
idempotency_key
The objective is not to log every thought.
The objective is to reconstruct the business execution path.
Multi-Agent Systems Need Explicit Stop Conditions
A traditional service normally returns.
An autonomous agent can continue.
With multiple agents, that continuation can become more complicated.
For example:
Agent A
|
v
Agent B
|
v
Agent C
|
v
Agent A
|
v
Agent B
A workflow can accidentally create cycles.
Therefore, the system needs limits such as:
maximum workflow duration
maximum agent calls
maximum retries
maximum parallel operations
maximum financial exposure
maximum delegation depth
The exact limits depend on the business.
The architectural principle is:
An agentic workflow should have a bounded ability to continue acting.
The Most Important Boundary Remains the Same
After all of this complexity, the fundamental architecture does not actually change.
It becomes:
User
|
v
Agent System
|
+-----------+-----------+
| | |
v v v
Agent A Agent B Agent C
| | |
+-----------+-----------+
|
Recommendations
|
v
Deterministic Boundary
|
+---------+---------+
| | |
v v v
Policy Authorization Validation
| | |
+---------+---------+
|
v
Financial Systems
|
v
System of Record
Multiple agents can reason.
Multiple agents can collaborate.
Multiple agents can investigate.
Multiple agents can propose actions.
But when the workflow reaches a consequential financial boundary, the system needs deterministic authority.
The Agent Network Is Not the Source of Truth
This principle becomes even more important with multiple agents.
Imagine:
Agent A says:
"Payment completed."
Agent B says:
"Payment appears pending."
Agent C says:
"Payment may have failed."
Which one wins?
None of them.
The payment system should answer.
Payment System
P-98231
Status = COMPLETED
The agents’ views are observations or interpretations.
The authoritative system defines the state.
That gives us a very useful rule:
When agents disagree about reality, do not resolve the disagreement by asking another agent. Resolve it against the authoritative system.
Multi-Agent Architecture Is Ultimately About Responsibility
The deeper question is not:
“How many agents should we have?”
It is:
“Who is responsible for each decision and each piece of state?”
For example:
User Intent
|
v
Agent
|
+--> Interpretation
Policy System
|
+--> Authorization
Workflow
|
+--> Progress / Recovery
Payment System
|
+--> Payment State
Ledger
|
+--> Financial Truth
Now the architecture has clear ownership.
The agents can be flexible without becoming sovereign.
A Multi-Agent System I Would Trust
For a consequential workflow, I would want something conceptually like:
User
|
v
+---------------+
| Agent System |
+-------+-------+
|
Understand Intent
|
v
Proposed Actions
|
+---------------+---------------+
| |
v v
Specialized Agents Workflow
| |
| v
| Durable State
| |
+---------------+---------------+
|
v
Deterministic Controls
|
+----------+----------+
| | |
v v v
Policy Authorization Validation
| | |
+----------+----------+
|
v
Financial Systems
|
v
System of Record
|
v
Reconciliation
The agents provide flexibility.
The workflow provides durability.
The business controls provide authority.
The financial systems provide truth.
Reconciliation handles what cannot immediately be known.
And observability allows us to understand how the system arrived at its current state.
The Real Distributed System Has Changed
With a traditional distributed application, we might think about:
Services
Databases
Queues
External APIs
With an agentic system, we now have another participant:
Decision-making agents
And when there are multiple agents:
Agent
|
+--> Agent
| |
| +--> Tool
|
+--> Agent
|
+--> External Service
The system now has components that can dynamically decide:
what to call
who to ask
what to do next
whether to retry
whether to stop
That is the genuinely new architectural dimension.
The distributed-system problems did not disappear.
They became more dynamic.
Final Takeaway
Multi-agent systems are often presented as a way to make AI more capable by giving different agents different responsibilities.
That is true.
But from a software architecture perspective, something else happens.
The moment multiple agents communicate, depend on one another, maintain state, call external systems, and participate in a long-running workflow, we have created another form of distributed system.
The agents can fail.
Their responses can be lost.
They can disagree.
They can operate on stale information.
They can retry the same operation.
They can amplify downstream failures.
They can make decisions concurrently.
And they can create increasingly complex dependency graphs.
That does not mean multi-agent architecture is a bad idea.
It means we should apply the same engineering discipline we already apply to distributed systems.
Make boundaries explicit.
Give operations durable identities.
Make retries safe.
Keep workflow state durable.
Define ownership.
Bound execution.
Make authorization deterministic.
Keep financial truth in the system of record.
Make partial success visible.
Treat unknown as a legitimate state.
And provide a path for reconciliation and human intervention.
The most important principle is perhaps the simplest:
Multiple agents can share the work. They should not share responsibility for what is actually true.
Each agent can reason within its role.
The workflow can coordinate progress.
Deterministic systems can enforce business rules.
And authoritative systems can decide what actually happened.
That is how I would approach multi-agent architecture in a financial system:
not as a collection of smarter chatbots, but as a new kind of distributed system whose participants can reason.