{"id":"2488a4d0-5256-4f34-8757-a01b5cbfc21e","arxiv_id":"2601.14567","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"An agent:// URI scheme that separates agent identity from network location, enabling DHT-based capability discovery and PASETO-attested capability claims.","lead":"This paper proposes a new type of address for AI agents, called agent://, that stays the same even when an agent moves to a different server. It also lets programs find agents by what they can do, and includes a way to cryptographically verify an agent's claimed abilities.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Prefix queries over SHA-256 DHT keys are unspecified: without an external index, a query for /workflow/approval cannot enumerate descendants like /workflow/approval/invoice, so capability discovery is unsupported.","rationale":"The reader's weakest-assumption analysis correctly identifies the prefix-query enumeration gap as the load-bearing flaw in the paper's central claim. I reviewed the full text and find the same issue: Sections 4.1 and 4.3 promise prefix matching over descendant capability paths, but the key derivation (SHA-256 of the full canonical path) and the registration rule (most-specific level only) make descendant enumeration impossible without an external index. This is not a minor implementation detail; it is a missing piece of the formal specification. The paper itself flags related gaps (e.g., capability mapping services in Section 8.3 are noted as future work), and the DHT participation incentive is admitted as underspecified. The prefix enumeration problem is more fundamental because it is the mechanism that is supposed to make discovery work at all. The performance contradiction between the abstract's 'under 5 microseconds' and the Table 5 max parsing time of 5.7–6.4 microseconds is a real credibility issue, and the identity-stability section's retreat from 'formal proofs' (Section 6.3) to 'by construction' also undercuts the abstract's wording. But the prefix enumeration flaw alone is sufficient to reject the central claim. No independent support (machine-checked proofs, reproducible code, external validation) is provided to offset this gap. The reader's verdict of REJECT stands.","tokens_in":13325,"tokens_out":3726,"duration_ms":37107,"concrete_test":"Implement a minimal Kademlia DHT with the paper's key derivation and registration rules: register N agents at distinct leaf paths under /workflow/approval (e.g., /workflow/approval/invoice, /workflow/approval/expense) using only the protocol in Sections 4.1–4.2. Issue a prefix query for /workflow/approval using only the stated mechanism (derive the exact key for the prefix and any explicitly stated levels; no external path list or wildcard index). Measure recall. If recall < 1.0, the protocol as written cannot support prefix discovery without an undeclared global index. Conversely, if a wildcard or enumeration layer is added, verify whether it introduces a centralized registry, contradicting R3.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central discovery mechanism depends on prefix queries returning all descendant capability paths, but this is not implemented by the paper's own key derivation. Section 4.1 defines key = SHA256(canonical(trust_root) || \"/\" || canonical(cap_path)), and Section 4.2 requires agents to register only at their most specific level (e.g., /workflow/approval/invoice). A prefix query for /workflow/approval must therefore locate every registration whose cap_path starts with that prefix. However, SHA-256 destroys path ordering: hashes of /workflow/approval, /workflow/approval/invoice, and /workflow/approval/expense are unrelated 256-bit values. Kademlia's exact-key lookup (Section 4.4) retrieves a record only if the full key is already known. The paper says a prefix query 'queries keys for /workflow/approval, /workflow/approval/*, and so on' (Section 4.1), but a key for \"/workflow/approval/*\" is not a registered key, and no mechanism enumerates the concrete child paths. Without an external index mapping prefixes to registered children, a query for /workflow/approval cannot discover /workflow/approval/invoice. If such an index exists, it either requires global coordination (violating R3's 'no centralized registry') or presumes every node knows all paths, which defeats decentralization. The F1=1.0 evaluation in Section 6.2 is circular: it simulates prefix matching while assuming the enumeration the protocol never provides. This gap undermines the paper's central claim of a 'formally-specified, practically-evaluated foundation' for capability-based discovery.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an agent:// URI scheme that separates agent identity from network location. A URI consists of a trust root, a hierarchical capability path, and a sortable TypeID. Capability paths are hashed into Kademlia DHT keys, agents register at their most specific capability path, and prefix queries are intended to discover descendant paths. The paper reports perfect F1 on a 10,000-agent discovery simulation, 100% path coverage on 369 production tools, migration-invariant identity, and microsecond-scale performance. The requirements analysis and the general architectural direction are sensible, but the central discovery mechanism is underspecified and the main evaluation is constructed so that the reported success is guaranteed by the setup.","tokens_in":13767,"tokens_out":6280,"duration_ms":71119,"significance":"If the prefix-enumeration problem were actually solved, the scheme would be a useful contribution: it applies Saltzer's name/address separation to agents and combines it with organizational trust roots, capability attestations via PASETO, and trust-scoped DHT key derivation. The paper is candid about limitations and open incentive questions, which is commendable. However, as written, the headline capability-discovery claim cannot be accepted: the specified SHA-256 DHT key derivation does not support the described prefix queries, and the F1=1.0 evaluation does not test the protocol as it would actually run. The paper is therefore currently suggestive rather than demonstrating its central claims.","major_comments":[{"comment":"Section 4.1, Eq. (1), defines key = SHA256(canonical(trust_root) || \"/\" || canonical(cap_path)). SHA-256 destroys path structure, so a query for /workflow/approval cannot enumerate the keys for /workflow/approval/invoice or /workflow/approval/expense unless those concrete paths are already known. The statement that prefix matching 'queries keys for /workflow/approval, /workflow/approval/*, and so on' is not an algorithm: there is no registered '/workflow/approval/*' key, and Kademlia's exact-key XOR lookup (§4.3–4.4) provides no substring or prefix iteration. Section 4.2 says agents register only at their most specific path, so descendants are not present under the query path. Without an explicit mechanism to enumerate child paths or a DHT data structure supporting prefix range queries, capability-based discovery as claimed is unimplementable. Introducing an external index would violate","section":"§4.1–4.4"},{"comment":"The discovery-precision experiment is circular. The 'ground truth' in the 10,000-agent simulation is the same registration table the simulated DHT uses, and queries are generated from that table. Precision = recall = 1.0 is therefore guaranteed by construction, not measured. The paper provides no independent ground-truth labeling, no holdout, and no perturbation of registrations or queries. The 'Expected Degradation' paragraph is a qualitative disclaimer, not an experiment. F1=1.0 cannot support the headline discovery claim without a protocol-aware evaluation.","section":"§6.2"},{"comment":"The abstract claims 'formal proofs of migration invariance', but Section 6.3 states: 'Rather than formal proofs of these properties (which hold by construction), we analyze failure modes.' Theorem 1 and Theorem 2 concern DHT resolution bounds and eventual consistency, not identity stability. This is an overstatement. If identity stability is definitional, the paper should say so and should not list it as an evaluated property alongside the other empirical dimensions.","section":"§6.3 / Abstract"}],"minor_comments":[{"comment":"The ABNF defines base32char = ALPHA / \"2\" ... \"7\", but the comment says the alphabet excludes I, L, O, U. ALPHA includes those letters; the grammar should exclude them explicitly if that is the intended set.","section":"§3.4"},{"comment":"The 100% coverage and zero-collision result over 369 tools is a weak test, because the deterministic mapping rules are chosen by the authors and no independent semantic baseline is used. The flat-namespace ablation is more informative and should be the primary result if it is retained.","section":"§6.1"}],"recommendation":"reject","confidential_remarks":"The paper is not ready for publication. The prefix-enumeration gap and the circular discovery evaluation are load-bearing rather than local issues. Fixing them would require a new or substantially revised protocol design for capability discovery and a new evaluation that exercises the actual protocol. The author's explicit acknowledgment of limitations in §8.3 is appreciated, but it does not repair the central unsupported claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nShort version: this is a useful design sketch, and the combination of TypeID/UUIDv7, Kademlia key derivation, and PASETO attestation into an agent URI scheme is genuinely new. But the central capability-discovery claim doesn't hold as written. The prefix-query mechanism is unspecified: Section 4.1 says a query for /workflow/approval queries keys for /workflow/approval, /workflow/approval/*, and so on, but a key for /workflow/approval/* is never registered. Agents register only at the most specific path (Section 4.2), and SHA-256 hashes destroy order, so Kademlia exact-key lookup can't find descendants. The F1=1.0 evaluation simulates prefix matching while assuming the enumeration the protocol never provides. That circularity is load-bearing; the scheme's core is capability-based discovery.\n\nWhat's good: the trust root / capability path / sortable ID separation is clean, the capability grammar covers 369 real tools with no collisions (a real result), and the identity-stability property holds by construction. The failure-mode analysis in Section 6.3 is more honest than most. The paper also flags its own limitations—DHT incentives, no global ontology, mapping services as future work—which is more than many papers do.\n\nThe performance claim in the abstract overstates the table: max URI parsing runs 5.7–6.4 µs, above the 'under 5 microseconds' claim. Minor, but fixable.\n\nShould this be desk-rejected? No. The idea is relevant, the citation pattern is fair, and the central gap is likely tractable with a better key derivation or an explicit index. A serious referee could help the author turn a promising sketch into something solid. I'd send it out, with the prefix-query issue as the first thing to resolve.","headline":"A real design contribution whose core discovery mechanism has an unspecified prefix enumeration—fixable, and worth a serious referee.","tokens_in":14193,"tokens_out":2900,"would_cite":false,"duration_ms":29698,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes an agent:// URI scheme that separates agent identity from network location, enabling stable references and capability-based discovery over a distributed hash table.","keywords":["multi-agent systems","agent identity","decentralized discovery","capability-based routing","URI schemes","distributed hash table","PASETO attestation","trust root federation"],"falsifier":"Attempt to issue a prefix query for /workflow in a running deployment where agents registered only at leaf paths such as /workflow/approval/invoice, with no external index; if the query returns nothing (because the requester cannot compute descendant keys without prior knowledge of the full path tree), the capability-discovery claim is falsified. Alternatively, check Section 4.1 for a terminating algorithm that lists all possible child paths; without such an algorithm, the prefix-matching enumeration is vacuous.","tokens_in":13246,"feed_emoji":"🤖","tokens_out":8626,"duration_ms":79998,"temperature":0.7,"pith_summary":"The paper argues that today's multi-agent systems make a fundamental architectural error: they let an agent's identity be wherever it happens to run. When an agent migrates, every URI and cached reference to it breaks. The paper proposes a three-part identifier—an organizational trust root, a hierarchical capability path, and a sortable unique ID—that is independent of any endpoint, plus a DHT key-derivation scheme that turns capability paths into lookup keys, and PASETO-signed attestations that bind claimed capabilities to the trust root. The paper reports that the capability grammar covers all 369 tools sampled from five agent frameworks without collisions, that discovery achieves perfect precision/recall in a simulated 10,000-agent network, and that all local operations complete in under five microseconds. If the scheme works as specified, agents could be discovered by what they do rather than where they live, across organizational boundaries, without any central registry.","feed_headline":"New agent:// URIs name agents by capability, not location","feed_subtitle":"Migrating agents keep their identity; discovery finds them by what they do via a DHT in O(log N) hops.","key_machinery":"The central mechanism is the agent:// URI whose three components map onto a DHT key-derivation rule: key = SHA256(trust_root || \"/\" || capability_path). The trust root anchors organizational authority, the capability path provides hierarchical prefix semantics for discovery, and the TypeID agent-id gives globally unique sortable identity. The same key-derivation rule enables trust-scoped exact queries and 'prefix matching' that is supposed to pull in descendant capability paths; PASETO attestation tokens then cryptographically bind the URI's capability path to the trust root's signature, letting any verifier check claims without contacting the issuer in real time.","core_discovery":"The central discovery is a URI grammar that separates identity from location. An agent is named by agent://trust-root/capability-path/agent-id, where the trust root is the organization vouching for it, the capability path describes what it does, and the agent-id is a globally unique TypeID. Because the URI contains no host or port, migration only updates a record in a Kademlia DHT; the name never changes. Capability discovery works by hashing the trust root and capability path together to derive a DHT key, with trust-root scoping ensuring organizations do not see each other's registrations unless they explicitly query across boundaries. Attestations are PASETO tokens signed by the trust root","pith_inferences":["The prefix-matching story is only as strong as the device that enumerates all descendant capability paths for a given prefix. The paper describes querying /workflow/approval, /workflow/approval/*, 'and so on,' but never specifies a bounded procedure that would let a requester discover /workflow/approval/invoice unless it already knew that path existed; without such a procedure (or an external inde","The abstract claims 'formal proofs of migration invariance,' but Section 6.3 explicitly disclaims formal proofs and says the properties hold 'by construction' and instead analyzes failure modes; a reader checking the proof should be aware that the strongest proof claim is not in the body of the paper.","The evaluation's F1=1.0 comes from synthetic data where registrations exactly match capabilities; the paper itself acknowledges that real deployments with capability drift will see recall drop to roughly 0.9, so the perfect discovery numbers should be read as an upper bound, not a typical deployment.","A capability-mapping service, which the paper defers to future work, is likely a pragmatic requirement for cross-organization federation: without shared vocabularies, equivalent paths such as acme.com/workflow/approval and globex.com/process/authorize will never be linked, and the paper's own 'no global ontology' choice guarantees silent failure for such equivalent capabilities."],"forward_implications":["Agents can migrate between cloud providers, servers, or regions without changing their URI or breaking references; resolution cost stays O(log N) regardless of migration history.","Capability-based discovery works across organizational boundaries without a central registry: a requester hashes a trust root and capability path, queries the DHT, and gets agents registered under that path and its descendants.","Verification of capability claims is decentralized: an attestation can be checked against a trust root's cached public key, so the issuing authority need not be online at verification time.","Trust boundaries are explicit: cross-organization discovery only happens when the requester explicitly queries each trust root, preventing automatic cross-organization pollution.","The scheme maps cleanly onto existing agent frameworks — 369 tools were representable with zero namespace collisions — suggesting compatibility with current ecosystems."],"fun_headline_variants":["Agent URIs drop location, keep identity","Name agents by what they do, not where they live","Capability-first agent IDs survive migration","Agent identity decoupled from network location","agent:// URIs: stable identity, capability discovery"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The scheme's discovery guarantee rests on the assumption that, given a prefix like /workflow, a requester can enumerate every descendant capability path (e.g., /workflow/approval/invoice) that agents have registered under, but the paper does not specify how that enumeration is produced or bounded.","fun_headline_variants_meta":{"raw":{"variants":["Agent URIs drop location, keep identity","Name agents by what they do, not where they live","Capability-first agent IDs survive migration","Agent identity decoupled from network location","agent:// URIs: stable identity, capability discovery"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000185,"raw_usage":{"total_tokens":1165,"prompt_tokens":758,"completion_tokens":407,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":502,"completion_tokens_details":{"reasoning_tokens":338}},"tokens_in":502,"tokens_out":407,"duration_ms":4391,"temperature":1.0,"reasoning_tokens":338,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T09:07:05.321159+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Attempt to issue a prefix query for /workflow in a running deployment where agents registered only at leaf paths such as /workflow/approval/invoice, with no external index; if the query returns nothing (because the requester cannot compute descendant keys without prior knowledge of the full path tree), the capability-discovery claim is falsified. Alternatively, check Section 4.1 for a terminating algorithm that lists all possible child paths; without such an algorithm, the prefix-matching enumeration is vacuous.","supporting_citations":[],"review_version":1}