Paper deep dive
LDP: An Identity-Aware Protocol for Multi-Agent LLM Systems
Sunil Prakash
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 97%
Last extracted: 3/13/2026, 12:55:57 AM
Summary
The paper introduces the LLM Delegate Protocol (LDP), an AI-native communication protocol designed for multi-agent systems. LDP addresses limitations in existing protocols like A2A and MCP by introducing first-class primitives for model identity, reasoning profiles, quality calibration, and cost characteristics. The protocol features five key mechanisms: rich identity cards, progressive payload modes, governed sessions, structured provenance, and trust domains. Empirical evaluation using the JamJet runtime and Ollama models demonstrates that LDP achieves significant efficiency gains, such as a 37% reduction in token count via semantic frames and 39% lower overhead in governed sessions, while providing architectural advantages in security and failure recovery.
Entities (5)
Relation Signals (3)
LDP → implementedaspluginfor → JamJet
confidence 100% · We implement LDP as a plugin for the JamJet agent runtime
LDP → introducesmechanism → Governed Sessions
confidence 100% · LDP introduces five key mechanisms: ... (3) governed sessions for multi-round delegation
LDP → improvesefficiencyover → A2A
confidence 90% · identity-aware routing achieves ~12x lower latency on easy tasks... semantic frame payloads reduce token count by 37%
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:As multi-agent AI systems grow in complexity, the protocols connecting them constrain their capabilities. Current protocols such as A2A and MCP do not expose model-level properties as first-class primitives, ignoring properties fundamental to effective delegation: model identity, reasoning profile, quality calibration, and cost characteristics. We present the LLM Delegate Protocol (LDP), an AI-native communication protocol introducing five mechanisms: (1) rich delegate identity cards with quality hints and reasoning profiles; (2) progressive payload modes with negotiation and fallback; (3) governed sessions with persistent context; (4) structured provenance tracking confidence and verification status; (5) trust domains enforcing security boundaries at the protocol level. We implement LDP as a plugin for the JamJet agent runtime and evaluate against A2A and random baselines using local Ollama models and LLM-as-judge evaluation. Identity-aware routing achieves ~12x lower latency on easy tasks through delegate specialization, though it does not improve aggregate quality in our small delegate pool; semantic frame payloads reduce token count by 37% (p=0.031) with no observed quality loss; governed sessions eliminate 39% token overhead at 10 rounds; and noisy provenance degrades synthesis quality below the no-provenance baseline, arguing that confidence metadata is harmful without verification. Simulated analyses show architectural advantages in attack detection (96% vs. 6%) and failure recovery (100% vs. 35% completion). This paper contributes a protocol design, reference implementation, and initial evidence that AI-native protocol primitives enable more efficient and governable delegation.
Tags
Links
- Source: https://arxiv.org/abs/2603.08852v1
- Canonical: https://arxiv.org/abs/2603.08852v1
Trouble viewing inline? Open PDF directly →
Full Text
51,513 characters extracted from source content.
Expand or collapse full text
LDP: An Identity-Aware Protocol for Multi-Agent LLM Systems Sunil Prakash 1 1 Indian School of Business, Hyderabad, India , sunil_prakash_pgpmax2026@isb.edu Abstract As multi-agent AI systems grow in complexity, the protocols that connect them increasingly constrain their capabilities. Current agent-to-agent protocols such as Google’s A2A and Anthropic’s MCP do not expose model-level properties as first-class protocol primitives—agents are identified by names, descriptions, and skill lists, but properties fundamental to effective delegation (model iden- tity, reasoning profile, quality calibration, cost characteristics) remain outside the protocol surface. We present the LLM Delegate Protocol (LDP), an AI-native communication protocol that makes these properties first-class. LDP introduces five key mechanisms: (1) rich delegate identity cards carrying model family, quality hints, and reasoning profiles; (2) progressive payload modes with automatic negotiation and fallback; (3) governed sessions for multi-round delegation with persistent context; (4) structured provenance tracking confidence and verification status; and (5) trust domains enforcing security boundaries at the protocol level. We implement LDP as a plugin adapter for the JAMJET agent runtime and conduct an initial empirical study against A2A and random baselines us- ing local Ollama models and LLM-as-judge evaluation. In our experiments, identity-aware routing achieves∼12× lower latency on easy tasks through better delegate specialization, though it does not improve aggregate quality over skill-matching in our small delegate pool; semantic frame payloads reduce token count by 37% (p=0.031, d=−0.7) with no observed quality loss; governed sessions eliminate 39% token overhead at 10 conversation rounds compared to stateless re-invocation; and— most notably—noisy provenance degrades synthesis quality below the no-provenance baseline, ar- guing that confidence metadata is harmful without verification. Simulated protocol analyses of trust domains and fallback chains show architectural advantages in attack detection (96% vs. 6%) and fail- ure recovery (100% vs. 35% completion), though these reflect protocol design properties rather than empirical attack scenarios. This paper contributes a protocol design, reference implementation, and initial evidence that AI-native protocol primitives enable more efficient and governable delegation. Keywords: agent protocols, multi-agent systems, LLM delegation, payload negotiation, AI interop- erability, trust domains 1 Introduction The rapid deployment of large language models (LLMs) in production systems has given rise to multi- agent architectures where specialized AI agents collaborate to solve complex tasks [Wu et al., 2023, Hong et al., 2023, Li et al., 2023]. These systems require communication protocols that enable agents to discover one another, negotiate interaction terms, delegate tasks, and synthesize results. Two dominant paradigms have emerged. Google’s Agent-to-Agent Protocol (A2A) [Google, 2025] provides a service-oriented interface where agents expose “Agent Cards” containing a name, description, and list of skills. Anthropic’s Model Context Protocol (MCP) [Anthropic, 2024] focuses on tool-level integration, allowing hosts to invoke functions on tool servers. Both protocols deliberately omit model- level metadata—a design choice favoring simplicity and generality. However, this opacity discards information critical to effective delegation. When a router must choose between a 3-billion-parameter model optimized for classification and an 8-billion-parameter 1 arXiv:2603.08852v1 [cs.AI] 9 Mar 2026 model with deep reasoning capabilities, knowing only their skill names (“classification”, “reasoning”) is insufficient. The router cannot assess quality–cost tradeoffs, negotiate communication formats, verify provenance of outputs, or maintain governed multi-round contexts. We argue that agent-to-agent protocols that are AI-native—that expose model identity, negotiate communication richness, enforce governance, and track provenance—can enable more efficient and governable delegation than protocols that do not expose these properties. To explore this thesis, we present the LLM Delegate Protocol (LDP), a protocol design with reference implementation and initial empirical study. LDP is designed from first principles around three observations: 1. AI delegates have rich, actionable identity. Model family, parameter count, reasoning profile, context window, and cost characteristics are all properties that inform delegation decisions. Exposing them in a structured identity card enables quality-aware routing. 2. Communication overhead is a first-order cost. Token consumption directly determines latency and monetary cost. Negotiating compact payload formats (structured semantic frames vs. verbose natural language) yields significant efficiency gains. 3. Governance requires protocol support. Multi-round sessions, provenance tracking, trust bound- aries, and policy enforcement cannot be reliably retrofitted onto stateless, opaque protocols. LDP is implemented as an external plugin for the JAMJET agent runtime [JamJet, 2024], registering alongside existing A2A and MCP adapters with zero modifications to the host system. We evaluate LDP against A2A and random-routing baselines across six research questions, using local Ollama [Ol- lama, 2024] models for delegates and Google Gemini [Google DeepMind, 2023] as an LLM judge. Our evaluation combines empirical experiments (routing, payload, provenance, sessions) with simulated protocol analyses (security, fallback). Contributions. • The LDP protocol specification: AI-native identity cards, progressive payload modes with negotiation and fallback, governed sessions, structured provenance, and trust domains (§3). • A reference implementation as a JAMJET protocol adapter (§4). • An initial empirical study with ablation analysis showing that identity metadata and structured pay- loads improve routing quality and communication efficiency (§6), plus simulated protocol analyses of security and fallback properties. 2 Background and Related Work 2.1 Agent Communication Protocols Agent communication has a long history in multi-agent systems. The Knowledge Query and Ma- nipulation Language (KQML) [Finin et al., 1994] and FIPA Agent Communication Language (FIPA- ACL) [FIPA, 2002] established foundations for performative-based messaging between software agents in the 1990s and 2000s. These protocols defined speech acts (inform, request, propose) but predated the era of large language models and did not address model-specific properties. Modern protocols for LLM-based agents include: Agent-to-Agent Protocol (A2A). Google’s A2A [Google, 2025] defines a service-oriented protocol for agent interoperability. Agents publish Agent Cards containing a name, description, version, URL, and list of skills. Communication is stateless: clients send tasks and receive results. A2A provides a clean, general interface but deliberately omits model-level metadata, quality signals, session support, provenance, and trust domain enforcement. 2 Not Supported PartialFull Support Model Identity Quality Hints Cost Profiles Reasoning Profile Payload Negotiation Governed Sessions Provenance Tracking Trust Domains Fallback Chain Multi-Party Rooms Protocol Feature Comparison LDP A2A MCP Figure 1: Feature comparison across agent communication protocols. LDP provides full support for all AI-native features, while A2A and MCP offer only partial transport-level security. Model Context Protocol (MCP). Anthropic’s MCP [Anthropic, 2024] provides a standardized inter- face for connecting AI assistants to external tools and data sources. MCP operates at the tool level— hosts invoke functions on servers—rather than the agent level. It is complementary to A2A and LDP but does not address agent-to-agent delegation. Agent Network Protocol (ANP). ANP [Agent Network Protocol, 2024] focuses on discovery and networking between agents, providing a directory layer but minimal communication semantics. LDP builds on the A2A pattern (service discovery, task submission, result retrieval) while extending it with AI-native awareness (§3). 2.2 Multi-Agent Frameworks Several frameworks orchestrate multi-agent collaboration. AutoGen [Wu et al., 2023] provides a conversation- based framework with flexible agent topologies. MetaGPT [Hong et al., 2023] assigns software engi- neering roles to LLM agents. CAMEL [Li et al., 2023] investigates role-playing for cooperative agent behavior. CrewAI [CrewAI, 2024] emphasizes role-based agent teams with task delegation. It is important to distinguish three layers in multi-agent systems: protocols (how agents communi- cate), frameworks (how agents are orchestrated), and routers (which agent to select). These frameworks define orchestration patterns but rely on ad-hoc communication (typically function calls or string pass- ing) for the protocol layer. LDP provides the communication layer that such frameworks lack—any of them could use LDP as their inter-agent protocol to gain identity-aware routing, payload negotiation, and governance. A natural question is whether A2A could be extended with custom metadata fields rather than adopting a new protocol; we address this directly in §7.4. 2.3 LLM Routing and Delegation Routing queries to appropriate models is an active research area. FrugalGPT [Chen et al., 2023] proposes cascading LLM calls to reduce cost while maintaining quality. RouterLLM [Ong et al., 2024] trains a lightweight router to direct queries to strong or weak models based on difficulty. These approaches 3 LDP Router qwen3:8b q=0.85, deep-analytical qwen2.5-coder:7b q=0.80, code-specialist llama3.2:3b q=0.55, fast-practical hard tasks code easy tasks Identity Cards Payload Negotiation Governed Sessions Provenance Tracking Trust Domains LDP Protocol Architecture Figure 2: Architecture of the LLM Delegate Protocol. The LDP router uses rich identity cards (model family, quality hints, reasoning profiles) to make intelligent routing decisions—sending easy tasks to lightweight models and hard tasks to capable models. Five protocol mechanisms work together: identity cards, payload negotiation, governed sessions, provenance tracking, and trust domains. optimize which model to call but do not address how to communicate with it once selected. LDP’s identity model provides the metadata that routers need (quality hints, cost profiles, capability manifests) as a protocol primitive rather than a separate system. 2.4 Structured Communication for LLM Agents Du et al. [Du et al., 2023] show that multi-agent debate improves factuality. Liang et al. [Liang et al., 2023] find that diverse agent roles improve reasoning quality. These works demonstrate that how agents communicate affects output quality—supporting LDP’s thesis that richer protocol semantics (structured payloads, identity context) yield better outcomes. 3 The LLM Delegate Protocol LDP is designed around a central premise: agent communication protocols should be aware that their participants are AI models with measurable, heterogeneous properties. We describe the key protocol mechanisms below. 3.1 AI-Native Identity Model A2A’s Agent Card exposes seven fields: name, description, version, URL, skills, authentication schemes, and supported protocols. LDP extends this with a Delegate Identity Card containing 20+ fields orga- nized into four categories: Core Identity. delegate_id, principal_id, model_family, model_name, model_version, runtime_version, weights_fingerprint, endpoint_address. Trust & Security. trust_domain, public_key, jurisdiction, data_handling_policy. 4 Capabilities. context_window, modalities_supported, languages_supported, tokenizer_fingerprint. Each capability entry carries quality_hint (0–1 continuous score), latency_hint_ms_p50, and cost_hint metadata. Behavioral. reasoning_profile (a qualitative descriptor such as “deep-analytical” or “fast-practical”) and cost_profile (“low”, “medium”, “high”). This rich identity enables metadata-aware routing: a router can send easy classification tasks to a fast, cheap 3B-parameter model and reserve hard reasoning tasks for a slower, more capable 8B model— decisions impossible with A2A’s skill-name-only matching. 3.2 Progressive Payload Modes Token count is a first-order cost in LLM systems. LDP defines six payload modes of increasing effi- ciency: • Mode 0 — Text. Natural language. Universal compatibility, easiest to audit, highest token count. • Mode 1 — Semantic Frames. Typed structured JSON with explicit fields (task_type, instruction, expected_output_format). Reduces verbosity while remaining human-readable. • Mode 2 — Embedding Hints. Vector representations attached as retrieval or routing signals. • Mode 3 — Semantic Graphs. Structured relationship representations for planning and formal rea- soning. • Mode 4 — Latent Capsules. Compressed machine-native semantic packets between compatible models. • Mode 5 — Cache Slices. Execution-state transfer between closely compatible model instances. Modes 2–3 are fully specified but not yet evaluated empirically. Modes 4–5 require model-level access not universally available through current APIs. We position Modes 2–5 as future work and focus evaluation on Modes 0–1, which are sufficient to demonstrate the payload efficiency thesis. Negotiation and Fallback. During session establishment, delegates negotiate the richest mutually supported mode. If a higher mode fails mid-exchange (e.g., schema validation error), the protocol auto- matically falls back: Mode N → Mode N−1 → · → Mode 0. Every delegate must support at least Mode 0 (text), ensuring communication never fails entirely. 3.3 Governed Sessions A2A is stateless: each task submission is independent. For multi-round delegation (iterative refinement, progressive analysis, verification chains), context must be re-transmitted with every request, incurring quadratic token overhead. LDP introduces governed sessions—negotiated, persistent contexts with explicit lifecycle: 1. HELLO: Caller announces identity. 2. CAPABILITY_MANIFEST: Callee responds with supported modes and constraints. 3. SESSION_PROPOSE: Caller proposes session parameters (payload mode, latency target, cost bud- get, privacy constraints, audit level). 4. SESSION_ACCEPT: Callee confirms, possibly with adjusted parameters. 5 5. TASK_SUBMIT / TASK_UPDATE / TASK_RESULT: Task exchange within the session context. Sessions maintain server-side context, eliminating the need to re-send conversation history. Budget tracking, privacy scoping, and quality-level negotiation persist across rounds. 3.4 Structured Provenance Every LDP task result carries structured provenance metadata: "produced_by": "delegate:qwen3-8b", "model_version": "qwen3-8b-2026.01", "payload_mode_used": "semantic_frame", "confidence": "score": 0.84, "method": "self-report", "verification": "performed": true, "status": "passed" This enables downstream consumers to weight outputs by source reliability—a synthesizer combin- ing opinions from three delegates can prioritize the one with higher confidence and verified status. A2A provides no provenance beyond task completion status. 3.5 Trust Domains LDP defines trust domains as security boundaries within which identity, policy, and transport guarantees are recognized. Security is enforced at multiple levels: 1. Message level: Per-message signatures, nonces, and replay protection. 2. Session level: Trust domain compatibility checks during session establishment. 3. Policy level: Policy engine validates each task against configurable rules (capability scope, jurisdic- tion compliance, cost limits). A2A relies solely on transport-level authentication (bearer tokens), which cannot distinguish trust domains, detect capability escalation, or enforce per-task policies. 3.6 Multi-Party Room Model Beyond point-to-point delegation, LDP specifies a room model with formal roles: Chair (coordination), Recorder (state management), Verifier (output checking), Arbitrator (conflict resolution), and Partici- pants (specialist delegates). This enables structured group collaboration patterns that A2A’s point-to- point topology cannot express. The room model is part of the protocol specification but is not evaluated in this paper; empirical validation of multi-party coordination is deferred to future work. 4 Implementation We implement LDP as an external plugin for the JAMJET agent runtime [JamJet, 2024], a production Rust-based system that orchestrates AI agent workflows. JAMJET provides a ProtocolAdapter trait with methods for discovery, invocation, streaming, status checking, and cancellation. Existing adapters implement MCP and A2A. 6 4.1 Plugin Architecture LDP registers at runtime via a single function call: let mut registry = default_protocol_registry(); register_ldp(&mut registry, config); URL-based dispatch routes ldp:// prefixed addresses to the LDP adapter. No modifications to JAM- JET’s core are required—LDP is a pure external dependency. 4.2 Identity Card Extension JAMJET’s AgentCard structure includes a labels: HashMap<String, String> field. LDP identity fields are stored as ldp. * labels (e.g., ldp.model_family, ldp.reasoning_profile, ldp.cost_profile), making them accessible to JAMJET’s existing routing and scheduling infras- tructure without schema changes. 4.3 Session Management Session lifecycle (negotiation, caching, teardown) is encapsulated within the adapter. From JAMJET’s perspective, each invoke() call is stateless. Internally, the adapter maintains a session cache keyed by (url, session_config), creating new sessions on demand and reusing existing ones for multi- round exchanges. 4.4 Model Adapters To support the experimental evaluation, we implemented two new model adapters for JAMJET’s ModelAdapter trait: an Ollama adapter for local inference (supporting Qwen, Llama, Gemma, and Phi model fami- lies) and a Google Gemini adapter for cloud-based judge evaluation. Both implement structured output support, OpenTelemetry tracing, and prefix-based model routing (e.g., qwen * → Ollama, gemini- * → Google). 5 Experimental Setup We evaluate LDP against baselines across six research questions. All experiments use local Ollama models for delegate inference (zero API cost) and Google Gemini 2.5 Flash as the LLM judge. 5.1 Research Questions RQ1 — Routing Quality. Does AI-native identity improve delegation routing quality compared to skill- matching and random selection? RQ2 — Payload Efficiency. Do semantic frame payloads reduce communication cost while preserving quality? RQ3 — Provenance Value. Does structured provenance improve downstream decision quality in multi- source synthesis? RQ4 — Session Efficiency. Do governed sessions reduce token overhead compared to stateless re- invocation in multi-round delegation? RQ5 — Security Boundaries (Simulated). Do trust domains detect unauthorized delegation attempts that bearer-token authentication misses? RQ6 — Fallback Reliability (Simulated). Does payload mode fallback improve task completion un- der communication failures? 7 5.2 Delegate Pool Three local Ollama delegates simulate a heterogeneous pool with varying quality, cost, and specializa- tion: • qwen3:8b — High quality (q=0.85), reasoning and analysis specialist, 5s median latency. • qwen2.5-coder:7b — Medium quality (q=0.80), code specialist, 4s median latency. • llama3.2:3b — Lower quality (q=0.55), fast classification and extraction, 1s median latency. All delegates run on a single Apple Silicon machine (36GB RAM) via Ollama, ensuring zero API cost and reproducible conditions. 5.3 Baselines All conditions use the same delegate pool, task set, and judge. The conditions differ in two dimensions: routing policy (how delegates are selected) and prompt conditioning (what context the delegate receives). We make this explicit because gains may arise from either or both; an ablation study (§6.7) separates these effects. LDP Baseline. Metadata-aware routing using identity-card fields (quality hints, reasoning profile, cost profile). System prompt includes delegate identity context. Represents the full LDP protocol. A2A Baseline. Skill-name matching only (no quality/cost metadata). Generic system prompt (“You are an AI assistant”). Represents standard A2A capability-based discovery. Random Baseline. Uniform random delegate selection with generic prompt. Provides a lower bound on routing quality. 5.4 LLM-as-Judge Evaluation Task outputs are evaluated by Gemini 2.5 Flash on three dimensions: quality (clarity and usefulness), correctness (factual accuracy), and completeness (coverage of the task). Each dimension is scored 1–10; the overall score is a weighted average: score overall = 0.3× quality + 0.4× correctness + 0.3× completeness(1) The judge receives the original task prompt, delegate output, and (optionally) a reference answer. We use the widely adopted LLM-as-judge methodology [Zheng et al., 2023]. 5.5 Task Generation For RQ1, 30 tasks are generated across three difficulty levels (easy, medium, hard; 10 each) spanning classification, reasoning, analysis, coding, and mathematical domains. For RQ2, 20 tasks per condition test three payload types: reasoning handoffs, context transfers, and verification tasks. For RQ3, 15 multi-source synthesis tasks require combining opinions from three delegates. For RQ4, 10 multi-round delegation scenarios are tested at 3, 5, and 10 rounds each under both session-based (LDP) and stateless (A2A) conditions (n=60 total). RQ5 simulates 100 security injection scenarios across four attack types. RQ6 simulates 40 communication failures across four failure types. 5.6 Statistical Methodology We report means with standard deviations and 95% confidence intervals. Statistical significance is as- sessed via the Mann-Whitney U test (non-parametric, appropriate for ordinal LLM-judge scores). Effect sizes are reported as Cohen’s d. We consider p < 0.05 statistically significant. 8 Table 1: Routing quality comparison across protocol conditions (RQ1). Quality scores are LLM-judge ratings (1–10). All delegates run locally via Ollama. ConditionQualityLatency (s)Tokensn LDP6.80± 3.6285.6137930 A2A7.43± 3.5467.4122730 RANDOM 6.95± 3.2142.282630 Table 2: Payload mode efficiency comparison (RQ2). Semantic frames reduce token count by 37% and latency by 42% compared to raw text, with no observed quality loss (p = 0.96). Token reduction is statistically significant (p = 0.031, d =−0.7). ModeTokensLatency (s)QualityInfo Preserved Text (Mode 0)1215± 75124.15.54± 4.055.85± 4.26 Semantic Frame (Mode 1)765± 51014.05.70± 2.935.50± 3.03 A2A JSON1128± 80423.45.47± 3.985.75± 3.89 6 Results 6.1 RQ1: Routing Quality Table 1 presents overall routing quality. A2A achieves the highest overall quality (7.43±3.49), followed by random (6.95± 3.22) and LDP (6.80± 3.60). No pairwise differences are statistically significant (p=0.56, Mann-Whitney U for LDP vs. A2A), which is unsurprising given the high variance inherent in LLM-judge scores, moderate sample size (n=30), and small delegate pool (n=3). The random base- line’s competitive performance reflects this small pool: random selection has a 1 3 chance of choosing the optimal delegate. LDP’s overall quality being slightly lower than A2A’s is an important honest result. It indicates that identity-aware routing does not automatically improve output quality in our setting. However, examining the results by task difficulty reveals a more nuanced picture. Figure 3 shows quality across difficulty levels. All three conditions perform comparably on easy tasks (∼9.1–9.6) and medium tasks (∼7.7–8.6). On hard tasks, all conditions struggle (3.3–4.1), with A2A slightly outperforming LDP (4.1 vs. 3.3). None of these per-difficulty differences are statistically significant at n=10 per cell. The quality result suggests that in our small-pool setting, LDP’s metadata-aware routing does not improve output quality over A2A’s simpler skill-matching. This is an honest negative finding that we attribute to two factors: (1) the delegate pool is too small (n=3) for routing sophistication to matter—all approaches select similar delegates; (2) the identity-enriched prompt may not provide sufficient benefit over a generic prompt for these tasks. Where LDP routing adds clear value: latency efficiency. The primary benefit of identity-aware routing in our experiments is specialization-based latency reduction, not quality improvement. Figure 4 shows the latency dimension. LDP’s easy-task latency is 2.9s vs. 34.8s for A2A (∼12× faster), because LDP routes easy tasks to the lightweight llama3.2:3b model while A2A’s skill- matching selects heavier models. This latency advantage is a direct consequence of metadata-aware routing and is independent of prompt conditioning—it arises purely from the protocol’s ability to match task difficulty to delegate cost profiles. 9 Easy MediumHard Task Difficulty 0 2 4 6 8 10 12 Quality Score (1-10) 9.4 7.7 3.3 9.6 8.6 4.1 9.1 8.0 3.7 Routing Quality by Task Difficulty (RQ1) LDP A2A Random Figure 3: Routing quality by task difficulty (RQ1). All conditions perform comparably; A2A slightly outperforms LDP overall, though no differences are statistically significant (n=10 per cell). Error bars show±1 standard deviation. 6.2 RQ2: Payload Efficiency Table 2 and Figure 5 show that semantic frames (Mode 1) reduce token count by 37% compared to raw text (765 vs. 1,215 tokens) and by 32% compared to A2A JSON (765 vs. 1,128). This reduction is statistically significant (p=0.031, Mann-Whitney U; d=−0.7, large effect). Latency follows token count: semantic frames are 42% faster (14.0s vs. 24.1s). Quality is compara- ble or slightly better (5.70 vs. 5.54 for text; p=0.96, n.s.), indicating that structured prompts help models focus without losing information. A2A’s JSON format provides minimal benefit over raw text (7% token reduction), as it lacks the structural compactness of typed semantic frames. The key difference is that semantic frames use typed fields (task_type, instruction, expected_output_format) that eliminate verbose natural- language phrasing, while A2A’s JSON merely wraps the same verbose text in a JSON envelope. 6.3 RQ3: Provenance Value Table 3 and Figure 6 present a nuanced finding. Accurate provenance and no provenance produce similar decision quality (7.65 vs. 7.85; p=0.47, n.s.)—the synthesizer performs comparably whether it knows delegate confidence levels or treats all sources equally. However, noisy provenance degrades quality significantly: 6.85± 2.66, with nearly double the variance of accurate provenance (±1.21). When one delegate’s confidence is artificially inflated (0.99) and marked as verified, the synthesizer over-weights its output, producing worse decisions than having no provenance at all. This finding argues for LDP’s structured verification fields: provenance is valuable only when trust- 10 Easy MediumHard Task Difficulty 0 20 40 60 80 100 120 140 Latency (seconds) 2.9s 128.2s 125.8s 34.8s 91.1s 76.3s 27.7s 39.0s 59.8s Routing Latency by Task Difficulty (RQ1) LDP A2A Random Figure 4: Routing latency by task difficulty (RQ1). LDP achieves∼12× lower latency on easy tasks by routing to the lightweight llama3.2:3b model, while A2A selects heavier models. worthy. Self-reported confidence without verification is worse than no confidence signal, because it in- troduces a false sense of calibration. LDP’s provenance model includes explicit verification.performed and verification.status fields precisely to address this risk. 6.4 RQ4: Session Efficiency Table 4 and Figure 7 compare LDP’s governed sessions against A2A’s stateless re-invocation across 3, 5, and 10 conversation rounds. At 3 rounds, the protocols are comparable (∼3,850 tokens each). At 5 rounds, A2A uses 7% more tokens (6,798 vs. 6,379), with 20% of its tokens being overhead from re-transmitted context. At 10 rounds, the gap widens: A2A uses 23% more tokens (16,010 vs. 12,990), with 39% of tokens being pure overhead. This scaling pattern confirms the protocol design prediction: stateless re-invocation incurs overhead that grows with conversation length, because each round must re-send all prior context. LDP’s ses- sions maintain server-side context, eliminating this re-transmission. The overhead difference is modest at short conversations but compounds at scale—in production systems with thousands of multi-round delegations, this translates directly to cost and latency savings. 6.5 RQ5: Security Boundary Enforcement (Simulated) The following two subsections present simulated protocol analyses—deterministic, rule-based evalua- tions of which protocol fields and checks exist in each protocol’s specification—rather than stochastic or empirical system evaluations. Detection and completion rates follow from the presence or absence of specific protocol primitives. We include them to illustrate architectural properties of LDP but caution that they should not be interpreted as production security or reliability benchmarks. 11 Text (Mode 0) Semantic Frame (Mode 1) A2A JSON 0 500 1000 1500 2000 Token Count 1215 765 1128 37% Token Efficiency Text (Mode 0) Semantic Frame (Mode 1) A2A JSON 0 2 4 6 8 10 Output Quality (1-10) 5.54 5.70 5.47 Quality Comparison Payload Mode Efficiency (RQ2) Figure 5: Payload mode efficiency (RQ2). Left: Semantic frames reduce token count by 37% vs. text (p=0.031). Right: Quality is comparable across all modes, indicating no observed information loss from structured payloads. Table 3: Provenance impact on synthesis quality (RQ3). Accurate provenance provides modest quality improvement, but noisy (misleading) provenance degrades quality and increases variance, arguing for LDP’s structured verification fields. ConditionDecision QualityCalibrationSynth. Tokens With Provenance7.65± 1.219.13± 0.83970 Without Provenance7.85± 1.849.33± 0.72802 Noisy Provenance6.85± 2.667.87± 2.901018 In our simulated analysis (Table 5), LDP’s trust domains detect 96% of unauthorized delegation attempts across four attack types (untrusted domain join, capability escalation, replay attack, cross- domain access) with 0% false positives. A2A’s bearer-token authentication detects only 6%—it catches only cases where tokens happen to be revoked but cannot detect capability escalation, replay attacks, or unauthorized cross-domain access, as these concepts are absent from its protocol model. These detection rates follow deterministically from the presence or absence of trust domain fields, capability manifests, session identifiers, and cross-domain policies in each protocol’s specification. 6.6 RQ6: Fallback Reliability (Simulated) In the same simulated framework, LDP’s fallback chain achieves 100% task completion across all four failure types (schema mismatch, codec incompatibility, version mismatch, timeout degradation) with minor quality degradation (0.16 on a 0–1 scale) and average recovery latency of 112ms. When a schema mismatch occurs, LDP falls back from semantic frames to text (50ms); when a codec fails, it falls back from embedding hints to semantic frames (80ms). Without fallback, A2A completes only 35% of tasks under the same failure conditions. Schema mismatches succeed accidentally 33% of the time; version mismatches succeed 50% of the time if versions happen to be compatible. Codec incompatibilities and timeout degradation are terminal failures. 12 Accurate Provenance No Provenance Noisy Provenance 0 2 4 6 8 10 Decision Quality (1-10) 7.65 7.85 6.85 Decision Quality Accurate Provenance No Provenance Noisy Provenance 0 2 4 6 8 10 12 Calibration Accuracy (1-10) 9.13 9.33 7.87 Source Calibration Provenance Impact on Synthesis Quality (RQ3) Figure 6: Provenance impact on synthesis quality (RQ3). Left: Noisy provenance degrades decision quality below the no-provenance baseline, while accurate provenance provides modest improvement. Right: Noisy provenance significantly reduces calibration accuracy. Error bars show±1 standard devi- ation. 6.7 Ablation: Routing vs. Prompt Conditioning A key methodological concern is whether LDP’s quality improvements arise from the protocol’s metadata- aware routing, from identity-enriched prompting, or from their combination. To isolate these effects, we run two additional ablation conditions on the same RQ1 task set: A2A + LDP prompt. Uses A2A’s skill-name routing (selecting the first matching delegate) but re- places the generic system prompt with LDP’s identity-enriched prompt containing reasoning profile and quality expectations. This isolates the prompt conditioning effect. LDP routing + generic prompt. Uses LDP’s metadata-aware routing (selecting delegates by quality hints, difficulty matching, and reasoning profile) but uses A2A’s generic “You are an AI assistant” prompt. This isolates the routing effect. Together with the existing LDP (both features) and A2A (neither feature), these four conditions form a 2× 2 factorial design crossing routing policy and prompt conditioning (n=30 per condition, 120 runs total). Table 7 presents the results. Quality. The routing main effect is−0.40 (p=0.43, Mann-Whitney U) and the prompting main effect is +0.01 (p=0.98). Neither routing policy nor prompt conditioning significantly affects overall quality in our setting. Where effects emerge: difficulty and latency. On hard tasks, identity-enriched prompts show a mod- est advantage: conditions with identity prompts score 4.81 vs. 3.80 for generic prompts (+1.01, p=0.44, n.s.). On easy tasks, LDP routing achieves 1.7–2.9s latency vs. 38.9–43.7s for A2A routing (∼15−20× faster), regardless of prompt type. This confirms that routing drives the latency benefit (it selects lightweight delegates for easy tasks) while prompting has a small, difficulty-dependent effect on quality that does not reach significance at this sample size. 13 3510 Conversation Rounds 0 2500 5000 7500 10000 12500 15000 Total Tokens 3,860 6,379 12,990 3,847 6,798 16,010 Token Count by Rounds LDP (sessions) A2A (stateless) 3510 Conversation Rounds 0 10 20 30 40 50 Overhead Tokens (%) 39% Context Re-transmission Overhead LDP overhead A2A overhead Figure 7: Session efficiency (RQ4). Left: Total token count by conversation length. A2A’s stateless re-invocation incurs growing overhead as context is re-transmitted each round. Right: Overhead tokens (context re-sent) as a percentage of total tokens. At 10 rounds, 39% of A2A’s tokens are pure overhead. Table 4: Session efficiency comparison (RQ4). LDP governed sessions eliminate context re-transmission overhead that grows with conversation length. At 10 rounds, A2A uses 23% more tokens, with 39% of its tokens being pure overhead. ConditionTokensOverheadOH%Messages LDP 3 rounds3,860602%4.2 A2A 3 rounds3,84739910%6.0 LDP 5 rounds6,37900%5.0 A2A 5 rounds6,7981,37420%10.0 LDP 10 rounds12,99000%10.0 A2A 10 rounds16,0106,27539%20.0 7 Discussion 7.1 When Does AI-Nativeness Matter? Our results suggest that LDP’s advantages are task-dependent and scale-dependent: Task difficulty. In our experiments, identity metadata does not improve quality over skill-matching— A2A slightly outperforms LDP on both hard tasks (4.1 vs. 3.3) and overall (7.43 vs. 6.80), though neither difference is statistically significant. The primary benefit of LDP’s routing is latency efficiency: routing easy tasks to lightweight models achieves ∼12× faster responses without meaningful quality loss. Note that this per-difficulty advantage may not be visible in the overall latency average, because medium and hard tasks—which dominate total wall-clock time—route to comparably heavy models under both protocols. Delegate pool size. With only 3 delegates, all routing strategies perform similarly. We expect LDP’s routing advantage to emerge more clearly with larger, more heterogeneous pools where the cost of misrouting increases and random selection probability decreases as 1 n . 14 Table 5: Security boundary enforcement (RQ5, simulated). LDP’s trust domains detect 96% of unau- thorized delegation attempts with 0% false positives. A2A’s bearer-token auth detects only 6%. ConditionDetection RateFalse Positive Rate LDP Trust Domains96.0%0.0% A2A Bearer Token6.0%0.0% Table 6: Fallback reliability under communication failures (RQ6). LDP’s mode fallback chain achieves 100% task completion with minor quality degradation (0.16). A2A has no fallback—failures are termi- nal. ConditionCompletion RateQuality DegradationRecovery (ms) LDP (with fallback)100%0.16± 0.10112 A2A (no fallback)35%0.67± 0.460 Communication volume. Payload mode savings (37% fewer tokens) compound across large-scale systems processing millions of delegations. At scale, this translates directly to cost reduction. 7.2 The Provenance Paradox Perhaps our most surprising finding is that accurate provenance does not significantly improve synthesis quality (p=0.47), while noisy provenance actively harms it. This creates a paradox: provenance is only valuable if verified, but verification adds complexity and cost. We interpret this as evidence that LDP’s design choice to include structured verification fields along- side confidence scores is correct. A protocol that exposes confidence without verification (e.g., by ex- tending A2A with a custom confidence header) may be worse than no confidence at all, because consumers cannot distinguish calibrated from uncalibrated self-reports. 7.3 Complexity vs. Value LDP is more complex than A2A. A legitimate question is whether the benefits justify the additional protocol machinery. Our analysis suggests a pragmatic adoption strategy aligned with LDP’s interoper- ability profiles: • Profile A (Basic): Identity cards + text payloads + signed messages. Captures the routing benefit (RQ1: 12× latency reduction) with minimal protocol overhead. • Profile B (Enterprise): Add provenance tracking and policy enforcement. Addresses the provenance verification gap (RQ3) and security boundaries (RQ5). • Profile C (High-Performance): Payload mode negotiation and session management. Captures the 37% token reduction (RQ2), compounding at scale. These profiles are grounded in our experimental findings: each level adds protocol features whose ben- efits we have measured or analyzed. Organizations can adopt LDP incrementally, starting with Profile A and progressing as needs grow. 7.4 Could A2A Be Extended Instead? An important alternative hypothesis is that A2A could be extended with custom metadata (quality hints, provenance fields, trust domains) rather than adopting a new protocol. While technically possible, this approach has limitations: 15 LDP Trust Domains A2A Bearer Token 0 20 40 60 80 100 Detection Rate (%) 96% 6% Attack Detection (RQ5) LDP (fallback) A2A (no fallback) 0 20 40 60 80 100 Completion Rate (%) 100% 35% Task Completion (RQ6) LDP (fallback) A2A (no fallback) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Quality Degradation (0-1) 0.16 0.67 Quality Loss (RQ6) Security and Fallback Evaluation (RQ5, RQ6) Figure 8: Security and fallback evaluation (RQ5, RQ6). Left: Trust domain attack detection rate. Center: Task completion rate under communication failures. Right: Quality degradation during fallback recovery. Results are simulated based on protocol design properties. Table 7: Ablation: 2 × 2 factorial crossing routing policy and prompt conditioning. Quality scores are LLM-judge ratings (1–10), n=30 per cell. Neither main effect is statistically significant for overall quality. A2A RoutingLDP Routing Generic Prompt7.25± 3.526.96± 3.55 Identity Prompt7.37± 3.266.86± 3.87 1. No negotiation. Extensions are unilateral—there is no mechanism for delegates to negotiate sup- ported modes or verify capability claims. 2. No fallback. Ad-hoc extensions lack formal fallback semantics; failures in custom fields are unre- coverable. 3. No governance. Extensions cannot add session lifecycle management or policy enforcement without fundamental changes to A2A’s stateless model. 7.5 Limitations Baseline fairness. The LDP and A2A conditions differ in both routing policy and prompt condition- ing. While our ablation study (§6.7) begins to disentangle these effects, a fully factorial design across all protocol features would provide stronger causal evidence. Sample size and delegate pool. With 30 tasks per condition for RQ1 and 15 for RQ3, many quality differences are not statistically significant despite showing consistent directional effects. The delegate pool (n=3) is small, making random routing artificially competitive. Larger-scale experiments with more diverse delegate pools would strengthen findings. Local models only. All delegates are local Ollama models (3B–8B parameters). Results may dif- fer with production-scale models (70B+) or cloud-hosted APIs where latency and cost profiles differ substantially. 16 020406080100 Score / Percentage Easy Task Latency (×) Token Reduction (%) Session Overhead Saved (%) Overall Quality Attack Detection (%) Completion Rate (%) 12.0 37 39 6.8 96 100 1.0 7 0 7.4 6 35 LDP vs A2A: Summary Comparison LDP A2A Figure 9: Summary comparison of LDP vs. A2A across key metrics. LDP shows advantages in latency efficiency, token reduction, and simulated security/fallback properties. Quality differences are not sta- tistically significant. Simulated experiments. RQ5 and RQ6 use simulated scenarios that reflect protocol design proper- ties rather than real attack/failure conditions. Empirical validation with actual system failures would strengthen these claims. LLM-as-judge. Our evaluation relies on a single judge model (Gemini 2.5 Flash). While LLM-as- judge evaluation is increasingly accepted [Zheng et al., 2023], it introduces model-specific biases. Hu- man evaluation or a second judge model would improve validity. Payload modes. We evaluate only Modes 0–1 (text, semantic frames). Higher modes (embedding hints, latent capsules) remain future work pending wider API support for intermediate representations. Identity field assignment. In our experiments, identity-card fields (quality hints, reasoning profiles) are assigned by the system designer based on known model properties. In production deployments, the question of whether these fields are self-declared, measured, or externally certified is an important trust consideration that we do not resolve here. 8 Conclusion We presented the LLM Delegate Protocol (LDP), an AI-native communication protocol that exposes model identity, negotiates payload formats, maintains governed sessions, tracks provenance, and en- forces trust boundaries. Our initial empirical study provides mixed but informative evidence. Identity- aware routing does not improve aggregate quality over simpler skill-matching in our small delegate pool, but achieves∼12× latency savings on easy tasks through specialization-aware delegate selection—a di- rect consequence of metadata-aware routing. Semantic frame payloads significantly reduce token count by 37% without observed quality loss (p=0.96 for quality difference). Governed sessions eliminate 39% of token overhead at 10 conversation rounds, with overhead growing as conversation length increases. Simulated protocol analyses suggest architectural advantages in security and failure recovery. Perhaps most notably, our provenance experiments reveal that metadata can be harmful without verification: noisy confidence signals degrade synthesis quality below the no-provenance baseline. This 17 Table 8: Summary of LDP vs. A2A across all research questions. ↑ indicates higher is better,↓ lower is better. Bold indicates the better result. ∗ Statistically significant (p < 0.05). † Simulated (protocol design property). ‡ Not statistically significant. RQMetricLDPA2A∆Evidence RQ1Overall quality ‡ ↑6.807.43 −0.63Empirical Easy task latency↓2.9s34.8s12×Empirical Hard task quality ‡ ↑3.34.1 −0.8Empirical RQ2Token count ∗ ↓7651128 −32%Empirical Latency↓14.0s23.4s −40%Empirical Quality ‡ ↑5.705.47+0.23Empirical RQ3Decision quality ‡ ↑7.657.85 −0.20Empirical Noisy provenance risk↓N/AN/A −1.0 qualityEmpirical RQ4Token overhead (10 rounds)↓0%39% −39ppEmpirical Total tokens (10 rounds)↓12,99016,010 −23%Empirical RQ5Attack detection † ↑96%6%+90ppSimulated RQ6Completion rate † ↑100%35%+65ppSimulated Quality degradation † ↓0.160.67 −0.51Simulated finding has implications beyond LDP—any protocol that exposes confidence or quality metadata should include verification mechanisms. This paper contributes a protocol design, reference implementation, and initial evidence. Important questions remain: whether these benefits hold at production scale with larger delegate pools and more diverse models, and whether identity fields should be self-declared or externally certified. We view LDP as a step toward treating AI agents as what they are—heterogeneous models with measurable properties—rather than as opaque services. LDP is implemented as an open-source plugin for the JAMJET agent runtime. The protocol specifi- cation and reference implementation are available at https://github.com/sunilp/ldp-protocol; experiment code and data are at https://github.com/sunilp/ldp-research. References Anthropic. Model Context Protocol. https://modelcontextprotocol.io/, 2024. AgentNetworkProtocol.ANPSpecification. https://github.com/ agent-network-protocol/AgentNetworkProtocol, 2024. L. Chen, M. Zaharia, and J. Zou. FrugalGPT: How to use large language models while reducing cost and improving performance. arXiv preprint arXiv:2305.05176, 2023. CrewAI. https://w.crewai.com/, 2024. Y. Du, S. Li, A. Torralba, J. B. Tenenbaum, and I. Mordatch. Improving factuality and reasoning in language models through multiagent debate. arXiv preprint arXiv:2305.14325, 2023. T. Finin, R. Fritzson, D. McKay, and R. McEntire. KQML as an agent communication language. In Proc. CIKM, 1994. FIPA. Agent Communication Language Specifications. http://w.fipa.org/repository/ aclspecs.html, 2002. 18 Google. Agent2Agent Protocol (A2A). https://github.com/a2aproject/A2A, 2025. Google DeepMind.Gemini: A family of highly capable multimodal models.arXiv preprint arXiv:2312.11805, 2023. S. Hong, X. Zhuge, J. Chen, et al. MetaGPT: Meta programming for a multi-agent collaborative frame- work. arXiv preprint arXiv:2308.00352, 2023. JamJet. Agent Runtime. https://github.com/jamjet-labs/jamjet, 2024. G. Li, H. Hammoud, H. Itani, D. Khizbullin, and B. Ghanem. CAMEL: Communicative agents for “mind” exploration of large language model society. arXiv preprint arXiv:2303.17760, 2023. T. Liang, Z. He, W. Jiao, et al. Encouraging divergent thinking in large language models through multi- agent debate. arXiv preprint arXiv:2305.19118, 2023. Ollama. https://ollama.com/, 2024. I. Ong, A. Almahairi, V. Wu, et al. RouteLLM: Learning to route LLMs with preference data. arXiv preprint arXiv:2406.18665, 2024. Q. Wu, G. Bansal, X. Zhang, et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. arXiv preprint arXiv:2308.08155, 2023. L. Zheng, W.-L. Chiang, Y. Sheng, et al. Judging LLM-as-a-judge with MT-Bench and Chatbot Arena. arXiv preprint arXiv:2306.05685, 2023. A Payload Mode Examples The following examples show the same delegation task (“Classify the sentiment of this review”) encoded in each payload format evaluated in RQ2. Mode 0 — Text (Raw Natural Language). Please classify the sentiment of the following customer review as positive, negative, or neutral. The review is: "The product arrived on time and works exactly as described. Very satisfied with the purchase." Please provide your classification along with a brief justification for your choice. Mode 1 — Semantic Frame (LDP). "task_type": "classification", "instruction": "Classify sentiment", "input": "The product arrived on time and works exactly as described. Very satisfied.", "expected_output_format": "label+justification", "labels": ["positive", "negative", "neutral"] 19 A2A JSON Envelope. "task": "message": "role": "user", "parts": [ "text": "Please classify the sentiment of the following customer review as positive, negative, or neutral. The review is: ’The product arrived on time and works exactly as described. Very satisfied with the purchase.’ Please provide your classification along with a brief justification for your choice." ] The semantic frame is 43% shorter than text and 38% shorter than A2A JSON because it uses typed fields to eliminate verbose phrasing while preserving all task-relevant information. B Identity Card Schema "delegate_id": "qwen3-8b-reasoning", "principal_id": "org:research-lab", "model_family": "qwen", "model_name": "qwen3", "model_version": "8b-2026.01", "runtime_version": "ollama-0.6.1", "trust_domain": "research.internal", "capabilities": [ "name": "reasoning", "quality_hint": 0.85, "latency_hint_ms_p50": 5000, "cost_hint": "medium" , "name": "analysis", "quality_hint": 0.82, "latency_hint_ms_p50": 4500, "cost_hint": "medium" ], "reasoning_profile": "deep-analytical", "cost_profile": "medium", "context_window": 32768, "modalities_supported": ["text"], "languages_supported": ["en", "zh"] Identity-card fields are currently assigned by the system designer based on known model properties. In production deployments, these could be self-declared, measured via benchmarks, or externally certified by third-party evaluation services. 20 C Threat Model for Trust Domain Evaluation Table 9 describes the four attack types simulated in RQ5. Table 9: Threat model for trust domain evaluation (RQ5). Each attack type is tested against LDP trust domains and A2A bearer-token authentication. Attack TypeDescriptionDetection Mechanism Untrusteddo- main join Agent from outside the trust domain attempts to register as a delegate Trust domain member- ship check Capability esca- lation Agent claims capabilities be- yond its registered manifest Capabilitymanifest validation Replay attackPreviously captured task/re- sultmessagesarere- submitted Sessionnonceand timestamp verification Cross-domain access Agent in domain A attempts to invoke a delegate restricted to domain B Cross-domain policy enforcement LDP detects all four attack types through protocol-level fields (trust domain membership, capability manifests, session nonces, cross-domain policies). A2A’s bearer-token authentication detects only revoked-token scenarios, as it lacks the protocol primitives for the other three checks. D Representative RQ1 Task Prompts Table 10 shows representative tasks from the RQ1 evaluation across difficulty levels and domains. The full set of 30 tasks spans classification, reasoning, analysis, coding, and mathematical domains. Table 10: Representative RQ1 tasks by difficulty and domain. Each difficulty level contains 10 tasks balanced across domains. Difficulty DomainPrompt (abbreviated) EasyClassifyClassify the sentiment of this product review as pos- itive, negative, or neutral. EasyExtractExtract all dates and monetary amounts from this contract paragraph. Medium CodeWrite a Python function that implements binary search on a sorted list with duplicate handling. Medium AnalysisCompare the tradeoffs between microservices and monolithic architectures for a 5-person team. HardReasoning Given the following set of constraints, determine whether a valid schedule exists and prove or dis- prove its feasibility. HardMathProve that the sum of the first n odd numbers equals n 2 using mathematical induction. 21