A2A-commerce: architecture for AI agents

A2A Commerce Architecture: Designing Infrastructure for AI Agent Interaction

The modern web is built for humans with browsers. But when the client becomes an autonomous AI agent, standard solutions—DOM parsing, OAuth-based API integration, and manual integration—fail to scale. In a world where every user has a personal agent capable of initiating thousands of transactions per second, fundamental changes are needed in addressing, routing, trust, and search. This isn’t an evolution of REST or GraphQL—it’s a new network semantics for machine-to-machine interaction.

Addressing: From URLs to Three-Layer Identification

The human web relies on DNS and URLs: domain → IP → server. For AI agents, this model doesn’t work. An agent can run on a mobile device behind NAT, in a provider’s cloud, or locally on a user’s PC; it can change endpoints, go offline, and have a cryptographic identity independent of infrastructure.

The solution is a three-layer model:

• Human handle (alice#aigentix.org) — a readable identifier transmitted via QR codes and messages;
• DID (did:aip:aigentix.org:alice) — a decentralized identifier following the W3C standard, containing public keys and not tied to a domain;
• Endpoint (https://hub.aigentix.org/relay/alice) — a physical delivery route that can change dynamically without losing identity.

A key technical detail: the # symbol in the handle conflicts with the fragment identifier in HTTP. In the API, the handle is always URL-encoded: alice%23aigentix.org. The server doesn’t receive GET /api/v1/resolve/alice#aigentix.org, but only GET /api/v1/resolve/alice. This isn’t trivial—it’s an example of how legacy web conventions create real obstacles when designing next-generation protocols.

Resolution happens sequentially: handle → lookup in the registry → DID → DID Document (with route_mode and public keys) → endpoint. Caching results at the registry level ensures performance, while layer separation guarantees long-term stability of identifiers.

Routing: Direct vs. Relay and Strict Idempotency

Having an endpoint alone doesn’t solve the delivery problem. Two main modes—direct and relay—address different classes of tasks:

• Direct: HTTP POST directly to the recipient’s endpoint. Suitable for corporate agents with public IPs and guaranteed availability.
• Relay: Publishing to a durable stream (e.g., NATS JetStream) and having the recipient subscribe via WebSocket. Ensures delivery even when offline but adds latency.

The choice of mode is determined by an algorithm:

• Resolve the recipient’s DID;
• If route_mode == "direct" and the endpoint is available—use direct;
• Otherwise—use relay.

Relay implies at-least-once delivery. This isn’t optional—it’s a requirement. The recipient must implement idempotent processing based on message_id. Each message contains mandatory fields:

• id: UUID v4;
• created_at: timestamp in RFC 3339;
• encrypted_body: encrypted payload (X25519 ephemeral key exchange);
• sig: Ed25519 signature over the serialized envelope.

Deduplication is implemented via a sliding window: message IDs from the last 10 minutes are stored with an allowable clock skew of ±300 seconds. A simple LRU cache in Redis or an LSM-tree in RocksDB is sufficient.

Trust: Cryptographic Certificates and Trust Graphs

Humans trust brands, reviews, and ratings. Machines only trust verifiable claims. We use the W3C Verifiable Credentials (VC) standard as the foundation of our trust model.

Example VC for verifying a legal entity:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OrganizationVerification"],
  "issuer": "did:aip:aigentix.org:trust-anchor",
  "credentialSubject": {
    "id": "did:aip:aigentix.org:etagi",
    "legalName": "Etazhi LLC",
    "inn": "7224052984",
    "verified": true
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
    "proofValue": "..."
  }
}

Such a certificate is issued by a Trust Anchor—a trust center whose DID and public keys are known to all network participants. Verification is done locally, without involving third parties.

Individual VCs form a Trust DAG—a directed acyclic graph where the weight of each edge depends on the issuer’s authority. The Trust Score calculation algorithm is conservative:

• The score grows slowly: many successful interactions are required;
• The score drops quickly: revocation or validation errors reduce it immediately;
• The final range is [0.0, 1.0].

This score is integrated into search via Reciprocal Rank Fusion (RRF):

final_score = RRF(semantic_rank, fts_rank) × (1 + 0.3 × trust_score)

The parameter trust_weight = 0.3 ensures that trust enhances relevance but doesn’t replace it.

Search: Hybrid Ranking and Structured Responses for Agents

Search for humans returns HTML pages. Search for agents returns a structured object indicating how to get more data. The response should include not only the data but also the agent-provider’s address:

{
  "results": [
    {
      "id": "doc_123",
      "name": "2-bedroom apartment, Tverskaya St., 68 m²",
      "price": 79,000,
      "available": true,
      "relevance_score": 0.92,
      "trust_score": 0.94,
      "agent": {
        "handle": "etagi%23aigentix.org",
        "name": "Etaji",
        "endpoint": "https://api.etagi.ru/aip"
      }
    }
  ]
}

The agent field isn’t a link to a website—it’s an address for further A2A calls. After resolving etagi%23aigentix.org, the agent sends a POST with the type aip.commerce.offer.request and item_id, receiving structured photos, floor plans, and contact details—without any HTML rendering.

Hybrid search is necessary because pure semantic search isn’t enough:

• Product codes and exact phrases (e.g., iPhone 15 Pro Max 256GB) require FTS;
• New entities (brands, companies, products) lack sufficient semantic context in embeddings;
• Numerical values (price, area, floor) are poorly distinguished in embedding space.

RRF is implemented as:

def rrf(semantic_rank, fts_rank, k=60):
    return 1/(k + semantic_rank) + 1/(k + fts_rank)

This allows combining two rankings without normalization, preserving sensitivity to top positions and consistently improving quality on mixed queries.

Protocol as Specification: Interoperability Over Implementation

The key principle is strict separation of protocol and implementation. The AIP (Agent Interaction Protocol) defines:

• Envelope format: mandatory fields id, from, to, type, encrypted_body, sig;
• Rules for resolving handle → DID → endpoint;
• Schema for search requests and responses;
• Algorithms for verifying VCs and calculating Trust Scores.

Implementation (Hub) can use any stack: Rust with Actix, Go with NATS, Python with FastAPI—these are deployment details. This architecture ensures:

• Interoperability between agents from different developers;
• No vendor lock-in for businesses;
• Federation capability: Hubs on different domains can route messages to each other.

The analogy with email is apt: SMTP is an open protocol, Gmail and Yandex.Mail are independent implementations, yet emails travel between them without coordination.

What Matters

• Addressing AI agents requires a three-layer model (handle/DID/endpoint) to separate readability from cryptographic identity and physical routing.
• Relay routing mandates strict idempotency: each message must have a UUID v4 and created_at, and the recipient must support sliding-window deduplication.
• Trust is built on W3C Verifiable Credentials, not centralized ratings: verification happens locally, without external services.
• Search for agents returns not URLs but objects with agent.handle and agent.endpoint—this is the foundation for the next level of A2A interaction.
• Hybrid search (RRF) combines FTS and semantic ranking because embeddings don’t replace exact matches for product codes, numbers, and new entities.
• The protocol must be separated from implementation: this is the condition for interoperability, federation, and protection against vendor lock-in.

— Editorial Team