Upgrade or Switch: Do We Need a Next-Gen Trusted Architecture for the Internet of AI Agents?

Abhishek Singh; Aditi Joshi; Ayush Chopra; Dimitris Stripelis; Jared James Grogan; Mahesh Lambe; Maria Gorskikh; Pradyumna Chari; Raghu Bala; Rajesh Ranjan

REVIEW 3 major objections 5 minor 2 cited by

Upgrade or Switch: Do We Need a Next-Gen Trusted Architecture for the Internet of AI Agents?

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper argues that autonomous AI agents impose qualitatively new infrastructure demands—millisecond-level discovery and revocation, cryptographic proofs of behavior—that make today's DNS/PKI/IP assumptions obsolete, and predicts a…

desk verdict A useful taxonomy and honest draft, but the 'qualitative break' claim is a hypothesis, not a result. read the letter →

arxiv 2506.12003 v2 pith:JXPKXIWS submitted 2025-06-13 cs.NI cs.AIcs.MA

Ramesh Raskar , Pradyumna Chari , Jared James Grogan , Mahesh Lambe , Robert Lincourt , Raghu Bala , Aditi Joshi , Abhishek Singh

show 6 more authors

Ayush Chopra Rajesh Ranjan Shailja Gupta Dimitris Stripelis Maria Gorskikh Sichao Wang

This is my paper · ORCID

classification cs.NIcs.AIcs.MA

keywords InternetofAIAgentsagentregistryDNSlimitationscertificaterevocationdecentralizedidentifierscapability-basedaddressinghybridindexarchitectureautonomous

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether the human web's infrastructure can be stretched to serve an Internet of AI Agents or whether agents need a purpose-built registry architecture. It argues the break is qualitative, not incremental: agents initiate actions, persist state, migrate between hosts, and spawn helpers, so they need millisecond-level capability lookup and instant credential revocation, while DNS propagation can stretch to 24–48 hours and certificate revocation cannot track trillions of short-lived entities. The paper weighs upgrading DNS, PKI, and IPv6 against clean-slate index designs and concludes that neither pure path wins: a hybrid will emerge, with centralized registries for safety-critical agents and federated meshes for specialized ones. A sympathetic reader should take this as a formative architecture argument that identifies where the legacy stack crosses a threshold and sets measurable targets for whatever replaces it, rather than as a finished protocol proposal.

What carries the argument

The load-bearing object is the agent index or registry: an authoritative system that stores cryptographic identifiers, capability descriptors, trust metadata, and audit logs for agents. The paper positions it as a resolution layer above DNS, IP, and PKI rather than a replacement for transport, and contrasts upgrade paths (SVCB/HTTPS records carrying capability hashes, DNS Push via RFC 8765, RDAP metadata extensions, ACME-plus certificates with short-lived stapled proofs) with switch paths (a clean-slate cryptographic namespace, self-sovereign DID meshes, and capability-first addressing such as '/translate-en-es'). The registry does the work that DNS did for the human web: it makes identity portable when agents migrate hosts, makes revocation immediate, and makes capability claims cryptographically checkable, with the paper's proposed AgentFacts metadata binding an agent's identifier to capability hashes, policy constraints, and runtime attestations.

What would settle it

Run a large deployed agent ecosystem and measure the distribution of discovery and revocation times using ordinary DNS with low TTLs and short-lived certificates; if the 99th percentile of both stays under one second without a purpose-built registry, the paper's millisecond-level break is not supported.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that the legacy web stack was built for human-initiated, stateless, slowly changing resources and therefore has a latent capability threshold that autonomous agents cross. Crossing that threshold demands three new properties: self-directed discovery (an agent finds and negotiates with unknown peers in milliseconds), delegated authority with instant revocation (helper-agent grants can be yanked the moment they misbehave), and cryptographic proof of behavior rather than proof of domain control. From this, the paper derives that per-agent IP addressing is economically and operationally untenable—$10^{12}$ /32 prefixes would inflate the BGP table by six orders of magnitude—that DNS propagation at 24–48 hours is orders of magnitude too slow for agent churn, and that CRL/OCSP cannot scale to trillions of certificates. The conclusion is that the future is a layered index: centralized registries for high-trust agents and federated meshes such as DID, IPFS, or ActivityPub for the long tail, bridged by gateways that sign and cache proofs so agents can cross tiers in under 50 ms.

Load-bearing premise

The argument rests on unvalidated projections that there will be trillions of always-on agents requiring millisecond-level discovery and revocation; if real agent ecosystems tolerate sub-second or second-level operations, or grow only to millions or billions of entities, the claimed qualitative break with legacy infrastructure weakens.

Editorial extensions

If this is right

Discovery and revocation move from a human-timescale DNS/PKI problem to a millisecond registry problem, with SVCB/HTTPS records and DNS Push as stopgaps rather than endpoints.
Per-agent IP addressing is ruled out, so any workable design routes through an indirection layer that shields BGP from agent churn.
Certificate trust shifts from domain-validated identity to capability attestation and short-lived, stapled proofs, with software-bill-of-materials digests bound to each agent credential.
Enterprises will demand configurable search paths that resolve internal registries first and then public ones, with audit logs for every boundary-crossing lookup.
The likely near-term outcome is hybrid: centralized registries for critical or safety-sensitive agents, federated meshes for specialized ones, and gateway bridges for interoperability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A consequence the paper leaves implicit is that whoever controls the registry layer inherits the gatekeeper role that domain-name governance and certificate authorities hold today, creating a new contest over which agents get indexed and which capabilities get attested.
A testable extension would be to instrument a production agent framework and measure real discovery and revocation latency envelopes; if 95th-percentile times stay under one second through upgraded DNS and short-lived certificates, the millisecond requirement is an assumption rather than a measured constraint.
If no registry standard is adopted quickly, the likely near-term world is fragmented agent networks separated by bridge gateways, with large platforms running private centralized indexes over federated long tails—mirroring the walled-garden risk the paper flags for naming.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Worth a read if you work on agent infrastructure. This is a position paper, not a research result, and once you know that, it is a decent one. The authors know the relevant systems (DNS, PKI, BGP, RDAP, DIDs) and structure the upgrade/switch/hybrid space clearly. The labels—Latent Capability Threshold, AgentFacts—are new wrappers around known ideas, but the comparative table (Table 3) and the discussion of configurable search paths and boundary-aware resolution are genuinely useful for framing the problem. They also do something rare in vision papers: they list their own unknowns. The Unknown Unknowns section openly says latency thresholds 'have yet to be measured' and floats 5/50/500 ms as open questions. That honesty earns credit.

Now the soft spots. The load-bearing premise is the claim that agent requirements are qualitative, not incremental, because agents need millisecond-level lookup and revocation and will number in the trillions. Neither number is established. Worse, the paper itself undercuts the latency premise: Table 1 gives autonomous agents an external goal latency budget of 0.25–3 s (LLM inference plus network). A discovery step inside that budget realistically needs tens to hundreds of milliseconds, not single-digit milliseconds. The Unknown Unknowns section confirms the real threshold could be 500 ms. If that is the case, the argument for a qualitative break weakens substantially; DNS Push, SVCB records, and short-lived OCSP-stapled proofs become viable upgrades, as the authors themselves note.

The paper also conflates two different quantities: steady-state DNS query latency (10–100 ms) and worst-case update propagation (24–48 h at long-tail ISPs). The 24–48 h figure is real, but presenting it as the representative DNS latency is misleading. The 'trillions of agents' scale is extrapolated from serverless invocation counts and IoT ratios, which is not a workload model.

That said, the core recommendation—a hybrid of centralized registries for critical agents and federated meshes for the long tail—is reasonable and well argued, as a scenario. The problem is that the paper presents it as a determinate prediction, not a conditional analysis. The authors should either bring workload evidence for the latency and scale assumptions or soften the conclusion to 'if agents require X, then hybrid.'

My advice: send this to peer review as a position/vision paper. The taxonomy deserves discussion, and the honest framing of open questions makes it useful. But the referee letter should be clear that the qualitative-break conclusion is not currently supported by the evidence in the paper.

Referee Report

3 major / 5 minor

Summary. The paper is a position/RFC-style analysis of whether the emerging ecosystem of autonomous AI agents requires a fundamentally new trusted architecture or can be served by upgrading the existing DNS, PKI, and IP-based web stack. It identifies three purported failure points: DNS propagation (24–48 h worst case vs. required milliseconds), certificate revocation unable to scale to trillions of entities, and IPv4/IPv6 addressing inadequate for agent-scale routing. It then compares three paths—upgrade, clean-slate switch, and hybrid—and concludes that agent requirements are a qualitative break, and that hybrid index/registry architectures, with centralized indexes for critical agents and federated meshes for specialized cases, are the most likely outcome. The argument is qualitative, relying on historical analogy (dial-up to broadband), a continuum from static endpoints to autonomous agents, and a comparative table of upgrade versus switch options, without empirical measurements, simulations, or quantitative workload models.

Significance. If the qualitative-break thesis is correct, the paper identifies a consequential architectural direction for the future Internet of AI Agents, and it usefully catalogs concrete mechanisms (DNS Push, short-lived OCSP-stapled proofs, SVCB/HTTPS records, DIDs, capability-first addressing) that could either extend or replace the legacy stack. The paper is also honest in parts, explicitly stating in the Unknown Unknowns section that latency thresholds are yet to be measured. However, the central conclusion rests on two unvalidated premises—trillion-scale agent populations and millisecond-level discovery/revocation requirements—and the manuscript's own Table 1 (0.25–3 s external goal latency) and Unknown Unknowns discussion (5/50/500 ms as an open question) undercut the strongest form of the claim. The paper is a plausible hypothesis-generating essay, but it does not yet provide the evidence or structured scenario analysis needed to turn that hypothesis into a demonstrated architectural conclusion.

major comments (3)

[Potential Issues] The assertion that 'Agents demand millisecond-level capability look-ups, key exchange, and revocation' is the load-bearing premise for the entire upgrade-versus-switch comparison, yet it is not supported by the manuscript's own data. Table 1 gives an external goal-fulfillment latency of 0.25–3 s for LLM-backed agents, and the Unknown Unknowns section explicitly asks whether the threshold is 5 ms, 50 ms, or 500 ms and states that 'empirical thresholds have yet to be measured.' Under a 500 ms budget, ordinary DNS query latencies (10–100 ms) and OCSP stapling with short TTLs are not 'orders of magnitude too slow.' The categorical 'qualitative, not incremental' conclusion in the Continuum section therefore depends on a premise the paper itself leaves open. Please replace the categorical millisecond claim with a scenario analysis across the plausible range, or supply a defended workload model for agent discovery and revocation.
[Challenges in Scaling – Known Unknowns] The paper cites worst-case DNS propagation of 24–48 hours as evidence that DNS is too slow for agents, but this conflates update-propagation convergence (how long a record change takes to reach all resolvers) with steady-state query latency (how long a lookup takes). These are different quantities: a DNS query for a stable record is typically tens of milliseconds, and the paper's own Upgrade Options section lists DNS Push (RFC 8765), sub-second TTLs, and short-lived OCSP-stapled proofs as mechanisms that address the propagation problem, with Table 3 targeting '<1 s global convergence' for the upgrade path. The paper should state the required convergence time for agent registries and compare that requirement against the upgrade mechanisms it itself enumerates; as written, the 24–48 h figure is a worst-case outlier, not the representative timescale for query latency, and it cannot support the 'orders of magnitude too slow' framing.
[Introduction] The 'trillions of always-on software actors' scale premise is extrapolated from 'trillions of serverless invocations per month' and IoT device counts, but neither statistic implies trillions of concurrent agent identities that require global discovery and revocation. The subsequent arguments about BGP table inflation (10^12 prefixes), CRL size, and per-agent IPv4 costs scale linearly with this assumed population. The paper should provide a range of plausible agent-population scenarios (e.g., 10^7, 10^9, or 10^12 agents) and show at which population each claimed failure point becomes material. Without this sensitivity analysis, the qualitative-break claim is not established, and the upgrade path may well remain viable for a substantial portion of the expected operating range.

minor comments (5)

[Table 1] The 'Typical latency budget' row for autonomous agents (internal loop <250 ms; external goal fulfilment 0.25–3 s) is hard to reconcile with the abstract and Potential Issues sections, which assert 'millisecond-level' discovery and revocation; please clarify how these numbers relate to each other.
[Unknown Unknowns] The paper lists '5 ms, 50 ms or 500 ms' as candidate thresholds for global discovery and authentication but does not use these candidates to bound the later upgrade-versus-switch comparison; a short scenario analysis using these three values would materially strengthen the argument.
[Glossary] The glossary defines 'AgentFacts' as a proposed metadata extension binding an agent ID to capability hashes, policy constraints, and runtime attestations, but the body of the paper never specifies it beyond this one-line definition; please either provide a concrete protocol sketch or explicitly label it as a placeholder for future work.
[References] The reference list is incomplete and inconsistently cited: the text uses [1]–[8] in a non-sequential way, at least one reference (ref. [7], the EV SSL certificate source) is not cited in the body, and the 'Figure 1' mentioned in the Introduction is not actually present in the manuscript.
[Glossary] The glossary defines 'Latent Capability Threshold' as the point where discovery latency, revocation speed, and behavioural attestation exceed legacy protocol limits, but this term is not used in the Continuum section or anywhere else in the text; please either use it where the continuum is discussed or remove it.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the paper's architectural comparison is self-contained and benchmarked to external DNS/BGP/PKI facts; its weakest premise is an unvalidated latency/scale assumption, not a circular reduction.

full rationale

The paper does not fit any model to data and never defines a target result in terms of its own assumptions. The upgrade-vs-switch comparison is grounded in externally checkable quantities: DNS propagation of 24-48 hours, a BGP table of roughly one million prefixes, IPv4 exhaustion, roughly 44% IPv6 adoption, and CRL/OCSP revocation behavior. The contested premise, that agents demand millisecond-level discovery, key exchange, and revocation, is asserted in the Introduction and in the Potential Issues section, and the paper's own Unknown Unknowns section concedes that 'empirical thresholds have yet to be measured' and asks whether the real threshold is 5, 50, or 500 ms. That is an unvalidated empirical assumption and a correctness risk, but it is not a circular step: the conclusion is not obtained by renaming the premise, and nothing is fitted and then re-labeled as a prediction. Table 1's 0.25-3 s external goal-fulfillment latency could even be read as tension with the millisecond claim, but internal inconsistency is not circularity. The only self-referential artifact is the glossary entry 'AgentFacts - Proposed metadata extension (our paper)', which is not used as evidence for any conclusion, and no self-citation chain, imported uniqueness theorem, or ansatz-by-citation appears. Accordingly no circular step can be quoted, and the score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 1 invented entities

The paper introduces no fitted parameters in the mathematical sense, but it does rely on hand-chosen projections (trillion agents, millisecond latency) and a selected worst-case DNS propagation figure. The core analysis depends on domain assumptions about the accuracy of cited infrastructure limitations and the validity of the dialup-to-broadband analogy. The only invented entity, AgentFacts, is a placeholder proposal without independent evidence. The central claim does not depend on AgentFacts, so the circularity burden is low.

free parameters (3)

trillion-agent scale = 10^12 agents
Illustrative projection asserted in the Introduction ('we may soon face trillions of always-on software actors'), used to justify the need for new architectures. No empirical basis is provided.
millisecond discovery and revocation latency budget = sub-second to milliseconds
Stated as a requirement in the Potential Issues section ('Agents demand millisecond-level capability look-ups, key exchange, and revocation'), but no measurement or workload analysis supports this number.
24-48 hour DNS propagation = 24-48 hours
Cited as worst-case from a DNS service vendor and used to represent DNS propagation limitations. This is a hand-selected worst-case value, not a measured distribution.

assumptions (3)

domain assumption The cited performance characteristics of DNS, CRL/OCSP, and BGP are accurate and representative.
The paper relies on external references for DNS propagation times, OCSP latency, and BGP table sizes. If these citations are inaccurate or outdated, the central comparison weakens.
domain assumption The dialup-to-broadband transition is a valid analogy for the AI agent infrastructure transition.
The paper repeatedly draws lessons from the dialup-to-broadband history to argue that qualitative changes require new infrastructure. The applicability of this analogy to AI agents is asserted, not demonstrated.
ad hoc to paper Autonomous AI agents will exist at trillion scale and require millisecond-level coordination.
This is the load-bearing premise introduced by the paper without evidence. It appears in the Introduction and drives the central claim that legacy infrastructure breaks down.

invented entities (1)

AgentFacts
purpose: Proposed metadata extension that binds an agent's ID to capability hashes, policy constraints, and runtime attestations.
Introduced in Table 2 as '(our paper)' and referenced in the comparative analysis, but no protocol specification, implementation, or testable design is provided in this draft.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Upgrade or Switch: Do We Need a Next-Gen Trusted Architecture for the Internet of AI Agents?." pith.science (2026). https://pith.science/paper/JXPKXIWS

@misc{pith2026250612003,
  author       = {Pith},
  title        = {Pith review of: Upgrade or Switch: Do We Need a Next-Gen Trusted Architecture for the Internet of AI Agents?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JXPKXIWS}},
  note         = {Machine review of arXiv:2506.12003}
}

read the original abstract

The emerging Internet of AI Agents challenges existing web infrastructure designed for human-scale, reactive interactions. Unlike traditional web resources, autonomous AI agents initiate actions, maintain persistent state, spawn sub-agents, and negotiate directly with peers: demanding millisecond-level discovery, instant credential revocation, and cryptographic behavioral proofs that exceed current DNS/PKI capabilities. This paper analyzes whether to upgrade existing infrastructure or implement purpose-built index architectures for autonomous agents. We identify critical failure points: DNS propagation (24-48 hours vs. required milliseconds), certificate revocation unable to scale to trillions of entities, and IPv4/IPv6 addressing inadequate for agent-scale routing. We evaluate three approaches: (1) Upgrade paths, (2) Switch options, (3) Hybrid index/registries. Drawing parallels to dialup-to-broadband transitions, we find that agent requirements constitute qualitative, and not incremental, changes. While upgrades offer compatibility and faster deployment, clean-slate solutions provide better performance but require longer for adoption. Our analysis suggests hybrid approaches will emerge, with centralized indexes for critical agents and federated meshes for specialized use cases.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Using the NANDA Index Architecture in Practice: An Enterprise Perspective
cs.NI 2025-08 conditional novelty 3.0 of 10

A work-in-progress proposal for a global agent registry, cryptographically signed capability claims, and cross-protocol adapters for secure AI agent collaboration.
Agentic Web: Weaving the Next Web with AI Agents
cs.AI 2025-07 conditional novelty 3.0 of 10

A position paper defines the Agentic Web as the next web era and proposes a three-dimensional conceptual framework for understanding and building it.

Reference graph

Works this paper leans on

5 extracted references · 4 canonical work pages · cited by 2 Pith papers

[1]

(2025, April)

DataReportal & Kepios. (2025, April). Digital 2025 April Global Statshot Report . https://datareportal.com DataReportal – Global Digital Insights 2. Shen, M., & Yang, Q. (2025). From mind to machine: The rise of manus ai as a fully autonomous digital agent. arXiv preprint arXiv:2505.02024 . 3. Gao, Z., & Venkataramani, A. (2019, April). Measuring update p...

arXiv 2025
[4]

(2025, March 25)

DNS Made Easy. (2025, March 25). DNS propagation: Why doesn’t my domain work? DNS Made Easy. https://dnsmadeeasy.com/resources/dns-propagation-why-doesnt-my-domain-work 5. Google. (2025, May 6). IPv6 adoption statistics. Retrieved May 13, 2025, from https://www.google.com/intl/en/ipv6/ DRAFT V0.3, Work in Progress, Request for Comments

work page 2025
[6]

(2025, Apr.)

World Wide Web Consortium. (2025, Apr.). Decentralized identifiers (DIDs) v1.1 (W3C Recommendation). 7. Chamola, S. (2023, September 22). EV SSL certificates: Pros & cons. Encryption Consulting. https://www.encryptionconsulting.com/ev-ssl-certificates-pros-cons/

work page 2025
[8]

Barnes, R., Hoffman ‑ Andrews, J., McCarney, D., & Kasten, J. (2019). Automatic Certificate Management Environment (ACME) (RFC 8555). Internet Engineering Task Force. https://doi.org/10.17487/RFC8555

work page doi:10.17487/rfc8555 2019
[9]

Service-Level Objectives,

Nielsen, J. (1993/2020, October 4). Response Times: The 3 Important Limits. Nielsen Norman Group. https://www.nngroup.com/articles/response-times-3-important-limits/ 10. Beyer, B. et al. (2016). Site Reliability Engineering: How Google Runs Production Systems — Section “Service-Level Objectives,” Example latency budgets. Google SRE online copy: https://sr...

work page 2016

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

(2025, April)

DataReportal & Kepios. (2025, April). Digital 2025 April Global Statshot Report . https://datareportal.com DataReportal – Global Digital Insights 2. Shen, M., & Yang, Q. (2025). From mind to machine: The rise of manus ai as a fully autonomous digital agent. arXiv preprint arXiv:2505.02024 . 3. Gao, Z., & Venkataramani, A. (2019, April). Measuring update p...

arXiv 2025

[2] [4]

(2025, March 25)

DNS Made Easy. (2025, March 25). DNS propagation: Why doesn’t my domain work? DNS Made Easy. https://dnsmadeeasy.com/resources/dns-propagation-why-doesnt-my-domain-work 5. Google. (2025, May 6). IPv6 adoption statistics. Retrieved May 13, 2025, from https://www.google.com/intl/en/ipv6/ DRAFT V0.3, Work in Progress, Request for Comments

work page 2025

[3] [6]

(2025, Apr.)

World Wide Web Consortium. (2025, Apr.). Decentralized identifiers (DIDs) v1.1 (W3C Recommendation). 7. Chamola, S. (2023, September 22). EV SSL certificates: Pros & cons. Encryption Consulting. https://www.encryptionconsulting.com/ev-ssl-certificates-pros-cons/

work page 2025

[4] [8]

Barnes, R., Hoffman ‑ Andrews, J., McCarney, D., & Kasten, J. (2019). Automatic Certificate Management Environment (ACME) (RFC 8555). Internet Engineering Task Force. https://doi.org/10.17487/RFC8555

work page doi:10.17487/rfc8555 2019

[5] [9]

Service-Level Objectives,

Nielsen, J. (1993/2020, October 4). Response Times: The 3 Important Limits. Nielsen Norman Group. https://www.nngroup.com/articles/response-times-3-important-limits/ 10. Beyer, B. et al. (2016). Site Reliability Engineering: How Google Runs Production Systems — Section “Service-Level Objectives,” Example latency budgets. Google SRE online copy: https://sr...

work page 2016