Multi-agent systems: Architectures, frameworks, and where humans decide in insurance

Multi-agent systems split a complex task across several coordinating agents instead of one program. That flexibility has a price: less predictability and auditability, which are the two properties a regulated insurer weighs most. This article covers the five design choices that decide whether the pattern fits. The architecture, centralized or decentralized, shapes your audit trail and how the system fails. The agent type, reactive, deliberative, or hybrid, trades latency for adaptability. The framework sets how much orchestration you write yourself. The learning approach decides whether the system improves from data or stays fixed between releases. In insurance, the fifth choice is where human decisions sit. For claims and underwriting, the article adds an orchestrator-specialists-human design pattern. It shows where that pattern fails and which controls keep it supervisable.

Conceptual framing: Multi-agent vs. single-agent systems

A single-agent system concentrates reasoning, tool use, and decisions in one model instance. A multi-agent system distributes that work across several autonomous, interacting agents in a shared environment. The difference matters architecturally. A single agent either completes the task or fails it, while a multi-agent design can degrade gracefully if individual agents fail, provided coordination is designed for it.

Multi-agent systems (MAS) are valuable for large-scale, complex tasks that can involve hundreds or thousands of agents, but that scale brings coordination overhead absent from single-agent designs. Each agent operates with a degree of autonomy and can act and decide independently.

How agents are classified

Agents are commonly classified by how they decide. Reactive agents respond to stimuli through condition-action rules without internal state. Deliberative agents keep an internal model of the world and plan before acting. Hybrid agents combine both: reactive behavior for time-critical responses, deliberation for longer-horizon planning. Each agent in a MAS has individual properties, while all agents behave collaboratively to produce the desired global properties.

Google Cloud notes that single-agent systems suit tasks where interaction is minimal and centralized control is efficient, such as recommendation engines or fraud detection, and that they are simpler to develop, with lower maintenance costs and more predictable outcomes. That is a useful default: start with one agent, and add agents only when the task genuinely decomposes.

Architectures and components of multi-agent systems

MAS can operate under centralized or decentralized architectures. In a centralized network, a central unit contains the global knowledge base, connects the agents, and oversees their information. This simplifies auditability, because every decision passes through a traceable coordination point.

In a decentralized network, agents coordinate peer-to-peer without a single point of control. That improves fault tolerance but makes the decision path harder to reconstruct afterward. A hierarchical arrangement, with agents at different levels of autonomy, works as a hybrid of the two.

Every MAS, whatever its architecture, has four core components:

• the agent: the autonomous decision-making unit;
• the environment: virtual or physical, shared by all agents;
• the communication layer: agent communication languages such as FIPA ACL and KQML give agents a standard way to interact and share information;
• the coordination mechanism: the methods agents use to resolve disagreements, align on goals, and work as a team, such as bidding for tasks, voting, or contract nets.

Agent behaviors and interactions

Coordination, communication, and negotiation determine whether a system’s emergent behavior is reliable or chaotic. To align their actions, agents can follow predefined protocols or strategies. Contract Net Protocol schemes allocate tasks through bidding; market-based mechanisms use price-like signals to allocate resources; stigmergy lets agents coordinate indirectly by changing a shared environment.

Coordination in production LLM systems

In production LLM-based systems, the coordination pattern has a direct effect on reliability. Anthropic’s account of its research system describes a lead agent that plans the work and hands subtasks to subagents running in parallel. LangChain’s analysis of that post and of Cognition’s opposing post draws two shared lessons.

First, context engineering (giving each model exactly the context it needs) is one of the hardest parts of the work. Second, agent systems that mainly “read” are easier to build than those that “write,” because conflicting writes typically produce far worse outcomes than conflicting reads. Production agents can run conversations spanning hundreds of turns, which requires deliberate context management. Agents are also stateful, so errors compound: a small early failure can cascade without mitigation.

Advantages and use cases

Multi-agent systems can handle complex, dynamic, or large-scale challenges that would overwhelm a single agent or a large, monolithic program. Their advantages include scalability, robustness, and flexibility. Scalability comes from decomposition into parallel subtasks. Robustness comes from the absence of a central coordinator as a single point of failure in decentralized designs. Flexibility comes from the ability to replace or specialize one agent without redesigning the rest.

Typical deployments of MAS include supply chain management, where agents connect stages from manufacturing to consumer purchase, and transportation, where they coordinate train networks, truck assignments, or ships.

Anthropic reports that multi-agent research setups excel at breadth-first queries that pursue several independent directions at once. On its internal research evaluation, a system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2%. Breadth-first research of that kind resembles due-diligence and compliance-review work in financial services.

Multi-agent systems in insurance: Claims and underwriting

Insurance processes decompose naturally into specialized steps, which makes them good candidates for agent designs. The pattern that fits supervision best is orchestrator-specialists-human: an orchestrating agent splits the case, specialist agents each do one bounded task, and a person makes the decision that changes the customer’s position.

Claims handling

An intake agent reads the first notice of loss and attached documents and extracts the facts. A coverage agent compares those facts with the policy wording and flags the clauses that apply. A fraud-signal agent checks the case against known patterns and explains each alert. The orchestrator assembles a case summary with the evidence for each finding, and a claims handler decides on coverage and payment. All specialist agents in this design only read; the single write (the decision in the claims system) is made by a person.

Underwriting support

A data-gathering agent collects the application, prior policies, and external data. A summarizing agent prepares the case for the underwriter, with sources for each fact. Any risk score comes from a validated model, not from a language model’s judgment, and the underwriter decides.

This matters legally: AI systems for risk assessment and pricing of natural persons in life and health insurance are high-risk under the AI Act (Annex III, point 5(c)). These obligations apply from December 2, 2027. A system listed in Annex III that profiles natural persons is always high-risk, so supporting agents do not automatically fall outside this scope (Article 6(3)).

Where these designs fail

The failure modes in the general literature apply directly:

• Writes to core systems. Write-heavy agent systems are harder to make reliable. An agent that updates a policy or a claim reserve should not do so without a human approval step.
• Compounding errors. A wrong extraction in the intake step propagates through every later agent. Each specialist should pass on its evidence, not only its conclusion, so that the handler can see where a chain went wrong.
• Non-determinism. Agents can decide differently between runs, even with identical prompts. A supervisor reviewing a decision needs the log of what each agent saw and returned for that specific case.

Security of agents that read customer documents

Claims and underwriting agents read text that outsiders wrote: claim forms, letters, attachments, emails. OWASP lists prompt injection as the first risk for LLM applications and describes indirect injection, where an LLM accepts input from external sources, such as websites or files, and that content alters the model’s behavior.

In an agent chain, one manipulated document can steer every agent after it. Treat every document as data, never as instructions; give each agent only the tools its task needs; and keep the write step with a person. Cisco’s 2025 study shows how far most organizations are from this: 83% plan to deploy AI agents, but only 31% overall say they are fully equipped to control and secure them, compared with 75% of the most AI-ready companies.

How to keep them supervisable

Three controls follow from the rules that apply, or will apply, to these systems. Log every handoff: the AI Act requires automatic record-keeping for high-risk systems (Article 12), and EIOPA’s Opinion lists record-keeping among its expectations for other AI systems in insurance. Define where a person reviews or overrides: human oversight is an AI Act requirement for high-risk systems (Articles 14 and 26) and part of EIOPA’s framework.

Finally, classify the use case before the design is fixed, because the classification decides how much of this is mandatory. The control matrix in Artificial intelligence governance for insurers maps who owns each of these controls.

Challenges and limitations

The most consequential limitation in production is cost. Heavy reliance on LLMs through API calls can lead to significant computational cost, and scaling can become prohibitively expensive if not managed. Cost grows with the number of agents and coordination rounds, not only with task complexity. Non-determinism makes reproducing a specific failure harder than in a deterministic pipeline. Synchronizing many agents adds coordination overhead, and, without mitigation, minor failures can escalate.

In regulated settings, two further constraints apply. First, decision paths must be reconstructable after the fact, which centralized architectures support more naturally than decentralized ones. Second, runtime monitoring becomes essential precisely because of the non-determinism. Data monitoring for AI and regulatory reporting covers the data side of that monitoring.

• Scaling can become prohibitively expensive if not managed
• Non-determinism between runs complicates debugging and audit
• Errors compound across stateful agents
• Decentralized architectures trade audit traceability for fault tolerance

Frameworks for multi-agent systems

Choosing a framework means matching its orchestration style to your production constraints. No framework is best on every axis. Three questions separate them: how much control over orchestration you keep, whether the project is actively maintained, and how easily it exposes the structured logs a regulated deployment needs.

Enterprise deployment perspective

In a sandbox, framework choice follows developer speed. In a regulated production environment, check first that the framework, or your wrapper around it, can emit a structured, timestamped log of every inter-agent decision and handoff, because that log is what an auditor asks for after an incident. Also check that the project is maintained: a framework without security fixes is a liability in a core insurance process.

The most important caveat sits outside the table. Anthropic and Cognition published posts with opposite titles (“How we built our multi-agent research system” and “Don’t Build Multi-Agents”), yet both point to context engineering as the hard part, and to read-heavy systems as easier than write-heavy ones. That distinction should weigh more in your choice than any single framework’s feature list.

Learning approaches

Learning approaches decide whether agents improve from experience or stay fixed between releases. Supervised learning trains on labeled historical data and suits stable subtasks such as document classification, but it degrades when the environment changes faster than labels can be produced. Reinforcement learning lets agents learn from rewards in their environment.

Multi-agent reinforcement learning (MARL) is a research field of its own; Zhang, Yang, and Başar give an overview of its theory and algorithms. Its central practical difficulty is that each agent’s learning changes the environment the other agents face. Evolutionary methods optimize populations of agents through selection and variation and are typically used when rewards are too sparse for standard reinforcement learning.

In most enterprise LLM-agent systems, “learning” does not mean retraining. Anthropic describes improving its research system mainly through prompt engineering. For an insurer, that is the realistic path: improve instructions, tools, and evaluation, and keep any model that scores risk under the model-validation process.

Methodology and limitations of this article

Methodology scope: enterprise deployment of multi-agent systems, where auditability, reliability, and compliance shape the evaluation, not academic benchmarking.

What this does not address: agent-based simulation for research and performance benchmarks of specific frameworks against standard test suites.

Prerequisites: familiarity with distributed systems, LLM-based application architecture, and basic AI/ML terminology.

Source basis: the sources linked in the text, including the primary posts by Anthropic and Cognition, the framework repositories, and the AI Act and EIOPA texts for the insurance section. Framework status was checked in November 2026.

Limitations

The framework table compares architecture, maintenance, and license, not performance; treat it as a shortlist and test candidates on your own workload. The enterprise lens underweights considerations that matter more in research, such as raw accuracy on open benchmarks. Framework status also changes quickly: AutoGen went from one of the most discussed frameworks to a project Microsoft no longer actively maintains, so re-check the status before you commit.

Checklist for selecting and deploying multi-agent systems

The six steps below condense the article into a pre-deployment check. Each row links back to the section that explains it.