VI · Multi-AgentEmerging★

Cross-Domain Enterprise Agent Network

also known as Domain-Specialised Agent Mesh, Joule-Style Agent Collaboration, Per-Function Agent Network

Decompose enterprise agency into domain-specialised agents (finance, supply chain, HR, service), each grounded in its own system of record, and route artefacts between them through a standardised inter-agent protocol.

Context

A large enterprise already runs its business across many backing systems — finance in an ERP, customers in a CRM, employees in an HR system, support in a ticketing system — and the end-to-end workflows it cares about cross those boundaries. A dispute moves from customer service into finance into supply chain; closing a quarter pulls data from half a dozen sources. Each domain has its own data model, vocabulary, compliance rules, and team that owns it.

Problem

Building a single mega-agent grounded against every backing system produces an agent with a sprawling tool catalogue, no clear domain ownership, and no domain-specific guardrails. Recall drops as the catalogue grows: the agent picks the wrong tool, mixes up vocabularies between domains, and applies finance rules to an HR question. Compliance teams have nowhere to attach domain controls, and no single team can be made accountable for the whole thing. Flat tool-use agents over a flat catalogue degrade in exactly this regime.

Forces

  • Each domain has its own data model, vocabulary, and compliance rules.
  • End-to-end workflows must cross domains.
  • A single agent over all systems blows up the tool catalogue and the prompt.
  • Domain teams want ownership and lifecycle of their own agents.

Example

A large enterprise has separate teams for finance, supply chain, HR, and customer service, each with its own systems of record. A single mega-agent grounded against all of them has terrible recall and no clear ownership when something goes wrong. They build a Cross-Domain Agent Network: a domain-specialised agent per area, each grounded in its own data and bounded by domain-specific policies, and a standardised inter-agent protocol that lets a finance agent request a supplier risk score from the supply-chain agent. Each domain stays independently governed.

Diagram

Solution

Therefore:

Build one specialised agent per business domain, each with its own grounded data, tool palette, and acceptance criteria. Define a standardised inter-agent protocol for handoffs (e.g. A2A, MCP). When a task crosses domains, the source agent routes to the target via the protocol, passing a typed artefact. An optional supervisor or role-based assistant fronts the user and dispatches to the right entry agent.

What this pattern forbids. An agent may only call across domains via the standardised protocol; ad-hoc backdoor integrations between domain agents are forbidden.

The smaller patterns that complete this one —

  • usesSupervisor★★— Place a coordinating agent above a set of specialised agents and route work to them.
  • usesHandoff★— Transfer the active conversation from one agent to another, carrying context across the switch.
  • usesInter-Agent Communication★— Define a protocol for agents to exchange tasks, capabilities, and results across process or vendor boundaries.
  • usesModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.
  • usesRole Assignment★★— Assign each agent a named role (researcher, writer, critic, planner) with a role-specific prompt, tool palette, and acceptance criteria.

And the patterns that stand alongside it, or against it —

  • alternative-toHero Agent✕— Anti-pattern: stuff every capability into one agent with one giant prompt.
  • alternative-toDecentralized Agent Network·— Agents publish signed DID+JSON-LD identity records so any peer can discover and verify them without a central registry — the agent equivalent of the open web.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance