Source-linked AI summary
Agent Transfer Protocol: Server-Mediated Agent-to-Agent Communication Architecture for the Agentic Web
Yuqi Qiu, Zuyao Xu, Lu Sun, Xiang Li, Fasheng Miao, Fubin Wu, Haixin Duan, Zheli Liu
TL;DR
Long-lived cross-organization agent interactions need stable addressing, reception, and source verification despite changing tasks, connections, and execution instances. ATP organizes these responsibilities through administrative domains; all 10 offline and instance-replacement runs completed processing, with about 2.7 milliseconds of median latency overhead over direct HTTPS.
Problem
Cross-organization agent interactions span changing tasks, connections, and execution instances, raising the question of how stable addressing, offline reception, and delayed source verification can be organized.
Source: §1 · p. 1Method
ATP has administrative domains maintain logical-agent addresses, receive and save messages, and sign complete envelopes for later domain-source and content-integrity verification.
Source: §1 · p. 2, §3.1 · p. 3, §3.4 · p. 4Results
All 10 offline and instance-replacement runs completed processing, and ATP added about 2.7 milliseconds of median latency compared with direct HTTPS.
Source: §1 · p. 2Takeaways & Limitations
ATP provides an implementable communication architecture for interactions crossing task and instance changes, with domain servers receiving messages while target instances are offline.
Source: §7 · p. 8Domain operators are trusted and can access inboxes; applications may add end-to-end signatures and encryption when they need protection against domain operators.
Source: §3.4 · p. 4
Abstract
from arXiv · showhide
The Agentic Web needs to support continuous collaboration among agents from different organizations. These collaborative relationships may span multiple tasks, network connections and execution instances. Such interactions require stable communication entries, message reception when instances are offline, and source verification after delayed reading. How to organize these responsibilities so that cross domain communication does not depend on specific execution instances being continuously online is a key issue for building long term agent interaction infrastructure. We propose ATP (Agent Transfer Protocol), a cross organization agent communication protocol adopting a domain mediated architecture. In this architecture, administrative domains maintain stable addresses and receiving entries for logical agents. The domain servers of both parties continuously undertake cross domain transmission. The receiving domain verifies and saves messages for execution instances to read later. The sending domain signs the complete message envelope. This allows the receiving instance to independently reverify the domain source and content integrity after the original connection ends, provided the original verification public key is still trusted and obtainable. We implemented an ATP prototype and evaluated it through a controlled cross organization LLM agent workflow, mechanism checks and latency measurements. The workflow completed subsequent business processing after instances went offline or were replaced. The independent verifier successfully verified the domain source and content integrity of saved messages. Latency measurements further quantified the communication and processing overhead introduced by the continuous mediation of domain servers.
1 Introduction
ATP addresses cross-organization communication that must persist across task, connection, and execution-instance changes. It assigns stable addressing, message reception, and domain-level source verification to administrative domains, and evaluates continuity and latency in a controlled workflow.
1 Introduction
- Cross-organization communication needs stable relationships despite changing tasks, connections, and execution instances, while domains independently manage local identities and policies.The infrastructure must also clarify reception and provenance verification after messages are stored or delayed.Source: §1 · pp. 1–2
- ATP uses administrative domains to maintain logical-agent addresses, receive and save messages, and sign envelopes for later domain-source and content-integrity verification.After verification and saving, the receiving domain confirms reception and assumes custody; instances can retrieve messages later.Source: §1 · p. 2
- The paper defines continuous cross-organization communication responsibilities and implements domain-mediated transmission and reception hosting in an ATP prototype.The prototype supports complete-envelope signatures bound to the sending domain for verification after message saving.Source: §1 · p. 2
- All 10 offline and instance-replacement runs completed processing, while ATP added about 2.7 milliseconds of median latency over direct HTTPS.The latency comparison was measured with a single machine, keep-alive connections, and a memory file system.Source: §1 · p. 2
2 Background and Problem Definition
The paper frames cross-domain agent communication around persistent logical roles whose execution instances, tasks, and network connections can change. It specifies addressing, reception, verification, and interoperability requirements, then asks how common rules can organize them and what constraints and costs result.
2.1 Problem Setup
- A logical agent is a persistent cross-organization role that may be hosted by changing execution instances, while tasks and network connections span the relationship.Instances may be offline, migrate, or operate behind firewalls or NAT, and network paths and access points can change.Source: §2.1 · p. 2
2.2 Communication Requirements
- Requirements span persistent logical-agent addressing and discovery, reception during offline or failed delivery, delayed source and integrity verification, and shared rules across independently managed domains.Reception confirmation, retry responsibility, and message expiry must be distinguished from business-processing outcomes.Source: §2.2 · pp. 2–3
2.3 Research Questions
- The paper asks how common rules can organize stable addressing, continuous reception, and source verification across changing tasks, connections, and instances, and what constraints and costs follow.Source: §2.3 · p. 3
3 ATP Design
ATP separates stable logical-agent identity from changing execution locations and assigns cross-domain transmission, reception hosting, and source endorsement to domain servers. It uses domain addresses and DNS discovery, saves messages for later retrieval, and signs messages for verification after storage.
3.1 Architecture Overview
- ATP assigns domain servers responsibility for cross-domain transmission and reception hosting, while execution instances handle business processing and upper-layer protocols organize tasks and dialogues.The parties follow common discovery, acknowledgment, and verification rules while managing local naming and policies independently.Source: §3.1 · p. 3
3.2 Stable Addressing
- Logical agents use local@domain addresses that persist across tasks and instances; DNS locates the receiving domain, which maps the full address to a local inbox.Instances connect outbound to local services and need not expose public inbound endpoints.Source: §3.2 · pp. 3–4, Figure 1 · p. 4
3.3 Message Hosting
- The receiving domain verifies and saves messages before confirming custody, while the sending domain retains and retries messages until transfer; offline instances can retrieve saved messages later.Continuous mediation adds transmission and server-processing overhead and makes communication depend on domain-service availability.Source: §3.3 · p. 4
3.4 Domain Level Signatures
- ATP signs the complete message object and binds the verification key’s domain to the sender address, enabling later provenance and integrity checks when the original key remains trusted and available.Domain operators are trusted and can access inboxes; applications may add end-to-end signatures and encryption for protection against them.Source: §3.4 · p. 4
3.5 Implementation
- The Go prototype uses HTTPS interfaces protected by TLS, JCS canonicalization, Ed25519 signatures, and SQLite inbox and delivery-queue storage.The implementation totals 5,237 lines of code.Source: §3.5 · p. 4
4 Combination Scheme Comparison
Section 4 compares ATP with an A2A-based combination scheme across addressing and reception, custody transfer, and source verification. Both approaches can support communication across instance changes, but their configurations and verification choices differ.
4 Combination Scheme Comparison
- The comparison evaluates a complete A2A combination against ATP and examines the design choices and conditions for meeting Section 2’s requirements.The A2A combination includes an organization-resident service, both parties’ gateways, a persistent queue, OAuth, and HTTP Message Signatures.Source: §4 · p. 4, §4.1 · p. 5
4.1 A2A Combination Scheme
- The A2A combination uses Agent Card discovery, OAuth-authorized submission to the local gateway, gateway delivery, and receiving-side verification and saving before backend processing.Agent Cards may be discovered through a well-known URI, directory, or direct configuration; client metadata may use CIMD version 02.Source: §4.1 · p. 5
4.2 Design Comparison
- Both approaches use resident services and stable receiving entries for offline instances, while ATP uses local@domain addresses and DNS to locate the receiving domain and inbox.The prototype supports instance replacement while retaining addresses, credentials, and cursors; the combination scheme depends on its selected service and configuration.Source: §4.2 · p. 5
- ATP transfers custody after verification and saving; the A2A combination can do likewise, but webhook confirmation alone does not uniformly require persistent saving.Both must handle repeated submissions after lost confirmation; queue retention, delivery deadlines, and inbox retention constrain retrying and reading.Source: §4.2 · p. 5
- ATP signs the complete envelope, discovers the key through DNS, and requires its domain to match the sending domain; both schemes need complete verification materials and trusted, available keys for reverification.The A2A combination can sign a content digest and reconstruct signature input from saved signature, content, and HTTP information.Source: §4.2 · p. 5
5 Evaluation
The evaluation tests ATP in a cross-organization travel workflow, mechanism checks, security tests, and latency measurements. The workflow and checks succeed under the tested conditions, while latency results quantify mediation overhead and show delivery limits during outages.
5.1 Experimental Environment
- The experiments used independent ATP server containers on one shared Ubuntu server; the latency test used a memory-file-system SQLite database, excluding per-record disk flushing.The reported overhead therefore applies to the stated single-machine, keep-alive, memory-file-system conditions; wider-area network delay and storage configuration also affect latency.Source: §5.1 · p. 5, §5.4 · p. 7
5.2 Cross Organization Agent Case Study
- All 10 offline and migration runs completed rescheduling and hotel booking, passing all checks while leaving existing-domain configuration unchanged when the hotel joined.The runs covered five external status checks per variant; the timeline figure shows notification, instance return, and subsequent processing.Source: §5.2 · p. 5, Figure 2 · p. 6
5.3 Mechanism Verification
- All mechanism checks passed, supporting message acceptance independent of instance online status, continuation after replacement, and independent source and content verification after saving.Reverification used the original public key, which remained obtainable; keys were not rotated during operation.Source: §5.3 · p. 6, Table 2 · p. 6
5.4 Runtime Overhead
- 2.7 milliseconds: interdomain ATP added about this much median latency versus direct HTTPS, and about 1.5 milliseconds versus intradomain ATP.Interdomain median latency was 3.48 and 3.45 milliseconds at the two tested loads; p99 was 4.72 and 4.47 milliseconds. Figure 4 identifies interdomain delivery as the longest cross-domain segment and breaks down receiving-domain processing.Source: §5.4 · pp. 6–7, Figure 3 · p. 6, Figure 4 · p. 7
5.5 Security Testing
- All tested security cases were rejected by the expected mechanisms, and none of their messages entered the inbox.The eight malicious-input types were tested three times each, with each case violating only the rule under test.Source: Table 3 · p. 7, §5.5 · p. 7
5.6 Delivery When Receiving Domain is Unreachable
- All messages in the 30- and 240-second outage groups were delivered, while the 270-second groups had 3 to 4 expired messages per run.The 240-second group’s median wait after recovery was 36 seconds, with a 125-second maximum; messages already saved in the inbox could still be retrieved after instances had been offline for 360 or 600 seconds.Source: §5.6 · p. 7
6 Related Work
Related work places ATP within shared agent infrastructure and compares where existing protocols assign communication, identity, recovery, and message-hosting responsibilities. ATP focuses on message delivery between independent administrative domains, separating domain custody from agent business processing.
Agentic web and shared infrastructure
- Agentic Web research describes autonomous collaboration and shared infrastructure, while this paper applies that infrastructure perspective to cross-domain addressing, message hosting, and domain-level source endorsement [28] [43] [44].The cited infrastructure framing treats technical systems and shared protocols as independent of agents; protocol interoperability has also been compared across communication objects, payloads, states, and discovery.Source: §6 · p. 7
Agent communication protocols and access architectures
- A2A covers client-server message, task, and context interactions, MCP organizes tool, resource, and prompt interfaces, and LDP adds model identity, payload negotiation, and managed sessions [31].A2A supports polling, streaming updates, and task pushing, and requires servers to authenticate requests.Source: §6 · pp. 7–8
Identity, discovery and access services
Long term interaction, recovery and message hosting
- Prior work addresses continuity and offline message hosting through sessions, relays, or platform mailboxes; ATP instead assigns interdomain message custody to receiving domains and leaves dialog and business-state recovery to upper layers.ATP specifies reception confirmation, sender retries, and message verification rules [p21].Source: §6 · p. 8
Internet communication precedents
- Email, SIP, Mobile IP, XMPP, Matrix, and ActivityPub provide precedents for interdomain hosting, stable identifiers, routing, or signed server-to-server delivery.ATP adapts these mechanisms for cross-organization logical-agent messages, adding DNS entry discovery, confirmation after saving, and sending-domain binding.Source: §6 · p. 8
7 Conclusion
ATP uses domain names as administrative boundaries for cross-organization agent communication, with domain servers providing stable addresses, continuous reception, and source endorsement. The protocol is intended to support interactions across task and instance changes.
7 Conclusion
- ATP uses domain names as administrative boundaries to provide source endorsement and continuous reception for cross-organization agent communication, including when target instances are offline.Its servers maintain stable addresses and save messages for later retrieval, supporting interactions across task and instance changes.Source: §7 · p. 8
A Protocol Details
The protocol details specify how ATP discovers receiving servers, verifies and transfers messages, and manages delivery, requests, and subscriptions. They also define sender policies, replay protection, and message expiry behavior.
Addressing and delivery
- ATP discovers the receiving server by querying the recipient domain’s SVCB record at _atp.<domain>, which supplies the host name and port.The default port is 7443; the sender connects using TLS and verifies the hostname against the SVCB record.Source: A Protocol Details · pp. 9–10
Envelope and signatures
- The sending domain canonicalizes and signs the complete envelope, covering all fields except the signature, including unknown fields.The receiving domain verifies and saves the message before accepting it into the recipient’s inbox.Source: A Protocol Details · p. 10
Responses
- A receiving server’s 202 response means the message was written to the recipient’s inbox, while temporary failures trigger retries and specified permanent errors end delivery.The response table describes receiver responses and corresponding sender handling.Source: A Protocol Details · p. 10, Table 4 · p. 10
Sender address policy
- ATS optionally filters senders by TCP peer address before signature verification, but a neutral ATS result does not replace the required signature check.Later matching policy directives override earlier ones; shared cloud addresses limit ATS to a supporting role.Source: A Protocol Details · p. 10
Replay protection
- Receivers reject timestamps outside the freshness interval and duplicate sender-nonce pairs, returning a temporary error if the replay store is full.The accepted interval is from 300 seconds before now to 60 seconds after now.Source: A Protocol Details · p. 10
Retry and expiry
- The sender retries temporary failures with exponential backoff while the message remains fresh, then marks it expired when another retry would exceed the delivery window.Expired or permanently failed messages are bounced only when ack_required is set; otherwise they are dropped and counted.Source: A Protocol Details · pp. 10–11
Request/response
- Request deadlines derive from the request timestamp and payload timeout, or from the freshness-window end when no timeout is given; long polling returns matching replies from the original recipient.Requests arriving past their deadline receive 504, and queued requests past deadline are marked expired.Source: A Protocol Details · p. 11
Event subscription
- Subscriptions carry an identifier and lifetime; publishers validate them at submission and before delivery, while periodic heartbeats are recorded without entering the agent inbox.The default subscription lifetime is 3600 seconds and the default heartbeat interval is 60 seconds.Source: A Protocol Details · p. 11
B Security Tests
The security tests evaluate whether crafted messages are rejected by the intended checks and whether rejected requests leave the inbox unchanged. All eight tested cases were rejected in each of three runs, though the tests do not establish general protocol security.
B Security Tests
- All eight adversarial cases were rejected by the intended check in each of three runs, but these tests do not prove ATP secure in general.The receiver’s inbox was checked after each rejected request; captured legitimate messages were checked for unchanged retention.Source: B Security Tests · p. 11
- The domain-mismatch test used a valid signing key belonging to another domain; without the alignment check, the message would have been accepted.The test domain published a signing key but no optional ATS record, so signature checks had to stop the forged-signature and domain-mismatch cases.Source: B Security Tests · p. 11
C Delivery Bound When the Receiving Domain Is Unreachable
The retry rule bounds delivery during receiving-domain outages, and an implementation test found delivery outcomes near that bound while recovery still left messages waiting for scheduled retries. The bound applies only to server-to-server forwarding; messages already received can be fetched later.
C Delivery Bound When the Receiving Domain Is Unreachable
- With immediate connection refusals, retries at about 0, 1, 3, 7, 15, 31, 63, 127, and 255 s put the last valid attempt near a 290 s forwarding window.A next attempt at about 511 s falls beyond the window; timeout-based failures shift attempts later, so this calculation does not apply.Source: C Delivery Bound When the Receiving… · p. 11
- Across three runs per outage duration, all 10 messages were delivered at 30 s and all 52 at 240 s; at 270 s, 54–55 messages were delivered and 3–4 expired.No run had duplicates, permanent failures, or pending messages.Source: C Delivery Bound When the Receiving… · pp. 11–12
- After recovery, messages wait for their next scheduled retry rather than being sent immediately; in the 240 s group, median wait was 36 s and maximum wait was 125 s.Source: C Delivery Bound When the Receiving… · p. 12
- The bound limits forwarding between servers only; after receipt into the inbox, the server does not check message timestamps when agents fetch messages.The case study and mechanism checks fetched messages after about 360 s and 600 s offline.Source: C Delivery Bound When the Receiving… · p. 12