The Protocol Is the Architecture

How the A2A protocol replaces fax, phone, and portal chaos with typed, auditable agent negotiation — and why the choice of protocol is the primary architectural decision.

Two aircraft approaching the same airspace represent the core coordination problem in enterprise AI. Neither pilot can see inside the other's cockpit. Neither aircraft shares systems with the other. A coordination failure has consequences that cannot be undone.

Air traffic control solves this not by connecting the aircraft's internal systems, but by establishing a protocol: a standardized language both parties speak regardless of who built the plane, where it was registered, or which airline is flying it. The protocol is the coordination mechanism. What happens inside the cockpit is irrelevant to the controller.

Prior authorization between a healthcare provider and a payer has the same structure. Two organizations, separate systems, no shared codebase, and a decision with direct patient consequences at the end. The current process handles this with fax, phone, and portal uploads. The information gets through eventually. The protocol is chaos. Every transaction is a bespoke negotiation.

The auth-a2a-agent-network replaces that chaos with something the air traffic control analogy describes precisely: two AI agents that share nothing except the protocol.

What This Prototype Does

The software terms in this article reference the agent network code at github.com/paullopez-ai/auth-a2a-agent-network. The real-time Review UI is at github.com/paullopez-ai/auth-a2a-agent-network-ui.

The concrete system implements two agents: Provider Agent and Payer Agent, each running as an independent Express server with a separate LangGraph pipeline, communicating exclusively over the Google A2A protocol (HTTP, SSE, JSON-RPC 2.0). Three runnable demo scenarios demonstrate the full negotiation cycle. The Demo Track requires zero API keys via MOCK_LLM=true for immediate testing. The Hyperscaler Track scaffolds AWS ECS Fargate plus Bedrock plus Terraform for the production deployment path.

The Architecture Decision: No Shared Code

The most important constraint in this prototype is also the most unusual one for a system built by a single developer: the Provider Agent and the Payer Agent share no code. No common imports. No shared state. No common pipeline logic. They run on separate ports, maintain separate LangGraph StateGraphs, and communicate exclusively through A2A messages.

This constraint is not an engineering exercise. It is an architectural argument. In real healthcare operations, a provider organization and a payer organization do not share internal systems. They do not have access to each other's pipelines. They communicate through transactions: structured messages with defined formats and acknowledged receipt. An architecture that allows agents from these two organizations to share state, share imports, or call each other's internal functions is modeling the wrong reality.

The A2A protocol enforces this separation at the design level. The only thing the Provider Agent knows about the Payer Agent is its A2A Agent Card: a formal declaration of the Payer Agent's capabilities, its accepted input types, its returned output structure, and its interaction modalities. Writing the Agent Card is a specification exercise. The protocol requires declaration as a precondition to communication. An agent that cannot declare what it does cannot participate.

This is the constraint that produces composability. A payer agent built on a different framework, running on a different cloud, written by a different team, can participate in the same network without modification to the Provider Agent, as long as it speaks A2A and publishes an Agent Card. The protocol is the contract. The implementation is irrelevant.

The Negotiation: Multi-Turn on a Single Task ID

Scenario 2 is the primary demonstration, and its design captures the most important insight about prior authorization as a workflow. A real authorization is not a request and a response. It is a negotiation. The payer evaluates the initial submission, determines that documentation is incomplete, and returns an input-required status. The provider responds with additional documentation, using the same task ID. The payer re-evaluates against the original criteria plus the new documentation and returns a final determination.

A single task ID tracks the entire lifecycle: initial submission, denial, appeal, and final outcome. This is not a coincidence of the A2A design. It is the protocol's model of how multi-turn work behaves: one task, multiple turns, state accumulated on the task object across every exchange.

The Provider Agent's five-node pipeline handles this through AppealNode, which fires when the Payer returns input-required. AppealNode does not create a new request. It resubmits on the same task ID with the supplemental documentation attached. The Payer Agent's six-node pipeline then runs the same evaluation sequence: RequestParseNode, CriteriaLookupNode, EvaluationNode, DeterminationNode, against the new evidence. The task state advances from input-required to completed. The determination artifact reflects the full context of the negotiation, not just the final round.

Each stage in both pipelines has a different failure mode. That is why each stage has a distinct architectural boundary. RequestParseNode can fail on malformed input. CriteriaLookupNode can fail on a missing MCP server (it falls back to embedded synthetic criteria rather than breaking the pipeline). EvaluationNode can fail on ambiguous clinical evidence. DeterminationNode can produce a low-confidence result that requires human routing rather than an automated decision. Separating these stages means each failure is visible, catchable, and handled without contaminating the others.

The Trust Boundary: Code That Cannot Be Bypassed

Every determination produced by the Payer Agent carries a trust boundary classification. Confidence above 0.8 returns as Autonomous: the pipeline proceeds to completion without human intervention. Confidence between 0.5 and 0.8 routes to HumanReviewNode and returns as Supervised: the pipeline physically halts, waits for a human decision, and carries that decision forward as the final determination.

The word "physically" is deliberate. The HumanReviewNode fires as an interrupt-before pattern in the LangGraph StateGraph. The pipeline cannot proceed past that node without a human decision input. There is no confidence threshold that could accidentally allow a 0.79 determination to slip through to Autonomous. The routing condition is a state machine edge, not a runtime check that could be bypassed by a model that produces a slightly higher confidence score than expected.

This is the difference between encoding organizational risk tolerance as a governed architectural parameter and implementing it as a runtime safeguard. Runtime safeguards are subject to edge cases, model drift, and downstream refactoring. A state machine edge is not. The LangGraph graph structure is the guarantee.

The TrustBoundaryClassification enum in determination.ts makes this classification explicit at the type level. Every determination artifact carries Autonomous or Supervised as a typed field alongside the confidence score, the criteria evaluated, the rationale, and the timestamp. No determination leaves the pipeline without attribution. That is not logging. That is the audit trail as a design requirement, not an afterthought.

The Review UI: Observer With One Write Path

The auth-a2a-agent-network-ui implements no agent logic, no pipeline logic, and no protocol logic. It operates as a read-only observer of the A2A exchange, plus a single write path: the human review decision posted back to the Payer Agent's task continuation endpoint.

Four screens provide complete visibility: Network Dashboard shows active agents and their capabilities. Task Stream displays real-time events from both agents as they negotiate. Task Detail provides full context for any specific authorization request. Human Review Panel surfaces pending determinations that require clinical judgment, with the reviewer's decision flowing back through the same A2A protocol boundary.

The SSE relay fans in task events from both agents through useTaskStream(), so the human reviewer sees the full negotiation as it happens, not a post-hoc summary. This design principle matters: the UI's single write path goes back through the A2A protocol, not through a side channel. The human reviewer's decision enters the system through the same protocol boundary as every other message. No backdoors. No administrative overrides. The protocol is the only way messages get into the system.

The Production Gap

The Hyperscaler Track scaffold (AWS ECS Fargate, Amazon Bedrock, Terraform) is reviewed and structured but not applied. It demonstrates the production deployment pattern without incurring ongoing cloud costs. The gap between scaffold and applied deployment is smaller than the gap between monolithic design and protocol-isolated design. The hard architectural decisions, agent isolation, protocol boundary, typed determination artifacts, interrupt-before human review, are already resolved. What the scaffold does not yet provide is production network isolation between the two agents, authentication between the Provider and Payer services, and a persistent task store that survives container restarts.

These are implementation gaps, not architectural gaps. The design decisions that would be difficult to retrofit (agent isolation, protocol contract, trust boundary classification) are built in. The production gaps are the ones that can be added without touching the core architecture.

What This Architecture Demonstrates

The pattern in this prototype applies beyond prior authorization. Any enterprise workflow that crosses an organizational boundary, claim adjudication, referral management, benefits verification, credentialing, has the same structure: two parties who share no internal systems and need to reach a binding decision with an auditable record.

The temptation in building these systems is to treat the organizational boundary as a technical inconvenience and route around it: shared database, shared microservice, direct API call into the other party's system. That approach produces integrations that work until one side changes something, and then fails in ways that are invisible until they cause a wrong decision downstream.

The A2A approach treats the organizational boundary as a design constraint that the architecture must express honestly. Two agents. No shared code. One protocol. The protocol boundary is the trust boundary. Every message that crosses it is typed, acknowledged, and attributed. Every failure is explicit. The system degrades by returning input-required or failed states, not by silently producing plausible wrong answers.

Enterprise AI programs that are building toward multi-agent coordination need to make this decision early. The choice of inter-agent communication pattern is not an implementation detail that can be swapped out later. It determines whether the system is auditable, whether agents can be replaced independently, and whether the architecture models the organizational reality it is supposed to serve.

The Healthcare Context: $35 Billion in Administrative Chaos

The economic case for this architecture comes from the scale of the current dysfunction. Physicians spend 16 hours per week fighting prior authorization paperwork instead of treating patients. That administrative burden costs the healthcare system $35 billion annually, with 93% of physicians reporting care delays due to prior authorization processes.

The 2027 CMS mandate for electronic prior authorization creates regulatory urgency. Medicare Advantage and state Medicaid programs must implement FHIR R4 compliance and support Provider Access API and Payer-to-Payer API by January 1, 2027. Early adopters of automated systems report 78% reduction in processing time, with 65% of routine prior authorizations suitable for full automation using current technology.

Healthcare organizations are responding to both the regulatory pressure and the economic opportunity. 45% of health systems are actively piloting or implementing AI-powered prior authorization, driving a $2.4 billion market for healthcare administrative automation. The organizations moving first are establishing the technical patterns that will become industry standards.

The auth-a2a-agent-network prototype demonstrates how those standards might work: human-supervised automation with interrupt-before patterns for complex cases, full audit trails for regulatory compliance, and protocol-based coordination that survives organizational boundaries. The technical approach matters because the regulatory mandate is fixed, but the implementation choices made in 2025 and 2026 will determine whether the industry gets interoperable systems or just digitized chaos.

Close

The air traffic control system does not require every aircraft manufacturer to build the same cockpit. It requires every aircraft to speak the same radio protocol. That constraint, a common language with no shared internals, is what makes safe coordination possible across thousands of aircraft from dozens of manufacturers flying in shared airspace every day.

A prior authorization is a negotiation between two organizations that will never share a codebase. The protocol is the only thing they have in common. That is not a limitation. That is the design.

References

[1] American Medical Association. (2024). "2024 AMA Prior Authorization Physician Survey." AMA Practice Management

[2] American Medical Association. (2024). "Practice Benchmark Survey: Administrative Burden Report." AMA Health Policy Research

[3] American Medical Association. (2024). "Prior Authorization Reform: Patient Care Impact Study." AMA Advocacy Resource Center

[4] Centers for Medicare & Medicaid Services. (2024). "Electronic Prior Authorization Final Rule Update." Federal Register, Vol. 89, No. 45

[5] Centers for Medicare & Medicaid Services. (2024). "Interoperability and Prior Authorization Final Rule (CMS-0057-F)." CMS.gov

[6] Healthcare Information and Management Systems Society. (2024). "AI in Healthcare Administration: 2024 Impact Report." HIMSS Analytics

[7] McKinsey Health Institute. (2024). "The automation opportunity in US healthcare administration." McKinsey & Company

[8] Healthcare IT News. (2024). "State of Healthcare Interoperability Report 2024." HIMSS Media

[9] Grand View Research. (2024). "Healthcare Artificial Intelligence Market Report 2024-2030." Industry Analysis

[10] College of Healthcare Information Management Executives. (2024). "AI Adoption in Health Systems: 2024 Survey Results." CHIME Research