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.
Figures & tables
Figure 1. ATP cross-domain message path. The sending domain authenticates the local sender, signs the envelope, and discovers the receiving domain through DNS. The receiving domain verifies and stores the message for later retrieval by the destination agent. The sending agent submits a message to its domain server, which discovers and authenticates the receiving domain and delivers the message to the recipient inbox for later retrieval.
Variant
Offline
Migration
Success
5/5
5/5
Total Time (s)
407.6
406.7
Offline (s)
360.7
361.1
Model (s)
35.0
34.3
Business Tool (s)
0.18
0.18
ATP send/recv (s)
0.13 / 0.08
0.13 / 0.10
Table 1. Travel coordination results (medians over five runs per variant).
Figure 2. Travel coordination timelines. Rows show offline and migration, with five runs each; columns show two time windows from the booking instruction. The interval from 90 to 375 seconds is omitted. Dark bars mark absence; bold rows identify the runs closest to each variant’s median total time. A two-by-two grid shows all five runs of each variant. The top row is offline and the bottom row is migration; the left column spans zero to ninety seconds and the right column spans three hundred seventy-five to four hundred seventy-five seconds. A shared legend appears below the panels.
Check
Observation Result for Each Time
Pass
Retrieve after offline (600 seconds)
20/20 messages received, no missing, duplication or content error
5/5
Address unchanged after migration
20/20 new messages fetched on new IP, old batch not fetched repeatedly
5/5
Independent reverification of signature
20/20 signatures passed verification
5/5
Tampering detection
60/60 modified envelopes rejected
5/5
Two agents on one server
20/20 messages each, no inbox mixing
5/5
Table 2. Mechanism checks and observation results, each item runs 5 times.
Figure 3. End-to-end latency CDFs at two loads, with shared logarithmic axes. Dotted guides mark p50 and p99. Two side-by-side CDF panels compare direct HTTPS, same-domain ATP, and cross-domain ATP at two and twenty messages per second. Both panels use identical logarithmic latency limits and share a path-color legend below.
Figure 4. Runtime latency breakdown. Open markers denote p50; segment ends denote p99. Two side-by-side panels show the median-to-ninety-ninth-percentile latency intervals for cross-domain path segments and receiving-server processing stages. A shared legend below identifies the two traffic loads.
Test Case
Rejected by Which Check (Status Code)
Pass
Forged signature
Signature check (403)
3/3
Tampered content
Signature check (403)
3/3
Use other domain key
Domain consistency (403)
3/3
Unauthorized source address
ATS policy (403)
3/3
Forged source request header
ATS policy (403)
3/3
Replay
Replay prevention cache (400)
3/3
Table 3. Security checks. Each test case runs 3 times, all are rejected by expected mechanisms, messages do not enter the inbox.
Figure 5. Delivery under receiver outages, with three runs per duration. The x-axis is send time relative to outage start. The staircase predicts delivery delay; crosses mark expired messages at the 290 s cutoff. The orange circle marks the single prediction mismatch. Shading indicates the outage. Three equal-height panels in one row across both columns show all messages during thirty-, two-hundred-forty-, and two-hundred-seventy-second outages. Predicted delay, recovery, expired messages, repeated runs, send timing, and the single mismatch are explained by a shared legend below the panels.
Appendix figures & tables3 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 6. ATP interaction flows: message delivery and custody transfer, request/response deadlines and matching, and the subscription lifecycle. Three equal-height diagrams appear side by side across both columns. They illustrate asynchronous message delivery, request and response with deadline checks, and event subscription with renewal, cancellation, and expiry.