Executive Brief

In our previous issue, we explored how AI-powered customers could change the way businesses compete.

That raises a further question: what happens when the AI supporting your customers begins interacting with the AI supporting your business?

Inside an organisation, a similar shift is possible. An agent researching a customer could pass its findings to another preparing a proposal. A delivery agent could assess capacity, while a finance agent checks commercial assumptions. People would set objectives, approve commitments and resolve exceptions.

This is the idea behind the multi-agent enterprise: an organisation in which people, AI agents and established systems coordinate work across business processes.

It is an emerging operating model, with capabilities and reliability that vary considerably between implementations.

For executives, the central question is:

Where could coordinated AI improve business performance—and how should that coordination be managed?

1. From Individual Assistance to Coordinated Work

An AI assistant might help you write a proposal.

An AI agent might gather information, use tools and work through several steps towards preparing that proposal.

A multi-agent system divides work between agents with different responsibilities, bringing their contributions together.

For example, Anthropic has described a research system in which a lead agent delegates different lines of investigation to other agents and combines their findings. That is a concrete example of multi-agent coordination within a defined task, rather than evidence that an entire business can operate autonomously. [1]

The executive opportunity is to identify work that benefits from this division of responsibilities.

2. What Could This Look Like in Your Business?

Consider this illustrative customer-enquiry process:

The business objective would be a faster, more accurate response with fewer manual handovers.

Each participant needs a defined role. The process also needs rules for missing information, conflicting recommendations and failed system connections.

3. The Opportunity Lies Between Departments

When looking for opportunities, examine the points where work changes hands.

A sales enquiry may wait for technical input. A proposal may wait for a delivery estimate. An invoice query may require information from several teams.

Ask:

Where does work stop while someone searches, checks, translates or passes on information?

These handovers are useful places to investigate coordinated AI assistance.

For a small business, the ‘departments’ may all be different responsibilities held by the same founder. The opportunity could be reducing the effort of switching between selling, delivering, administering and planning.

Map the actual delays before deciding how many agents—or which tools—you need.

4. More Agents Do Not Automatically Mean Better Results

Every additional agent introduces communication, coordination and monitoring work.

A task that one well-designed assistant can complete may become slower or more expensive when split unnecessarily.

Anthropic’s published experience highlights both the value of parallel research and the additional resource consumption of multi-agent systems. Its guidance also recommends beginning with simple approaches and adding complexity when the task requires it. These are engineering observations, not a universal business case for adding agents. [1][2]

Before approving a multi-agent project, ask:

What improvement do we expect from multiple agents that a simpler workflow could not deliver?

The answer should be measurable.

5. Collaboration Requires Shared Rules

Agents need a clear way to exchange requests, results and progress updates.

The Agent2Agent protocol, or A2A, is one initiative designed to support communication between agents built using different frameworks or by different vendors. [3]

However, technical connectivity is only part of the challenge.

A business still needs to specify:

• What information each agent may share.
• Which records are authoritative.
• Who can request an action.
• What constitutes a completed task.
• How disagreements and exceptions are resolved.

Two agents being able to communicate does not establish that either has permission to make a commercial commitment.

6. Who Owns the Outcome?

Imagine a proposal contains an unrealistic delivery date.

The research agent gathered the requirements. The proposal agent drafted the offer. The delivery agent used an outdated capacity report. A manager approved the final version.

Who is responsible for correcting the process?

My recommendation is to assign one named business owner to the complete workflow, supported by people responsible for its individual components.

That owner should understand the intended outcome, monitor performance and have authority to pause the process.

For every workflow, document:

Business owner → permitted actions → approval points → escalation route → recovery procedure.

Accountability should remain clear even when execution is distributed.

7. Risk and Governance Watch

An error can travel through a chain of agents.

For example, an unverified statement extracted from a customer email could become an assumption in a proposal and then a task in a delivery plan. Repetition across systems might make it appear more credible without adding evidence.

Security risks also cross these boundaries. OWASP’s agent-security guidance recommends validating communications between agents, restricting permissions and preventing an agent chain from becoming a route to greater access. It also recommends controls that stop failures spreading. [4]

Useful design questions include:

• Can downstream agents distinguish verified facts from assumptions?
• Can they trace important information back to its source?
• Can one agent persuade another to perform an action outside its authority?
• Can the workflow be stopped before an error creates further consequences?

Treat an agent’s output as information to evaluate, not automatic authority to act.

8. Human Oversight Must Be Practical

‘Human in the loop’ needs to describe a real operating arrangement.

Specify which decisions require review, what evidence the reviewer receives and how much time they have to respond.

For an initial pilot, a sensible boundary might be:

• Agents can research, summarise and prepare drafts.
• People approve external commitments and consequential changes.
• Uncertain or conflicting cases move to a named reviewer.
• If that reviewer is unavailable, the process pauses or follows an agreed fallback.

Review the workload as well. If the system produces more approvals than people can meaningfully examine, the oversight design needs to change.

9. Seven Questions Every Leadership Team Should Ask

1. Which business problem are we trying to solve?
   Identify the delay, cost, quality issue or unmet customer need.
2. Why does this require multiple agents?
   Explain the benefit of dividing the work.
3. Who owns the complete outcome?
   Name the accountable business leader.
4. What may each agent access and do?
   Define information access and action limits.
5. How will agents handle conflicting or incomplete information?
   Establish an escalation and resolution process.
6. How will we detect, stop and recover from failure?
   Test this before expanding access.
7. How will we know the approach is worthwhile?
   Compare results with the existing process and a simpler alternative.

10. Executive KPI Dashboard

Use a small dashboard that measures business outcomes and the quality of coordination.

Set a baseline before the pilot. Agree in advance what results would justify continuing, revising or stopping it.

11. Executive Playbook for the Next 30 Days

Week 1 — Select one workflow
Choose a contained process with a clear owner and observable outcomes. Map the current steps, delays and information sources.

Week 2 — Define responsibilities and boundaries
Decide which tasks belong to people, agents and conventional software. Establish access limits, approval points and the fallback process.

Week 3 — Run a controlled test
Use historical cases or a limited set of approved live cases. Test incomplete information, conflicting instructions, unavailable systems and failed handovers.

Week 4 — Evaluate the complete process
Measure quality, time, total cost and review effort. Compare against the baseline and the simpler alternative.

A successful month may produce evidence to proceed—or reveal that the proposed architecture needs simplifying.

12. Board Decision of the Week

Ask your leadership team:

Which business process would benefit most from better coordination between people, AI and existing systems?

Then authorise a bounded discovery exercise with:

• A named owner.
• A defined problem and baseline.
• A limited budget.
• Clear restrictions on access and actions.
• A date for reviewing the evidence.

Members can use the AI Executive PRO Opportunity Finder to identify candidates, then take the strongest opportunities through prioritisation, business-case development and readiness assessment.

13. From Agent Experiments to Organisational Capability

The multi-agent enterprise brings operating-model questions into AI adoption.

How is work divided? How is information checked? Who can make a decision? What happens when participants disagree? How is performance measured?

These questions deserve attention alongside the technology.

The ambition should be a business process that works better for customers and staff, with enough visibility and control for leadership to trust its operation.

Executive Question of the Week

If AI agents begin coordinating work across your business, have you defined the responsibilities, boundaries and measures that will make that coordination effective?

Until next week,
The AI Executive Brief