Skip to main content

A2A Integration

How the platform interfaces with external carrier and broker agents across three integration maturity models — all coexisting simultaneously.

Integration Maturity Models​

Model 1 — BP Managed​

Carrier is passive. BP owns appetite, eligibility, and question set logic. Carrier exposes only Quote/Bind APIs. No agent-to-agent communication — pure API integration.

Model 2 — Distributed​

Carrier owns their logic (appetite, eligibility, question sets). Partner Engine maintains wrapper layers that call out to carrier systems. Still API-based — the wrappers are integration adapters, not agents.

Model 3 — True Agentic​

Carrier has their own Orchestrator Agent, deep agents, and Carrier MCP server. Fully autonomous carrier-side intelligence. Requires A2A protocol layer between BP and carrier systems.

info

All three models coexist simultaneously — different carriers at different maturity levels. Outbound agents adapt per counterparty — same pipeline, different topologies.

A2A Architecture — Distributed Agent Communication​

flowchart LR U(["User"]):::human ORCH["BP Orchestrator"]:::orch MCP["Insurance Intelligence MCP"]:::mcp BAM["Broker Agent Manager"]:::bam CAM["Carrier Agent Manager"]:::cam A2A["A2A Server"]:::a2a BA(["Broker Agent"]):::ext CORCH["Carrier Orchestrator"]:::carrier CMCP["Carrier MCP"]:::carrier PAS["PAS / Core Systems"]:::pas U --> ORCH ORCH --- MCP MCP --- BAM MCP --- CAM BAM --- A2A CAM --- A2A A2A --- BA A2A --- CORCH CORCH --- CMCP CMCP --- PAS classDef human fill:#92400e,color:#fef3c7,stroke:#b45309,stroke-width:2px classDef orch fill:#1d4ed8,color:#fff,stroke:#1e40af,stroke-width:2px classDef mcp fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:2px classDef bam fill:#0e7490,color:#fff,stroke:#0891b2,stroke-width:2px classDef cam fill:#7c3aed,color:#fff,stroke:#6d28d9,stroke-width:2px classDef a2a fill:#6d28d9,color:#fff,stroke:#5b21b6,stroke-width:2px classDef ext fill:#991b1b,color:#fecaca,stroke:#b91c1c,stroke-width:2px classDef carrier fill:#dc2626,color:#fff,stroke:#b91c1c,stroke-width:2px classDef pas fill:#991b1b,color:#fecaca,stroke:#b91c1c,stroke-width:1px

Legend: 🟤 User · 🔵 BP Orchestrator · 🟦 MCP Server · 🔷 Broker Agent Mgr · 🟣 Carrier Agent Mgr · 🟪 A2A Server · 🔴 Carrier Systems

Four MCP clients, one tool server. The BP Orchestrator, A2A Server, and Outbound Agent Managers all connect to the Insurance Intelligence MCP Server. The A2A Server is the protocol boundary between BP and external agents — all traffic passes through it. Outbound Agent Managers handle business logic with different graph topologies per counterparty.

Outbound Deep Agents​

A2A Server (Protocol Boundary)​

Stateless: Validate → Classify → Route. Not a deep agent. The protocol boundary between BP and external agents. Inbound: validates identity, classifies request, routes to MCP tools. Outbound: agent managers communicate through it. Deterministic pipeline with input sanitization.

Agent Managers (Broker + Carrier)​

CapabilityBroker Agent ManagerCarrier Agent Manager
LifecycleSubmission lifecycle: intake → docs → forward → status → bindNegotiation lifecycle: submission → UW conversation → pricing → conditions → bind
Adversarial AwarenessEligibility probing, MI model gaming, appetite miningCross-tenant PII, internal data extraction, scope escalation
Hardened GraphLLM confined to classify + compose nodes. Authorization and data classification gates are graph nodes, not prompt instructions.Same structural enforcement — graph topology differs per counterparty.

Outbound Agent Processing Pipeline​

Both outbound agents use this hardened pipeline. Graph topology differs per counterparty — same structural enforcement.

Receive Message → Classify Request (LLM) → Lookup Data (MCP) → 🔴 Authorization Gate → Compose Response (LLM) → 🔴 Data Classification → Send Response → Audit Trail

Node TypeRole
🟣 LLM (confined)Classify and compose only — no flow control
🟢 MCP Tool (deterministic)Data lookup via MCP tools
🔴 Structural GateAuthorization and data classification — graph nodes, not prompts
🟤 A2A ProtocolMessage receive/send boundary
🟢 AuditFull audit trail on every node transition

A2A Task Lifecycle​

flowchart LR SUB(["submit_to_carrier"]):::tool SUBMITTED["submitted"]:::state WORKING["working"]:::state INPUT["input-needed"]:::input COMPLETED["completed"]:::done FAILED["failed"]:::fail SUB --> SUBMITTED --> WORKING WORKING --> INPUT INPUT -->|"auto-resolved"| WORKING INPUT -->|"needs broker"| WORKING WORKING --> COMPLETED WORKING --> FAILED classDef tool fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:1px classDef state fill:#1d4ed8,color:#fff,stroke:#1e40af,stroke-width:1px classDef input fill:#d97706,color:#fff,stroke:#b45309,stroke-width:2px classDef done fill:#059669,color:#fff,stroke:#047857,stroke-width:2px classDef fail fill:#dc2626,color:#fff,stroke:#b91c1c,stroke-width:2px

Legend: 🟦 Tool Call · 🔵 Task State · 🟠 Input Needed · 🟢 Completed · 🔴 Failed

Why Graph-Based, Not Flexible Orchestrator​

  • Structural enforcement — authorization and data classification gates are graph nodes, not prompt instructions. The LLM cannot bypass them.
  • Confined LLM reasoning — the LLM operates at two specific nodes (classify, compose). It does not control flow. The graph controls flow.
  • Deterministic audit trail — every node transition is logged. Required for regulatory compliance.
  • Attack surface reduction — external messages pass through input sanitization before reaching any LLM node.