Catalog / Agents & Process Automation / AGENT-013

Multi-agent systems for complex end-to-end business processes

Orchestrate several specialised AI agents (planner, domain workers, reviewer) that hand off work across tools and systems to run a whole business process such as order-to-cash or claims, with humans approving critical steps.

Parts needed to run it yourselfAgents & automationLanguage modelSearch & RAG

Single agents handle one task well, but processes like order-to-cash, claims or customer onboarding cross many systems, roles and policies. Multi-agent systems split such a process among specialised agents (router, domain workers, checker) coordinated by an orchestrator or a workflow engine. Done well they automate the routine path and escalate exceptions; done badly they multiply errors, cost and audit gaps. The pragmatic pattern in 2026 is a deterministic workflow skeleton with agents inside bounded steps.

Problem & value

  • Today: end-to-end processes are stitched together from RPA bots, rule engines, email and people handing over between departments. Exceptions (missing data, conflicting documents, policy edge cases) consume most manual effort and are hard to script.
  • AI value: agents interpret unstructured inputs, choose tools, and resolve exceptions that rules cannot enumerate; specialisation keeps each agent's prompt, tools and permissions small and testable.
  • Evidence is mixed: Anthropic advises starting with the simplest solution and using agents only where flexibility is needed, noting that agents trade cost and latency for capability [1]. Gartner has predicted that over 40% of agentic AI projects will be cancelled by end of 2027 owing to cost, unclear value or inadequate risk controls [5]. Treat vendor ROI claims cautiously and measure your own baseline.

Variants

  • Supervisor/worker: one orchestrator delegates to specialist agents (e.g. extraction, policy check, communication).
  • Workflow-with-agents: fixed graph (BPMN/state machine) where only selected nodes are agentic; best for regulated processes.
  • Peer/handoff: agents transfer control to each other (customer-facing triage to back-office agent).
  • Cross-organisation: agents of different companies negotiate via A2A (e.g. supplier and buyer); still rare.
  • Industry flavours: insurance claims (AGENT-014), KYC (AGENT-015), order-to-cash (AGENT-023), public administration (AGENT-026), IT operations (AGENT-016).

How it works

  1. trigger (email / event / ticket / schedule)
  2. orchestrator: plan + route (workflow graph or supervisor LLM)
  3. worker agents with scoped tools (MCP servers / APIs): read, extract, look up, draft, act
  4. checker agent / rule validators (policy, maths, permissions, injection filters)
  5. human approval gate (thresholds, irreversible or personal-data-affecting actions)
  6. system-of-record write + audit log + trace
  7. evaluation and monitoring loop (AGENT-025)
  • Tool access: Model Context Protocol (MCP) standardises how agents reach tools and data; the Agent2Agent (A2A) protocol standardises agent-to-agent calls via Agent Cards. Both now sit under the Linux Foundation's Agentic AI Foundation [2][3].
  • State and memory: durable execution (checkpoints, resumable runs) so long processes survive failures and human waits.
  • Human-in-the-loop: approvals for payments, customer commitments, deletions and any decision about individuals.
  • Least privilege: each agent gets its own identity and minimal scopes; no shared super-user credentials.

Data preparation

Multi-agent systems need less training data than they need clean process knowledge and system access. Relevant data: process definitions and SOPs (often only in people's heads, Word files or the DMS), approval limits and rules, master data in ERP/CRM, e-mails and attachments, and ticket histories. Typical gaps: undocumented exceptions, outdated SOPs, duplicate or inconsistent master data, scanned attachments without text, scattered knowledge on file shares, and overly broad service-account rights.

Preparation steps: (1) write the target process down as a decision table with owners and exceptions; (2) clean the master data the agents will read or write (see PREP-005 for exports and APIs, PREP-011 for tidy tables); (3) turn rules and SOPs into an authoritative knowledge base (PREP-013, PREP-016); (4) expose systems through narrow, least-privilege tool interfaces (API or MCP) instead of broad accounts, and clean up permissions first (PREP-023); (5) build 30-50 real historical cases with the correct outcome as an evaluation set (PREP-018). Scans need OCR first (PREP-006, DOC-014).

Effort: roughly 30-40 % of the project, mostly process documentation and access design rather than data cleaning. See GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

  • SMB: Path B - no product covers an SMB's own mix of ERP, mail and approval rules, so a small workflow (n8n or a vendor workflow tool) with cloud model APIs, started on one narrow process, fits best.
  • Enterprise: Path B - the process is core and must integrate with existing systems; a shared internal agent platform may later shift parts to Path C.
  • Developer: Path C - open frameworks plus open-weight models give full control over tool access, tracing and evaluation.

Path A — Buy (off-the-shelf)

  • Enterprise suites: Microsoft Copilot Studio / Azure AI Foundry Agent Service, Salesforce Agentforce, ServiceNow AI Agents, SAP Joule agents, UiPath Agentic Automation, Google Gemini Enterprise / Vertex AI Agent Builder, AWS Bedrock AgentCore.
  • EU vendors: SAP (DE), Camunda (DE, agentic orchestration on BPMN), Mistral AI agents (FR), Aleph Alpha/PhariaAI (DE), Celonis (DE, process intelligence feeding agents), n8n (DE, fair-code).
  • Choose A when: your systems of record are already from one vendor and the process fits its pre-built agents.
  • Frameworks: LangGraph, Microsoft Agent Framework (AutoGen/Semantic Kernel successor), OpenAI Agents SDK, Claude Agent SDK, Google ADK, CrewAI, LlamaIndex; Temporal or Camunda for durable orchestration.
  • Models: frontier reasoning models (Claude, GPT, Gemini) via EU regions, or Mistral (EU provider); small models for routing and extraction to reduce cost.
  • Integration: MCP servers for internal systems, A2A for cross-agent calls, OpenTelemetry GenAI conventions for tracing.
  • Choose B when: you need process-specific logic, EU data residency and control over approvals.

Path C — Self-host (open source)

  • Models: open-weight reasoning/tool-use models such as Qwen3, gpt-oss, DeepSeek, Mistral/Magistral families served with vLLM or Ollama.
  • Stack: LangGraph, CrewAI, AutoGen/AG2 or Google ADK; Temporal or Camunda 8; Langfuse or Arize Phoenix for observability; Qdrant/pgvector.
  • Hardware: HW3 (one 48-141 GB GPU) for ~30-120B tool-calling models; HW4 for high concurrency.
  • Choose C when: data cannot leave the premises (public sector, health, finance) and you have platform engineers.

Path D — Custom training

Seldom justified at first. Later, fine-tune a small model on logged trajectories (successful tool-call sequences, reviewer corrections) to replace an expensive frontier model in high-volume steps; requires thousands of curated traces and an evaluation harness.

State of the art (2026)

  • Convergence on protocols: MCP for tools and A2A for agent interoperability, both hosted by the Agentic AI Foundation since 2026 [2][3].
  • Architecture lessons: Anthropic's multi-agent research system showed large gains from parallel sub-agents on breadth-heavy tasks but at far higher token usage, and noted that coordination, evaluation and non-determinism are hard [4]. Many production teams therefore prefer few agents, explicit workflows and strong tracing.
  • Failure modes: error compounding over long chains, looping, tool misuse, context loss at handoffs, prompt injection through emails/documents spreading between agents, unclear accountability, runaway cost.
  • Benchmarks: agentic benchmarks (tau-bench, WebArena/OSWorld, SWE-bench) show steady progress yet reliability on multi-step enterprise tasks across repeated runs remains well below human consistency; run your own end-to-end evaluations.

Shared resources & combinations

  • Same stack: AGENT-002 (workflow engine), AGENT-003 (computer-use for legacy UIs), AGENT-025 (observability, evals, governance), guardrails and identity layer.
  • Process agents built on it: AGENT-006 financial close, AGENT-014 claims, AGENT-015 KYC, AGENT-023 order-to-cash, AGENT-026 public administration.
  • Hardware: one HW3 inference server can serve several agent systems; vector store shared with RAG use cases.

Effort, cost & KPIs

  • Path A: weeks to pilot; licence plus consumption pricing per agent action or conversation.
  • Path B: 3-9 months for a first production process incl. evaluation, approvals and integration.
  • Path C: 6-12 months incl. platform build; GPU server plus MLOps staff.
  • Cost drivers: tokens per run (multi-agent often several times a single agent), integration work, evaluation and governance.
  • KPIs: straight-through rate, cost per completed case, cycle time, escalation rate, human override rate, task success across repeated runs, policy violations, incident count.

People & change

Involve management (scope, budget, approval limits) and the department lead as process owner from the start; IT and IT security design tool access and logging; data owners release the sources; the DPO joins early if personal data (customers, employees) is touched, and a DPIA is likely when agents decide about people or run at scale. AVV (Art. 28 GDPR) is needed with every model or platform provider.

Works council: depends. Agents that log which employee approved, corrected or overrode what create objectively suitable monitoring data, so §87(1) no. 6 BetrVG usually applies as soon as approval and trace logs are tied to named users; in any case §90(1) no. 3 requires timely information when work processes are planned with AI, and §80(3) allows an AI expert. In the public sector the staff council (Personalrat) applies. Only companies with an elected works council are affected.

Take measures to support AI literacy (AI Act Art. 4): train the approvers on failure modes and escalation. Pick one narrow process and a small pilot team of volunteers, communicate that the agent takes over routine steps while humans keep approval for money, contracts and exceptions, and report error rates openly. Typical concerns (job loss, blame for agent errors) are met with clear responsibility rules and a kill switch. Guides: GUIDE-004, GUIDE-008, GUIDE-009.

Risks, regulation & compliance

  • EU AI Act: depends on the process. Back-office automation without decisions about people is minimal risk (AI literacy, Art. 4). Agents that select candidates, score creditworthiness, price insurance or decide on benefits fall under Annex III high-risk (Art. 6, obligations incl. risk management, logging, human oversight, Art. 9-15). Agents that interact with people must disclose AI (Art. 50). Art. 5 prohibitions (e.g. social scoring, emotion inference at work) must not be built into any agent step. [6]
  • GDPR: Art. 22 limits solely automated decisions with legal or similar effects; define lawful basis, purpose limitation per agent, data minimisation in shared memory, DPIA for personal data, processor agreements with model and tool vendors.
  • Security: OWASP Top 10 for LLM applications (prompt injection, excessive agency) applies; also NIS2 and DORA for in-scope firms.
  • Mitigations: least-privilege identities, allow-lists of tools, approval gates, kill switch, immutable audit trail, red-team tests, staged autonomy.

Getting started

  1. Pick one process with measurable volume and a clear exception path; map it as a workflow before adding agents.
  2. Prove a single agent plus deterministic workflow first; add agents only where a step needs separate tools, permissions or evaluation.
  3. Expose systems through MCP/API with scoped credentials; define approval thresholds and a kill switch.
  4. Build an evaluation set from 100+ real historical cases and trace every run (see AGENT-025).
  5. Run in shadow mode, then assisted mode, and raise autonomy only when override rates are stable.

Sources

  1. Anthropic — Building effective agents — https://www.anthropic.com/engineering/building-effective-agents
  2. Axios — A2A protocol gets a new home at the Agentic AI Foundation (Aug 2026) — https://axios.com/2026/08/17/a2a-agentic-ai-foundation-open-ai-standards
  3. Model Context Protocol specification — https://modelcontextprotocol.io
  4. Anthropic — How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
  5. Gartner — Over 40% of agentic AI projects will be canceled by end of 2027 (press release, June 2025) — https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
  6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  7. LangGraph documentation — https://langchain-ai.github.io/langgraph/
  8. OWASP Top 10 for LLM Applications — https://genai.owasp.org/llm-top-10/