RogueSwarms Product Architecture and Information Architecture: A Machine-First Design Report

Full report

On this page

1. Executive Summary

The transition from a human-centric web to a machine-centric, agentic web necessitates fundamentally different infrastructure. Historically, web architecture optimized for human consumption via browsers executing HTML, CSS, and JavaScript. In contrast, the emerging agentic economy requires stateless, deterministic, and machine-readable environments where autonomous agents can discover peers, negotiate capabilities, establish cryptographic trust, and execute commerce without human intervention. The absence of a fully decentralized, verifiable, and privacy-preserving communication protocol for autonomous agents remains a core challenge in distributed computing, often leading to reliance on centralized intermediaries that reintroduce trust bottlenecks and limit cross-network interoperability1.

RogueSwarms is positioned to provide neutral, non-proprietary infrastructure for independent ecommerce machine intelligence agents. This report outlines the product architecture and information architecture required to build a machine-first RogueSwarms website. The architecture strictly avoids proprietary runtimes and JavaScript dependencies, favoring root-deployable PHP serving deterministic JSON and utilizing standardized HTTP mechanics. The primary objective is to facilitate machine-readable agent discovery, capability publication, and cryptographically secure commerce declarations.

The analysis synthesizes current agent ecosystems, including the Agent2Agent (A2A) protocol2, the Model Context Protocol (MCP)4, the Agent Payments Protocol (AP2)6, and Lightning HTTP 402 (L402) micropayments8. It further integrates decentralized identity standards (W3C DID)10 and Verifiable Credentials Data Model v2.0 (VCDM)11. The overarching conclusion is that RogueSwarms must function as a decentralized discovery and attestation layer—a highly structured, hypermedia-driven registry that manages capability routing and cryptographic trust without acting as a centralized arbiter of truth. By enforcing strict content negotiation, immutable schemas, and decentralized identifiers, RogueSwarms will enable a resilient, trustless ecosystem for autonomous agent commerce.

2. Recommended Conceptual Architecture

The conceptual architecture of RogueSwarms must reflect its role as a neutral facilitator rather than a proprietary gatekeeper. Historical attempts to create centralized web service registries, most notably the Universal Description, Discovery, and Integration (UDDI) standard, failed due to over-engineered XML/SOAP structures, rigid top-down architectures, and an overemphasis on physical location rather than logical capability13. RogueSwarms must avoid these pitfalls by adhering to RESTful principles, decentralized trust, and modular capability declarations.

In large-scale agentic systems, discovery mechanisms must handle significant churn from node failures and demand-driven agent lifecycles17. While pure peer-to-peer Distributed Hash Tables (DHTs) like Kademlia or Chord offer decentralized routing, they introduce high control-plane overhead and latency during agent discovery19. RogueSwarms provides an alternative: a highly available, federated discovery node that operates on standard web infrastructure, bridging the gap between isolated AI agents and a global, interconnected agentic web20.

2.1 Protocol Agnosticism and Ecosystem Interoperability

RogueSwarms must support competing and complementary agent protocols without tightly coupling to any single one. The architecture must accommodate both vertical integrations (agents connecting to tools) and horizontal integrations (agents connecting to other agents)21.

 

2.2 Decentralized Trust vs. Centralized Authority

A foundational requirement for agentic commerce is the establishment of trust without relying on probabilistic AI inferences or centralized authorization bottlenecks30. RogueSwarms will not act as a certificate authority, nor will it compute opaque "trust scores" or reputation metrics, which mislead users and create centralized liability12.

Instead, RogueSwarms will implement a "Bring Your Own Trust" (BYOT) model utilizing the W3C Verifiable Credentials Data Model v2.0 (VCDM)11. Agents will publish their public keys and Decentralized Identifiers (DIDs) on the platform. Trust is derived entirely from cryptographically signed third-party attestations (e.g., an audit firm signing a credential that an agent is compliant with specific commerce regulations, or a user signing a mandate authorizing a specific purchase)11. RogueSwarms acts merely as the highly available bulletin board where these cryptographic proofs are discovered and retrieved for local verification by the querying agent.

3. Recommended Site Information Architecture

The information architecture (IA) is designed exclusively for software agents, with human-readable HTML serving only as a secondary fallback via content negotiation. The IA relies heavily on RFC 8615 (Well-Known URIs) to bootstrap discovery31 and RFC 8288 (Web Linking) to establish semantic relationships between decentralized resources33.

3.1 Initial Discovery and Domain Root

When an autonomous agent reaches RogueSwarms.com, it requires immediate, deterministic routing without executing JavaScript or parsing DOM elements.

The response to a GET / request depends entirely on the client's Accept header, enforcing strict server-driven content negotiation35. When a machine requests Accept: application/json or a specific vendor media type like Accept: application/vnd.rogueswarms.index+json, the server must return a canonical machine manifest. This manifest acts as the root node of a hypermedia-driven API (HATEOAS), exposing RFC 8288 \_links to all major subsystems, including agent directories, capability registries, and trust ledgers33.

Before querying the root, compliant software agents commonly probe /.well-known/ paths to discover site-wide metadata without requiring prior agreement on URL structures31. RogueSwarms must expose a configuration endpoint at /.well-known/rogueswarms-configuration, conceptually analogous to the openid-configuration endpoint used in OpenID Connect40. This JSON document will define the base API URIs, supported cryptographic suites, and canonical schema locations, allowing a visiting agent to dynamically map the entire RogueSwarms infrastructure before issuing a single transactional request32.

3.2 Resource Partitioning Strategy

The site's information architecture strictly separates volatile state from immutable cryptographic evidence. This partitioning guarantees that historical transaction records and capability definitions cannot be altered, providing a reliable foundation for agent auditability.

• Mutable Directories (Stateful): Paths such as /agents/ and /capabilities/ represent the current state of the network. Agents can PUT or PATCH their endpoints, operational statuses, or capability declarations as their lifecycles fluctuate between active and dormant states17.
• Append-Only Ledgers (Historical): Paths such as /trust/ and /attestations/ act as chronological event logs. Agents may append new verifiable credentials or transaction receipts, but historical records cannot be modified or deleted. Revocation is handled exclusively via appended Bitstring Status Lists42.
• Immutable Artifacts (Static): Paths such as /schemas/ and /protocols/ define the unchangeable rules of engagement. Once a schema version (e.g., /schemas/ap2/cart-mandate/v1.0.json) is published, it must remain static indefinitely. Altering a schema post-publication causes downstream type-coercion failures, leading to severe AI hallucinations where models misinterpret data types and execute catastrophic errors in commerce or data handling44.

3.3 Human-Readable Documentation Fallback

While RogueSwarms is engineered for machines, developers require documentation to build compatible agents. Human-readable documentation should not exist on separate URL paths. Instead, if a client requests a resource with Accept: text/html, RogueSwarms will utilize content negotiation to serve an HTML representation of the documentation or the specific agent record46. This ensures that URIs remain canonical and universally applicable regardless of the consuming entity.

4. Recommended Machine-Resource Hierarchy

The resource hierarchy prioritizes predictable URIs and a strict separation of concerns, ensuring that agents can autonomously navigate the platform utilizing standard HTTP methods.

 

Stable URIs are paramount in this hierarchy. A broken link for a machine client severs the execution graph entirely. Resources under /schemas/, /attestations/, and specific versions of capabilities must be completely immutable. Any PUT, POST, or PATCH request to these endpoints post-creation must be rejected with an HTTP 405 Method Not Allowed response.

If an agent's underlying infrastructure moves, RogueSwarms must implement graceful redirection. The platform should return an HTTP 308 Permanent Redirect (which preserves the original request method and body, unlike 301\) and include the RFC 8288 Link: \<new-uri\>; rel="canonical" header, allowing the machine client to update its internal routing tables automatically34.

5. Proposed Canonical Agent Data Model

The agent data model must bridge the gap between decentralized identity and functional capability publication. The recommended approach is to adapt the W3C DID Core specification, augmented with metadata from the A2A AgentCard format10.

5.1 Identity and Addressing via Decentralized Identifiers (DIDs)

Agents should be exclusively identified by Decentralized Identifiers (DIDs), decoupling them from centralized registries that can revoke access arbitrarily10. RogueSwarms should natively support the did:web method, which leverages existing DNS and HTTPS infrastructure for reputation and discovery53. Furthermore, RogueSwarms should support did:wba, an extension of did:web optimized for agent scenarios, which enforces strict Ed25519 or ECDSA cryptographic binding for cross-domain authentication55.

When a machine client executes a GET request to /agents/{did}, the canonical agent record must contain a strict set of mandatory fields to ensure operational viability, alongside optional fields for extended context:

Mandatory Fields:

1. id: The precise DID of the agent10.

2. verificationMethod: The public cryptographic keys associated with the agent. For general authentication, Ed25519 is preferred. However, for commerce via the AP2 protocol, agents must explicitly publish ECDSA P-256 keys, as AP2 forbids deterministic schemes like Ed25519 for Checkout JWTs10.

3. service: The physical network endpoints (e.g., Streamable HTTP, JSON-RPC) where the agent can be actively engaged10.

Optional Fields:

1. capabilities: URIs pointing to the /capabilities/ registry, declaring the specific tools or A2A skills the agent possesses26.

2. health: Standardized indicators of current load or availability, vital for handling agent-level churn and demand-driven lifecycles17.

5.2 Mitigating Server-Side Request Forgery (SSRF) in JSON-LD

A critical architectural vulnerability involves the parsing of the agent data format itself. W3C DID Core and Verifiable Credentials rely heavily on JSON-LD (JavaScript Object Notation for Linked Data) and the @context attribute to provide semantic meaning to the JSON payload10. The standard behavior of many JSON-LD processors is to dynamically dereference remote @context URIs at runtime to retrieve the schema definitions.

Allowing machines to dynamically fetch arbitrary URLs provided by untrusted agents introduces severe Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE) vulnerabilities. This exact vector has been exploited repeatedly across the industry (e.g., CVE-2026-47965, CVE-2026-72904, and vulnerabilities in ldfetch and Python RDFLib)58. Attackers exploit remote context loading to force the host server to query internal cloud metadata endpoints (such as AWS 169.254.169.254), exposing internal system information, authentication tokens, and providing footholds for lateral network movement59.

Architectural Decision: RogueSwarms must strictly forbid remote @context dereferencing at runtime64. All JSON-LD payloads submitted to the platform must be validated exclusively against a locally hosted, immutable whitelist of schemas located at /schemas/. If an agent submits a DID document or Verifiable Credential containing an unknown or external @context URI, the RogueSwarms parser must reject the payload immediately with an HTTP 400 Bad Request. This secure-by-default posture eliminates the SSRF attack vector while maintaining compliance with semantic web standards59.

6. Proposed Capability Data Model

Capabilities inform a querying agent exactly what a target agent can execute, the parameters required, and the expected output. Because RogueSwarms must remain protocol-agnostic, the capability data model must be expressive enough to seamlessly wrap MCP Tools, A2A Skills, and generic REST endpoints within a unified structure4.

6.1 Naming, Namespacing, and Commerce Roles

To prevent namespace collisions in a global directory, capabilities must be named using Reverse Domain Name Notation (e.g., com.rogueswarms.commerce.purchase.v1) or deterministic UUIDs generated from the capability's semantic hash.

Within the capability declaration, agents must explicitly define their commerce roles, particularly to comply with the Agent Payments Protocol (AP2) extension architecture. The AP2 specification dictates a strict separation of duties to ensure PCI-DSS compliance and cryptographic accountability7. Capabilities must include a commerceRoles array utilizing AP2 enumerations, such as \["merchant"\], \["shopper"\], \["trusted-surface"\], or \["credential-provider"\]28. This explicit declaration allows querying agents to filter the registry for appropriate transaction partners without ambiguous capability matching.

6.2 Schema Definition and Discovery

Machine clients must discover and validate schemas without human intervention. Machine clients will discover schemas via the /schemas/ endpoint, and responses from capability APIs will utilize the RFC 8288 Link: \<url\>; rel="describedby" header to programmatically point clients to the exact schema governing the response50.

All capability interfaces must be strictly defined using JSON Schema 2020-1250. This specific dialect matches the default established by the Model Context Protocol (MCP) and is fully supported by A2A49. Enforcing JSON Schema 2020-12 ensures deterministic type checking and prevents the cascading failures that occur when LLM-driven agents hallucinate data structures due to permissive or absent validation rules44.

The capability data model must contain:

• name: The machine-readable, namespaced identifier.
• description: Semantic context optimized for interpretation by Large Language Models (LLMs)69.
• inputSchema: A valid JSON Schema 2020-12 object defining the exact required arguments and constraints.
• outputSchema: A valid JSON Schema 2020-12 object defining the structure of the successful return payload.
• protocols: An array of supported protocol URIs (e.g., https://github.com/google-agentic-commerce/ap2/tree/v0.1) demonstrating how the capability is invoked66.

7. Proposed Trust and Verification Model

The trust model addresses the core crisis of agentic commerce: How does a merchant agent definitively know that a shopping agent possesses the authority to spend funds on behalf of a human, and who is accountable if the transaction is fraudulent?6.

7.1 Cryptographic Proofs over Inferred Trust

RogueSwarms will explicitly avoid generating, hosting, or endorsing arbitrary "Trust Scores" or probabilistic reputation metrics. Such metrics are easily manipulated, mislead users, and force the platform into the role of a centralized liability-bearing underwriter12. Instead, RogueSwarms will serve as a neutral ledger for cryptographic proofs, utilizing the W3C Verifiable Credentials Data Model v2.0 (VCDM v2.0)11.

When an agent needs to prove its compliance, solvency, or authorization, it presents a Verifiable Credential signed by a trusted third party (an Issuer) to the querying agent (the Verifier). The querying agent evaluates the cryptographic signature locally. RogueSwarms merely hosts the DID documents and public keys required to resolve the signatures, ensuring the platform never assumes the risk of validating the truthfulness of the claim itself10.

7.2 The AP2 Mandate Pipeline

To facilitate secure agent-to-agent commerce, the trust model fully integrates the Agent Payments Protocol (AP2). AP2 establishes transactional accountability by breaking the payment process into three distinct, non-repudiable cryptographic contracts known as Mandates, secured as Selective Disclosure JSON Web Tokens (SD-JWTs)7.

RogueSwarms will host the schemas and routing infrastructure necessary for agents to exchange these Mandates:

1. Intent Mandate: Created by the human user's device (the Trusted Surface), this mandate cryptographically signs the constraints of the task (e.g., "Authorized to purchase running shoes for maximum $150"). It provides the foundational proof of user consent7.

2. Cart Mandate: Once the shopping agent negotiates a specific purchase with a merchant agent, the exact itemized cart and final price are locked into a Cart Mandate, signed by both the merchant and the user (or the agent, in autonomous scenarios). This prevents post-negotiation price manipulation7.

3. Payment Mandate: Derived from the Cart Mandate, this minimal credential is sent to the payment network. It separates the itemized cart data from the payment authorization, ensuring privacy and maintaining PCI-DSS compliance by preventing the shopping agent from accessing raw payment tokens7.

All Mandates rely on ECDSA signatures to guarantee integrity28. RogueSwarms will provide the /trust/ and /attestations/ append-only endpoints for agents to permanently log these transaction receipts and closed mandates, providing a verifiable audit trail for dispute resolution without exposing sensitive financial data6.

8. Recommended URI Structure

Autonomous agents require uncompromising stability in URI structures. An architecture that routinely breaks links or alters the state of historical resources will rapidly degrade the reliability of the agentic network.

The URI structure follows strict immutability rules based on the resource type. Records located at /schemas/, /attestations/, and specific versioned instances of capabilities (e.g., /capabilities/purchase/v1.0) are totally immutable. Once a POST request successfully creates these resources, any subsequent modification attempts must result in an HTTP 405 Method Not Allowed response.

Endpoints categorized as append-only, such as /trust/{did}/, permit the addition of new verifiable credentials or revocation bitstrings, but historical entries within the collection cannot be modified or destroyed42.

To handle the inevitable movement or restructuring of agent infrastructure, RogueSwarms must implement graceful redirection. When an agent's canonical DID or capability endpoint migrates, the original URI must return an HTTP 308 Permanent Redirect (ensuring that clients re-issue POST requests with the original payload intact, unlike 301 which may degrade to GET). The response must also include the RFC 8288 header Link: \<new-uri\>; rel="canonical" to programmatically instruct the machine client to permanently update its internal routing tables34.

9. Recommended Content-Negotiation Behavior

Content negotiation is the HTTP-driven process by which a client and server agree on the most appropriate representation of a resource, allowing a single URI to serve different formats based on client capabilities35. For RogueSwarms, proactive, server-driven content negotiation based on RFC 9110 is mandatory35.

9.1 Accept Headers and Vendor Media Types

Machine clients interacting with RogueSwarms must explicitly declare their requirements utilizing the Accept header. A request specifying Accept: application/json will return the standard JSON response, while Accept: text/html will instruct the server to render a human-readable fallback view of the directory or documentation, keeping URLs clean and unified35.

To ensure robust machine interoperability, RogueSwarms should implement vendor-specific media types. Instead of generic JSON, agents should request strict schemas via headers such as Accept: application/vnd.rogueswarms.agent.v1+json36. This mechanism embeds the versioning and format requirements directly into the HTTP request layer.

9.2 Strict Fallbacks and Vary Headers

If a machine client transmits an Accept header that RogueSwarms cannot fulfill, the architecture dictates a "fail closed" approach. The server must return an HTTP 406 Not Acceptable error rather than pragmatically guessing or defaulting to a generic format36. This strict enforcement forces developers to program compliant, deterministic agents.

Furthermore, to prevent cache poisoning or fragmentation at the CDN layer, every response generated via content negotiation must include the Vary: Accept header. This instructs intermediate caching servers to store separate copies of the response based on the exact Accept header provided by the client, ensuring that a machine does not inadvertently receive a cached HTML payload intended for a browser36.

10. Recommended Versioning Strategy

A dual-layered versioning strategy is required to balance infrastructure routing with data model evolution.

URI versioning (e.g., /api/v1/agents) is practical for major, breaking architectural overhauls affecting the entire platform35. However, utilizing URIs to version individual agent records or specific capability schemas creates a brittle ecosystem where agents constantly update their external links.

Therefore, RogueSwarms will rely on content-negotiation versioning for data model iterations36. If the schema defining an agent record evolves from version 1 to version 2, the underlying URI (/agents/{did}) remains perfectly stable. The querying client dictates the desired version via the Accept header: Accept: application/vnd.rogueswarms.agent.v2+json. The server dynamically formats the response to match the requested version. This guarantees the longevity of URIs while facilitating seamless, non-breaking schema evolution for the agentic network.

11. Recommended Deprecation Strategy

APIs, capabilities, and agent schemas inevitably face retirement. Unlike human developers who can interpret blog posts or email announcements, autonomous agents require standardized, machine-readable deprecation signals embedded directly within the protocol layer.

RogueSwarms must implement the IETF standard HTTP headers for lifecycle management to communicate these changes effectively71:

1. Deprecation: \<HTTP-date\> (RFC 9745): This header signals to the consuming agent that the specific endpoint or schema is officially deprecated. The presence of this header, carrying a structured field date, instructs the machine client to avoid forming new dependencies on the resource while continuing to operate normally in the short term72.

2. Sunset: \<HTTP-date\> (RFC 8594): This header provides a concrete, non-negotiable deadline indicating precisely when the resource will become completely unresponsive. It allows the agent to calculate the exact timeframe required to execute a migration71.

3. Link: \<replacement-uri\>; rel="successor-version": Working in tandem with the previous headers, the RFC 8288 Link header programmatically routes the agent to the upgraded resource or documentation, enabling automated migration pathways73.

Once the timestamp defined in the Sunset header passes, RogueSwarms must cease returning 200 OK or 404 Not Found, and instead return HTTP 410 Gone. This explicit status code signals that the resource has been permanently removed, instructing the client agent to permanently purge the endpoint from its local routing and capability tables73.

12. "Do Not Build" List

To ensure RogueSwarms remains neutral, infinitely scalable, and highly secure, the following components must explicitly not be built:

1. Do Not Build Proprietary Agent Runtimes: RogueSwarms serves exclusively as a decentralized directory, discovery node, and infrastructure layer. It must not host the actual execution logic, memory management, or processing environments of the agents. Agents must remain independent entities hosted on their own external infrastructure.

2. Do Not Build Centralized Payment Processors: RogueSwarms facilitates the discovery of payment capabilities and the cryptographic logging of AP2 mandates. It must not handle the actual settlement of funds. Payment clearance remains the exclusive domain of AP2 Issuers, L402 Lightning nodes, and traditional Payment Service Providers (PSPs)8.

3. Do Not Build Dynamic Remote JSON-LD Resolvers: As extensively documented, dynamic resolution of JSON-LD @context URIs introduces critical SSRF and RCE vulnerabilities. RogueSwarms parsers must be strictly locked to local, immutable schemas, explicitly rejecting requests that rely on arbitrary remote context fetching59.

4. Do Not Build Subjective Trust Scores: RogueSwarms must avoid synthesizing Verifiable Credentials into a proprietary "RogueSwarms Reputation Score." The platform must act as a neutral conduit, passing the raw cryptographic evidence directly to the querying agent to evaluate locally, thereby avoiding the liability of acting as a centralized arbiter of truth12.

13. Top 10 Architecture Decisions RogueSwarms Should Make Now

1. Mandate JSON Schema 2020-12: Standardize all capability, input, and output definitions exclusively on the JSON Schema 2020-12 dialect to ensure strict deterministic parsing and full compatibility with the Model Context Protocol (MCP) and A2A standards50.

2. Adopt W3C VCDM v2.0: Utilize the latest W3C Verifiable Credentials Data Model standard to handle all trust, auditability, and decentralized attestations across the platform11.

3. Implement AP2 Cryptographic Roles: Structure the commerce capabilities around the AP2 framework (e.g., Shopping Agent, Merchant, Trusted Surface) and strictly mandate ECDSA P-256 for all commerce-related cryptographic signatures28.

4. Enforce Strict Content Negotiation: Require machine clients to utilize exact Accept headers and fail closed with HTTP 406 Not Acceptable for unsupported requests to ensure strict, predictable machine compliance35.

5. Bootstrap via RFC 8615 Well-Known URIs: Centralize initial network discovery by exposing the /.well-known/rogueswarms-configuration endpoint31.

6. Ban Remote JSON-LD Dereferencing: Eliminate SSRF attack vectors by strictly utilizing a local, immutable schema registry for all JSON-LD @context validations59.

7. Utilize Decentralized Identifiers (DIDs): Anchor all agent identities to the did:web or did:wba methods, removing reliance on centralized identity providers and embedding reputation directly into the DNS layer53.

8. Implement Lifecycle Headers: Programmatically manage the deprecation of APIs, capabilities, and resources utilizing the RFC 9745 (Deprecation) and RFC 8594 (Sunset) HTTP headers71.

9. Support Streamable HTTP: Reject the deprecated Server-Sent Events (SSE) transport protocol in favor of Streamable HTTP to facilitate robust, real-time agent-to-agent capability negotiations via MCP24.

10. Design for Absolute Immutability: Enforce strict append-only and immutable database constraints on trust records, schemas, and historical capability definitions to guarantee a non-repudiable audit trail for the agentic economy.

14. Major Unresolved Questions

Several complex architectural challenges require further research before a v1.0 deployment:

• Discovery Reliability Under High Churn: How will RogueSwarms manage "agent-level churn"—the rapid warming, cooling, and termination of agents based on dynamic demand—without flooding the central directory with stale capability endpoints? While academic research into Distributed Hash Tables (DHTs) suggests structured overlays handle physical node-churn efficiently, demand-driven agent cooling presents unique caching and availability challenges that require sophisticated heartbeat monitoring17.
• Protocol Conflict (L402 vs. AP2): While AP2 provides robust, multi-stage authorization mandates ideal for high-value e-commerce7, the L402 protocol excels at sub-cent, instantaneous API micropayments utilizing HTTP 402 and the Lightning network8. RogueSwarms must determine exactly how an agent seamlessly declares support for both paradigms within the same capability interaction without causing processing deadlocks.
• Migration to Quantum-Resistant Cryptography: Currently, the AP2 protocol and standard Verifiable Credentials rely heavily on Elliptic Curve cryptography (ECDSA P-256)28. As quantum computing capabilities advance, these algorithms will become vulnerable. RogueSwarms will need to define a clear, non-disruptive migration path for existing Verifiable Credentials utilizing the emerging W3C Quantum-Resistant Cryptosuites v1.0 specification42.

15. Source Architecture and Integration

The following authoritative specifications and research documents form the foundational architecture of this report.

Proposed RogueSwarms v1 Machine-Facing Resource Map

/ \# Root Manifest (Content Negotiated HATEOAS Entry)

/.well-known/rogueswarms-configuration \# Site-wide discovery and capability config

/api/v1/ \# API Base for transactional endpoints

/agents/ \# Mutable Agent Directory

/{did} \# Individual Agent DID Document

/capabilities/ \# Mutable Capability Registry

/{id}/v1 \# Specific Immutable JSON Schema 2020-12 Definitions

/protocols/ \# Immutable Protocol Index

/mcp \# MCP standard pointers and configurations

/ap2 \# AP2 standard pointers and configurations

/a2a \# A2A standard pointers and configurations

/trust/ \# Append-Only W3C Verifiable Credentials Directory

/{did} \# Trust attestations bound to a specific agent

/attestations/ \# Append-Only ledgers for system events

/{hash} \# Immutable transaction/interaction receipt

/schemas/ \# Immutable Localized JSON-LD @contexts & JSON Schemas

Works cited

1. A Decentralized Agent Identity Protocol with Zero-Knowledge Proofs, https://arxiv.org/abs/2511.11619

2. Agent2Agent Protocol: The Standard for AI Agent Interoperability, https://www.salesforce.com/agentforce/ai-agents/agent2agent-protocol/

3. Agent2Agent (A2A) is an open protocol enabling ... \- GitHub, https://github.com/a2aproject/a2a

4. Specification \- Model Context Protocol （MCP）, https://modelcontextprotocol.info/specification/2025-06-18/

5. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28

6. Agent Payments Protocol (AP2), https://ap2-protocol.net/en/

7. Agent Payments Protocol (AP2) \- Worldline Connect, https://docs.connect.worldline-solutions.com/documentation/ConnectAI/agent-payments-protocol-ap2

8. L402 — Pay for APIs with Lightning. Authenticate with the receipt., https://l402.tech/

9. L402 Protocol Explained: HTTP 402 for Machine API Payments, https://satgate.io/blog/l402-protocol-explained

10. Decentralized Identifiers (DIDs) v1.1 \- W3C, https://www.w3.org/TR/did-1.1/

11. Verifiable Credentials Data Model v2.0 \- W3C, https://www.w3.org/TR/vc-data-model-2.0/

12. W3C Verifiable Credentials 2.0: The New Standard Reshaping, https://vidos.id/blog/w3c-verifiable-credentials-2-0-the-new-standard-reshaping-enterprise-digital-identity

13. Three Post-Mortem Lessons From a Failed Software Project, https://dev.to/canro91/three-post-mortem-lessons-from-a-failed-software-project-53jo

14. Udi Dahan \-- the biggest mistakes teams make when applying DDD, https://gojko.net/2010/06/11/udi-dahan-the-biggest-mistakes-teams-make-when-applying-ddd/

15. UDDI basic architecture | Download Scientific Diagram, https://www.researchgate.net/figure/UDDI-basic-architecture\_fig8\_226871083

16. Verification of Web Services Using an Enhanced UDDI Server., https://www.researchgate.net/publication/221189090\_Verification\_of\_Web\_Services\_Using\_an\_Enhanced\_UDDI\_Server

17. Usable Agent Discovery for Decentralized AI Systems \- arXiv, https://arxiv.org/pdf/2604.23080

18. Usable Agent Discovery for Decentralized AI Systems \- arXiv, https://arxiv.org/abs/2604.23080

19. Trade-offs in Decentralized Agentic AI Discovery Across the ... \- arXiv, https://arxiv.org/pdf/2605.11839

20. A Unified Agent Communication Protocol (ACP) for Secure ... \- arXiv, https://arxiv.org/html/2602.15055v1

21. MCP vs A2A Protocol: Architecture, Differences and When to Use, https://atlan.com/know/mcp/mcp-vs-a2a-protocol/

22. Architecture \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28/architecture

23. Model Context Protocol (MCP) vs. Agent2Agent (A2A) \- Redis, https://redis.io/blog/mcp-vs-a2a-which-protocol-do-you-need/

24. MCP: Model Context Protocol \- Cheatsheet | SFEIR Institute, https://institute.sfeir.com/en/claude-code/claude-code-mcp-model-context-protocol/cheatsheet/

25. Overview \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28/basic/transports

26. Agent2Agent (A2A) Protocol Specification, https://a2a-protocol.org/latest/specification/

27. Agent2Agent (A2A) Protocol: Opening a New Era for Autonomous AI, https://www.tmasolutions.com/insights/agent2agent-a2a-protocol-opening-a-new-era-for-autonomous-ai-agents-interaction

28. AP2 Protocol Explained: How Agent Payments Get Authorized, https://dodopayments.com/blogs/ap2-protocol-agent-payments

29. Introduction to L402: Lightning-Powered Payment Protocol for AI, https://www.nervos.org/knowledge-base/introduction\_to\_l402

30. Secure Use of the Agent Payments Protocol (AP2) | CSA, https://cloudsecurityalliance.org/blog/2025/10/06/secure-use-of-the-agent-payments-protocol-ap2-a-framework-for-trustworthy-ai-driven-transactions

31. Well-known URI \- Wikipedia, https://en.wikipedia.org/wiki/Well-known\_URI

32. RFC 8615: Well-Known Uniform Resource Identifiers (URIs), https://www.rfc-editor.org/info/rfc8615/

33. RFC 8288: Web Linking \- Ian Duncan, https://www.iankduncan.com/projects/rfc-browser/8288

34. RFC 8288 Web Linking, https://www.rfc-editor.org/rfc/rfc8288.html

35. Content Negotiation in REST APIs: Accept Headers \+ Examples, https://www.restguide.info/content-negotiation

36. REST API Content Negotiation: A Practical Guide \- ASOasis Tech, https://asoasis.tech/articles/2026-05-07-0253-rest-api-content-negotiation-guide/

37. HTTP Content Negotiation explained, https://http.dev/content-negotiation

38. How to add RFC 8288 HTTP link header to a response, https://stackoverflow.com/questions/56009033/how-to-add-rfc-8288-http-link-header-to-a-response

39. OpenID Connect Discovery and the .well-known Endpoints \- Abblix, https://www.abblix.com/en/docs/discovery-and-well-known-endpoints

40. Well-Known URIs explained \- HTTP.DEV, https://http.dev/well-known-uris

41. What Is .well-known/openid-configuration? A Developer's Guide, https://www.authgear.com/post/well-known-openid-configuration/

42. Verifiable Credentials Overview v1.1 \- W3C, https://www.w3.org/TR/vc-overview-1.1/

43. The Verifiable Credentials 2.0 family of specifications is now a W3C, https://www.w3.org/news/2025/the-verifiable-credentials-2-0-family-of-specifications-is-now-a-w3c-recommendation/

44. MCP overlooks hard-won lessons from distributed systems, https://news.ycombinator.com/item?id=44846871

45. Schema Reference \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28/schema

46. PHP: HTTP content negotiation \- cweiske.de webmail, https://cweiske.de/tagebuch/php-http-negotiation.htm

47. Your PHP website is a free API: how to unlock it with content, https://dev.to/amaury\_bouchard/your-php-website-is-a-free-api-how-to-unlock-it-with-content-negotiation-2h0p

48. Decentralized Identifier Resolution (DID Resolution) v1 \- W3C, https://www.w3.org/TR/did-resolution-1.0/

49. A2A protocol: Architecture and technical specification \- Tyk.io, https://tyk.io/learning-center/a2a-protocol-architecture-and-technical-specification/

50. SEP-1613: Establish JSON Schema 2020-12 as Default Dialect for, https://modelcontextprotocol.io/seps/1613-establish-json-schema-2020-12-as-default-dialect-f

51. SEP-2106: Tools \inputSchema\ & \outputSchema\ Conform to, https://modelcontextprotocol.io/seps/2106-json-schema-2020-12

52. Decentralized Identifiers (DIDs) v1.0 \- W3C, https://www.w3.org/TR/2021/WD-did-core-20210124/

53. did:web Method Specification, https://w3c-ccg.github.io/did-method-web/

54. Announcing Public Review of the did:webs Method Specification, https://www.trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/

55. did:wba Method Specification \- Agent Network Protocol, https://agent-network-protocol.com/specs/did-method.html

56. JSON-LD Requirements, https://json-ld.org/requirements/latest/

57. Verifiable Credential Data Integrity 1.1 \- W3C on GitHub, https://w3c.github.io/vc-data-integrity/

58. Vulnerability Summary for the Week of June 8, 2026 | CISA, https://www.cisa.gov/news-events/bulletins/sb26-166

59. How Server-Side Request Forgery (SSRF) happens in Node.js and, https://orbisappsec.com/blog/how-server-side-request-forgery-ssrf-happens-in-node-js-12875

60. Server-Side Request Forgery (SSRF) in rdflib | Snyk, https://security.snyk.io/vuln/SNYK-PYTHON-RDFLIB-1324490

61. Critical Firecrawl Flaw Allowed File Read and SSRF via JSON, https://mallory.ai/stories/019fedba-f26a-7e53-b4ba-509606cd765b

62. From Blind SSRF to RCE: How Source Code Review Exposed a, https://blog.cyberadvisors.com/technical-blog/from-blind-ssrf-to-rce-how-source-code-review-exposed-a-critical-exploit-chain

63. Server-Side Request Forgery (SSRF) \- CVEs \- page 12 \- Feedly, https://feedly.com/cve/cwe/918?page=12

64. Verifiable Credential Data Integrity 1.0 \- W3C, https://www.w3.org/TR/vc-data-integrity/

65. Security vulnerability when loading HTTP-based JSON-LD Contexts, https://github.com/json-ld/json-ld.org/issues/213

66. A2A Extension for AP2 \- AP2 Protocol, https://ap2-protocol.net/en/a2a-extension

67. Overview \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2025-11-25/basic

68. Exposed: MCP Servers Are Lying About Their Schemas \- Specmatic, https://specmatic.io/demonstration/exposed-mcp-servers-are-lying-about-their-schemas/

69. Tools \- Model Context Protocol （MCP）, https://modelcontextprotocol.info/docs/concepts/tools/

70. AP2 & the Agent Payments Protocol: What Enterprises Need to, https://www.mintmcp.com/blog/ap2-agent-payments-protocol

71. Sunset Header | APIs.io Providers, https://apis.io/providers/sunset-header/

72. draft-dalal-deprecation-header-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-dalal-deprecation-header-00

73. How to Create API Deprecation Headers \- OneUptime, https://oneuptime.com/blog/post/2026-01-30-api-deprecation-headers/view

74. Support the new Deprecation HTTP header · Issue \#5724 \- GitHub, https://github.com/psf/requests/issues/5724

75. API Deprecation and the Sunset Header \- Routebase, https://routebase.dev/guides/api-versioning/api-deprecation-and-sunset/

76. AP2 Protocol: Complete Guide to Agent Payments for Web3 (2026), https://www.cobo.com/post/ap2-protocol-complete-guide-to-agent-payments-for-web3-developers-2026