Skip to main content
AI-Native Network Protocol (AINP) for Semantic Agent Communication
AI-Native Network Protocol (AINP) for Semantic Agent Communication
draft-ainp-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Eswara Prasad Nagulapalli | ||
| Last updated | 2025-11-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ainp-protocol-00
Independent Submission E. P. Nagulapalli
Internet-Draft Servesys Labs
Intended status: Standards Track 24 November 2025
Expires: 28 May 2026
AI-Native Network Protocol (AINP) for Semantic Agent Communication
draft-ainp-protocol-00
Abstract
This document specifies the AI-Native Network Protocol (AINP) version
0.1, a semantic communication protocol designed for intent exchange
between AI agents. AINP replaces location-based routing with
semantic routing, byte-stream delivery with intent delivery, and
simple handshakes with multi-round negotiation. AINP enables agents
to discover each other by capability rather than network location,
negotiate terms autonomously, and exchange structured intents with
cryptographic security.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 May 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Nagulapalli Expires 28 May 2026 [Page 1]
Internet-Draft AINP Protocol November 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4
3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Message Envelope . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Envelope Fields . . . . . . . . . . . . . . . . . . . 5
3.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Quality of Service Parameters . . . . . . . . . . . . . . 5
3.5. Capability Query . . . . . . . . . . . . . . . . . . . . 6
3.6. Signature Format . . . . . . . . . . . . . . . . . . . . 6
4. Semantic Addresses . . . . . . . . . . . . . . . . . . . . . 6
4.1. Decentralized Identifiers (DIDs) . . . . . . . . . . . . 6
4.2. Semantic Address Structure . . . . . . . . . . . . . . . 7
5. Intent Schemas . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. REQUEST_MEETING Intent . . . . . . . . . . . . . . . . . 7
5.2. APPROVAL_REQUEST Intent . . . . . . . . . . . . . . . . . 7
5.3. SUBMIT_INFO Intent . . . . . . . . . . . . . . . . . . . 8
5.4. INVOICE Intent . . . . . . . . . . . . . . . . . . . . . 8
5.5. FREEFORM_NOTE Intent . . . . . . . . . . . . . . . . . . 8
5.6. REQUEST_SERVICE Intent . . . . . . . . . . . . . . . . . 9
6. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . 9
6.1. Negotiation Flow . . . . . . . . . . . . . . . . . . . . 9
6.2. Negotiation Message Structure . . . . . . . . . . . . . . 9
6.3. Negotiation Convergence . . . . . . . . . . . . . . . . . 9
6.4. Timeout Behavior . . . . . . . . . . . . . . . . . . . . 10
6.5. Multi-Party Negotiation . . . . . . . . . . . . . . . . . 10
7. Protocol Handshake Sequence . . . . . . . . . . . . . . . . . 10
7.1. Five-Step Handshake . . . . . . . . . . . . . . . . . . . 10
7.2. ADVERTISE Phase . . . . . . . . . . . . . . . . . . . . . 10
7.3. DISCOVER Phase . . . . . . . . . . . . . . . . . . . . . 11
7.4. ERROR Phase . . . . . . . . . . . . . . . . . . . . . . . 11
7.5. Offline Intent Queueing . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12
8.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . 12
Nagulapalli Expires 28 May 2026 [Page 2]
Internet-Draft AINP Protocol November 2025
8.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 12
8.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 12
8.5. DoS Protection . . . . . . . . . . . . . . . . . . . . . 13
8.6. Replay Protection and Delivery Semantics . . . . . . . . 13
8.7. Capability Attestations . . . . . . . . . . . . . . . . . 13
8.8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 13
8.9. Outlier Detection . . . . . . . . . . . . . . . . . . . . 13
8.10. Discovery Scalability . . . . . . . . . . . . . . . . . . 13
8.11. Lite Mode for Resource-Constrained Agents . . . . . . . . 14
9. CBOR Encoding (Optional) . . . . . . . . . . . . . . . . . . 15
10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Custom Intent Types . . . . . . . . . . . . . . . . . . 15
10.2. Custom Negotiation Terms . . . . . . . . . . . . . . . . 15
10.3. Versioning . . . . . . . . . . . . . . . . . . . . . . . 15
10.4. Lite Profile (Trusted Networks) . . . . . . . . . . . . 15
11. Success Metrics . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Route Success Rate . . . . . . . . . . . . . . . . . . . 16
11.2. Latency (p95) . . . . . . . . . . . . . . . . . . . . . 16
11.3. Negotiation Completion Rate . . . . . . . . . . . . . . 16
11.4. False Route Rate . . . . . . . . . . . . . . . . . . . . 16
11.5. Abuse Resilience . . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Traditional network protocols (TCP/IP, HTTP, SMTP) were designed for
reliable byte stream delivery between machines. AINP represents a
paradigm shift: it is designed for semantic intent delivery between
AI agents, with built-in understanding, negotiation, and adaptation.
AINP Phase 0.1 provides: - Wire format specification (JSON-LD + CBOR)
- Message envelope structure with cryptographic signatures - Intent
schemas for common agent interactions - Semantic address format with
Decentralized Identifiers (DIDs) - Negotiation protocol for multi-
agent consensus - Discovery and routing mechanisms
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Nagulapalli Expires 28 May 2026 [Page 3]
Internet-Draft AINP Protocol November 2025
1.1.1. Definitions
*Agent*: An autonomous software entity capable of semantic
understanding and intent exchange
*Intent*: A semantic representation of an agent's goal, including
embeddings and structured semantics
*Semantic Address*: An identity-based address using DIDs and
capability descriptors
*Negotiation*: Multi-round protocol for establishing consensus on
resources, terms, and capabilities
*Capability*: A semantic description of what an agent can do,
including natural language and embeddings
*Trust Vector*: Multi-dimensional reputation score tracking
reliability, honesty, competence, and timeliness
2. Architecture Overview
AINP consists of four layers:
+-----------------------------+ | Intent Layer | Semantic exchange
(intents) +-----------------------------+ | Negotiation Layer |
Multi-agent consensus +-----------------------------+ | Routing
Layer | Semantic routing +-----------------------------+ | Substrate
Layer | Physical transport (TCP/IP, etc.)
+-----------------------------+
Phase 0.1 runs as an overlay network on TCP/IP with WebSocket or
HTTP/3 transport.
3. Wire Format
3.1. Encoding
AINP messages MUST support both: - *JSON-LD*: Human-readable, linked
data format with @context for semantic interoperability - *CBOR*:
Binary encoding ([RFC8949]) for efficient transmission
Implementations SHOULD negotiate encoding during handshake. JSON-LD
is the default for Phase 0.1.
Nagulapalli Expires 28 May 2026 [Page 4]
Internet-Draft AINP Protocol November 2025
3.2. Message Envelope
All AINP messages MUST be wrapped in an envelope structure:
json { "version": "0.1.0", "msg_type": "INTENT", "id": "550e8400-
e29b-41d4-a716-446655440000", "timestamp": 1728259400000, "ttl":
30000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
"to_did": "did:key:z6Mk...", "schema":
"https://ainp.dev/schemas/intents/request-meeting/v1", "qos": {
"urgency": 0.7, "importance": 0.8, "novelty": 0.1, "ethicalWeight":
0.5, "bid": 5 }, "payload": { ... }, "sig": "base64signature..." }
3.2.1. Envelope Fields
* version (string, REQUIRED): Protocol version, MUST be "0.1.0"
* msg_type (string, REQUIRED): Message type (see Section 3.3)
* id (string, REQUIRED): UUID v4 for message identification
* timestamp (number, REQUIRED): Unix epoch milliseconds
* ttl (number, REQUIRED): Time-to-live in milliseconds
* trace_id (string, REQUIRED): Distributed tracing UUID for thread
tracking
* from_did (string, REQUIRED): Sender DID ([W3C.DID])
* to_did (string, OPTIONAL): Recipient DID (for direct addressing)
* to_query (object, OPTIONAL): Semantic query (alternative to
to_did, see Section 3.5)
* schema (string, REQUIRED): JSON-LD context URI
* qos (object, REQUIRED): Quality of Service parameters (see
Section 3.4)
* payload (object, OPTIONAL): Application payload (intent,
negotiation, etc.)
* sig (string, REQUIRED): Ed25519 signature in base64 encoding
3.3. Message Types
AINP defines the following message types:
* ADVERTISE: Publish capabilities to discovery index
* DISCOVER: Query for agents by capability
* DISCOVER_RESULT: Discovery results
* NEGOTIATE: Multi-round negotiation
* INTENT: Send intent payload
* RESULT: Response with optional proof
* ERROR: Error response
3.4. Quality of Service Parameters
QoS parameters enable priority-based routing and resource allocation:
Nagulapalli Expires 28 May 2026 [Page 5]
Internet-Draft AINP Protocol November 2025
json { "urgency": 0.7, // 0-1, time sensitivity "importance": 0.8, //
0-1, impact magnitude "novelty": 0.1, // 0-1, information gain
"ethicalWeight": 0.5, // 0-1, moral importance "bid": 5 // Token
amount or credits (non-negative) }
*Priority Calculation*: Implementations SHOULD calculate message
priority as:
priority = (urgency * w_urgency) + (importance * w_importance) +
(novelty * w_novelty) + (ethicalWeight * w_ethical) adjusted_priority
= priority + 0.5 * tanh(bid / bid_scale)
Where bid_scale is node-configurable (RECOMMENDED default: 10
credits).
*Default Weights*: - w_urgency = 0.3 - w_importance = 0.3 - w_novelty
= 0.2 - w_ethical = 0.2
3.5. Capability Query
For semantic discovery, agents use capability queries:
json { "description": "Find agents who can schedule meetings",
"embedding": "base64-encoded Float32Array[1536]", "tags":
["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000,
"max_cost": 10 }
3.6. Signature Format
Messages MUST be signed using Ed25519 ([Ed25519]) with detached
signatures in base64 encoding.
*Signing Process*: 1. Serialize envelope fields (excluding sig) to
canonical JSON ([RFC8785]) 2. Compute SHA-256 hash of canonical JSON
3. Sign hash with Ed25519 private key 4. Encode signature as base64
5. Add sig field to envelope
*Verification Process*: 1. Extract sig field 2. Remove sig from
envelope 3. Serialize remaining fields to canonical JSON ([RFC8785])
4. Compute SHA-256 hash 5. Verify signature using Ed25519 public
key from from_did
4. Semantic Addresses
4.1. Decentralized Identifiers (DIDs)
Agents MUST have a DID conforming to [W3C.DID].
Nagulapalli Expires 28 May 2026 [Page 6]
Internet-Draft AINP Protocol November 2025
*Supported DID Methods* (Phase 0.1): - did:key: - Self-certified
cryptographic keys - did:web: - Web-based identifiers
4.2. Semantic Address Structure
json { "did": "did:key:z6Mk...", "capabilities": [ { "description":
"Schedule meetings with calendar integration", "embedding": { "b64":
"base64-encoded float32 array", "dim": 1536, "dtype": "f32", "model":
"openai:text-embedding-3-small" }, "tags": ["scheduling",
"calendar"], "version": "1.0.0", "evidence":
"https://credentials.example.com/vc/scheduling" } ], "trust": {
"score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85,
"competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977,
"last_updated": 1728259200000 }, "credentials":
["https://credentials.example.com/vc/scheduling"] }
5. Intent Schemas
AINP defines six core intent types for Phase 0.1. All intents MUST
include: - JSON-LD @context for semantic interoperability - Embedding
(Embedding object; base64 Float32Array inside b64) - Budget
constraints - Semantic payload
5.1. REQUEST_MEETING Intent
*Schema URI*: https://ainp.dev/schemas/intents/request-meeting/v1
json { "@context": "https://ainp.dev/contexts/meeting/v1", "@type":
"RequestMeeting", "version": "1.0.0", "embedding": { "b64":
"base64-encoded Float32Array", "dim": 1536, "dtype": "f32", "model":
"openai:text-embedding-3-small" }, "semantics": { "participants":
["did:key:..."], "duration_minutes": 30, "preferred_times":
["2025-10-07T14:00:00Z"], "location": "virtual", "constraints": {
"timezone": "America/Los_Angeles", "max_latency_ms": 5000,
"min_notice_hours": 24 } }, "budget": { "max_credits": 10,
"max_rounds": 5, "timeout_ms": 30000 } }
5.2. APPROVAL_REQUEST Intent
*Schema URI*: https://ainp.dev/schemas/intents/approval-request/v1
Nagulapalli Expires 28 May 2026 [Page 7]
Internet-Draft AINP Protocol November 2025
json { "@context": "https://ainp.dev/contexts/approval/v1", "@type":
"ApprovalRequest", "version": "1.0.0", "embedding": { "b64": "...",
"dim": 1536, "dtype": "f32" }, "semantics": { "request_type":
"purchase", "description": "Purchase office supplies", "amount": 500,
"currency": "USD", "justification": "Quarterly restock", "deadline":
"2025-10-10T00:00:00Z", "approvers": ["did:key:..."], "threshold": 1,
"constraints": { "requires_attestation": true, "max_latency_ms": 5000
} }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms":
30000 } }
5.3. SUBMIT_INFO Intent
*Schema URI*: https://ainp.dev/schemas/intents/submit-info/v1
json { "@context": "https://ainp.dev/contexts/submit-info/v1",
"@type": "SubmitInfo", "version": "1.0.0", "embedding": { "b64":
"...", "dim": 1536, "dtype": "f32" }, "semantics": { "data_type":
"form", "payload": { "field1": "value1" }, "schema_ref":
"https://example.com/schema.json", "privacy_level": "encrypted",
"retention_policy": { "duration_days": 90, "delete_after": true },
"constraints": { "requires_acknowledgment": true, "max_latency_ms":
5000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
"timeout_ms": 15000 } }
5.4. INVOICE Intent
*Schema URI*: https://ainp.dev/schemas/intents/invoice/v1
json { "@context": "https://ainp.dev/contexts/invoice/v1", "@type":
"Invoice", "version": "1.0.0", "embedding": { "b64": "...", "dim":
1536, "dtype": "f32" }, "semantics": { "invoice_id": "INV-2025-001",
"from": "did:key:...", "to": "did:key:...", "amount": "1000.00",
"currency": "USD", "line_items": [ { "description": "Service fee",
"quantity": 1, "unit_price": "1000.00", "total": "1000.00" } ],
"due_date": "2025-11-01T00:00:00Z", "payment_methods": ["crypto",
"wire"], "constraints": { "requires_escrow": true, "max_latency_ms":
10000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
"timeout_ms": 30000 } }
5.5. FREEFORM_NOTE Intent
*Schema URI*: https://ainp.dev/schemas/intents/freeform-note/v1
json { "@context": "https://ainp.dev/contexts/freeform/v1", "@type":
"FreeformNote", "version": "1.0.0", "embedding": { "b64": "...",
"dim": 1536, "dtype": "f32" }, "semantics": { "subject": "Meeting
notes", "body": "Discussion summary...", "format": "markdown",
"attachments": [ { "url": "https://example.com/doc.pdf", "mime_type":
Nagulapalli Expires 28 May 2026 [Page 8]
Internet-Draft AINP Protocol November 2025
"application/pdf", "size_bytes": 102400, "hash": "sha256:abc123..." }
], "thread_id": "thread-123", "in_reply_to": "msg-456",
"constraints": { "max_latency_ms": 5000 } }, "budget": {
"max_credits": 1, "max_rounds": 1, "timeout_ms": 10000 } }
5.6. REQUEST_SERVICE Intent
*Schema URI*: https://ainp.dev/schemas/intents/request-service/v1
json { "@context": "https://ainp.dev/contexts/service/v1", "@type":
"RequestService", "version": "1.0.0", "embedding": { "b64": "...",
"dim": 1536, "dtype": "f32" }, "semantics": { "service_type":
"plumbing.leak.fix", "geo": { "lat": 37.7749, "lon": -122.4194,
"radiusKm": 10, "zip": "94102" }, "time_window": { "earliest":
"2025-10-08T09:00:00Z", "latest": "2025-10-08T17:00:00Z" },
"constraints": { "eco": true, "access_notes": "Ring doorbell",
"evidence_required": ["photo_before_after"] }, "details": {
"urgency": "high", "description": "Kitchen sink leak" } }, "budget":
{ "max_credits": 20, "max_total": 200, "escrow_required": true,
"max_rounds": 10, "timeout_ms": 60000 } }
6. Negotiation Protocol
6.1. Negotiation Flow
Negotiation MUST follow this state machine:
START -> OFFER -> COUNTER <-> COUNTER -> ACCEPT | | ABORT TIMEOUT | |
REJECT REJECT
6.2. Negotiation Message Structure
json { "negotiation_id": "uuid", "round": 1, "phase": "OFFER",
"proposal": { "price": 100, "latency_ms": 500, "confidence": 0.9,
"privacy": "encrypted", "terms": {} }, "constraints": { "max_rounds":
10, "timeout_per_round_ms": 5000, "convergence_threshold": 0.9 } }
*Negotiation Phases*: - OFFER: Initial offer - COUNTER: Counter-offer
- ACCEPT: Accept proposal - REJECT: Reject and end - ABORT: Abort
negotiation - TIMEOUT: Timeout occurred
6.3. Negotiation Convergence
Implementations MAY auto-accept proposals when convergence threshold
is met:
``` convergence_score = 1 - (abs(offer.price - counter.price) /
max(offer.price, counter.price))
Nagulapalli Expires 28 May 2026 [Page 9]
Internet-Draft AINP Protocol November 2025
if convergence_score >= convergence_threshold: auto_accept() ```
6.4. Timeout Behavior
* *Per-round timeout*: If no response within timeout_per_round_ms,
sender MAY send TIMEOUT message
* *Overall timeout*: If negotiation exceeds max_rounds *
timeout_per_round_ms, MUST terminate with TIMEOUT
6.5. Multi-Party Negotiation
For intents involving multiple agents (e.g., scheduling a meeting
with 5 participants, multi-signature approvals), negotiation MUST
support group consensus mechanisms.
*Group Proposal Structure*: json { "negotiation_id": "multi-abc123",
"phase": "OFFER", "proposal": { "participants": ["did:key:agent-a",
"did:key:agent-b", "did:key:agent-c"], "voting_mechanism":
"majority", "convergence_threshold": 0.75, "terms": {
"preferred_times": ["2025-10-07T14:00:00Z", "2025-10-07T15:00:00Z"],
"duration_minutes": 30 } } }
*Voting Mechanisms*: 1. *Unanimous*: All agents must ACCEPT (default
for high-stakes) 2. *Majority*: More than 50% must ACCEPT 3.
*Weighted*: Votes weighted by trust scores
*Multi-Party Flow*: 1. Fan-out: Send NEGOTIATE(OFFER) to all
participants 2. Collection: Each agent responds with individual
proposal 3. Aggregation: Broker aggregates and computes consensus
score 4. Convergence Check: Compare score to threshold 5. Auto-
accept if converged, else synthesize counter-proposal and repeat 6.
Termination: ABORT after max_rounds or timeout if no consensus
7. Protocol Handshake Sequence
7.1. Five-Step Handshake
1. *ADVERTISE*: Agent publishes capabilities to discovery index
2. *DISCOVER*: Agent queries for matching capabilities
3. *NEGOTIATE*: Agents negotiate terms (OFFER → COUNTER → ACCEPT)
4. *INTENT*: Agent sends intent after successful negotiation
5. *RESULT*: Recipient responds with result
7.2. ADVERTISE Phase
Agent publishes capabilities to discovery index:
Nagulapalli Expires 28 May 2026 [Page 10]
Internet-Draft AINP Protocol November 2025
json { "version": "0.1.0", "msg_type": "ADVERTISE", "id": "550e8400-
e29b-41d4-a716-446655440000", "timestamp": 1728259200000, "ttl":
86400000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
"schema": "https://ainp.dev/schemas/advertise/v1", "qos": {
"urgency": 0.1, "importance": 0.5, "novelty": 0.3, "ethicalWeight":
0.5, "bid": 0 }, "sig": "base64signature...", "payload": {
"capabilities": [ { "description": "Schedule meetings with calendar
integration", "embedding": { "b64": "...", "dim": 1536, "dtype":
"f32" }, "tags": ["scheduling", "calendar"], "version": "1.0.0",
"evidence": "https://credentials.example.com/vc/scheduling" } ],
"trust": { "score": 0.85, "dimensions": { "reliability": 0.9,
"honesty": 0.85, "competence": 0.8, "timeliness": 0.85 },
"decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials":
["https://credentials.example.com/vc/scheduling"] } }
7.3. DISCOVER Phase
Agent queries for capabilities:
json { "version": "0.1.0", "msg_type": "DISCOVER", "id": "660e8400-
e29b-41d4-a716-446655440001", "timestamp": 1728259300000, "ttl":
10000, "trace_id": "trace-def456", "from_did": "did:key:z6Mk...",
"to_query": { "description": "Find agents who can schedule meetings",
"embedding": "base64...", "tags": ["scheduling", "calendar"],
"min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }, "schema":
"https://ainp.dev/schemas/discover/v1", "qos": { "urgency": 0.5,
"importance": 0.7, "novelty": 0.2, "ethicalWeight": 0.5, "bid": 1 },
"sig": "base64signature..." }
Discovery index responds with DISCOVER_RESULT containing matching
agents with similarity scores, trust ratings, and estimated latency.
7.4. ERROR Phase
On error, agent MUST respond with ERROR message:
json { "msg_type": "ERROR", "error_code": "TIMEOUT", "error_message":
"Negotiation timed out", "intent_id": "770e8400-e29b-
41d4-a716-446655440002", "retry_after_ms": 5000 }
*Standard Error Codes*: - INVALID_SIGNATURE - UNAUTHORIZED -
UNSUPPORTED_SCHEMA - TIMEOUT - RATE_LIMIT_EXCEEDED -
INSUFFICIENT_CREDITS - NEGOTIATION_FAILED - ESCROW_REQUIRED -
EVIDENCE_INSUFFICIENT - DUPLICATE_INTENT - AGENT_OFFLINE -
INTERNAL_ERROR
Nagulapalli Expires 28 May 2026 [Page 11]
Internet-Draft AINP Protocol November 2025
7.5. Offline Intent Queueing
When recipient agent is offline or unreachable, broker MAY queue
intents for later delivery instead of immediately failing.
*Queue Behavior*: - TTL enforcement: Intent expires after ttl
milliseconds from original timestamp - Broker SHOULD send ERROR to
sender immediately: error_code: "AGENT_OFFLINE" - ERROR response
SHOULD include retry_after_ms field - Broker MUST NOT queue intents
indefinitely (maximum queue time = ttl)
*Queue Delivery Protocol*: 1. Agent Offline Detection: Broker
detects agent offline 2. Queue Intent: Insert into queue with
expires_at = timestamp + ttl 3. Send ERROR: Notify sender with
AGENT_OFFLINE and retry_after_ms 4. Agent Reconnect: When agent
comes online, broker delivers queued intents in priority order 5.
Delivery Ordering: Process queue as FIFO within each priority level
6. Retry Logic: If delivery fails, increment retry_count and retry
after exponential backoff 7. Expiration Cleanup: Periodically purge
expired intents
8. Security Considerations
8.1. Authentication
* All messages MUST be signed with Ed25519
* Signatures MUST be verifiable using public key from from_did
* Unsigned messages MUST be rejected
8.2. Identity
* Agents MUST have a valid [W3C.DID]
* DIDs MUST be resolvable to DID documents containing public keys
8.3. Rate Limiting
Implementations MUST enforce rate limits: - Default: 100 intents per
minute per agent - Burst: Up to 200 intents in 10-second window -
Discovery queries: 10 per minute per agent
8.4. Replay Protection
Recipients MUST reject duplicate messages with the same (from_did,
id) seen within ttl + 60000ms.
Nagulapalli Expires 28 May 2026 [Page 12]
Internet-Draft AINP Protocol November 2025
8.5. DoS Protection
Implementations MUST: - Validate message signatures before processing
- Enforce TTL (drop expired messages) - Limit negotiation rounds (max
10) - Reject messages exceeding 1MB payload size - Require
attachments by reference (URLs) rather than inlining large binaries
8.6. Replay Protection and Delivery Semantics
* Recipients MUST reject duplicate messages with the same (from_did,
id) seen within ttl + 60000ms
* Implementations MUST allow a clock skew of +/-60000ms when
validating timestamp
* At-least-once delivery is RECOMMENDED; senders MUST use UUID v4
ids and recipients MUST make intent handling idempotent with
respect to id
8.7. Capability Attestations
* Agents advertising capabilities SHOULD provide Verifiable
Credentials (VCs)
* VCs MUST conform to [W3C.VC]
* Discovery indices MAY reject advertisements without VCs
8.8. Timeouts
* *Intent delivery*: 60 seconds default TTL
* *Negotiation per round*: 5 seconds default
* *Overall negotiation*: 30 seconds default
* *Discovery query*: 10 seconds default
8.9. Outlier Detection
Discovery indices SHOULD flag agents with: - Trust score < 0.3 -
Capability embeddings >3 standard deviations from cluster mean
(potential false advertising) - Success rate < 50% over last 100
intents
8.10. Discovery Scalability
*Phase 0.1 Architecture*: Centralized discovery index using
PostgreSQL with pgvector extension for semantic search.
*Vector Indexing*: Discovery indices SHOULD use Approximate Nearest
Neighbor (ANN) indexing for efficient semantic search at scale.
Nagulapalli Expires 28 May 2026 [Page 13]
Internet-Draft AINP Protocol November 2025
*Recommended Algorithm*: HNSW (Hierarchical Navigable Small World) -
*Structure*: Multi-layer graph with hierarchical routing -
*Parameters*: m = 16, ef_construction = 64, ef_search = 40 -
*Distance Metric*: Cosine similarity - *Performance*: ~10ms search
latency for 1M agents, ~99% recall
*Scaling Strategies*: 1. *Vertical Scaling*: Increase HNSW
parameters, use NVMe SSDs, scale PostgreSQL memory 2. *Horizontal
Scaling*: Read replicas, connection pooling (PgBouncer), Redis
caching 3. *Partitioning*: Capability sharding, tag-based routing,
geographic partitioning 4. *Query Optimization*: Pre-filtering, batch
queries, approximate search
*Performance Benchmarks* (Phase 0.1 targets):
+=============+============+============+===============+===========+
| Agent Count | Index Size | Build | Query Latency | Recall@10 |
| | | Time | (p95) | |
+=============+============+============+===============+===========+
| 1K | 2 MB | 5s | 2ms | 99.5% |
+-------------+------------+------------+---------------+-----------+
| 10K | 20 MB | 45s | 5ms | 99.2% |
+-------------+------------+------------+---------------+-----------+
| 100K | 200 MB | 8 min | 12ms | 98.8% |
+-------------+------------+------------+---------------+-----------+
| 1M | 2 GB | 90 | 25ms | 98.0% |
| | | min | | |
+-------------+------------+------------+---------------+-----------+
Table 1
8.11. Lite Mode for Resource-Constrained Agents
For lightweight agents (e.g., IoT devices, mobile, embedded systems),
implementations MAY use a minimal envelope to reduce payload size and
processing overhead.
*Required Fields*: version, msg_type, id, timestamp, from_did,
to_did, sig
*Optional Fields* (MAY be omitted): - ttl (default: 60000ms) -
trace_id (no distributed tracing) - to_query (explicit addressing
only) - capabilities_ref (no VC attestations) - attestations (trust
by DID only) - qos (default: all 0.5, bid 0)
Nagulapalli Expires 28 May 2026 [Page 14]
Internet-Draft AINP Protocol November 2025
*Lite Mode Constraints*: - Lite mode SHOULD NOT be used for high-
stakes intents - Agents using lite mode MUST still provide valid
Ed25519 signatures - Discovery indices MAY reject lite mode
advertisements - Brokers MAY apply lower trust scores to lite mode
agents by default
9. CBOR Encoding (Optional)
For efficiency, implementations MAY use CBOR ([RFC8949]) encoding:
*Key Map (v0.1)*: - 1: version - 2: msg_type - 3: id - 4: timestamp -
5: ttl - 6: trace_id - 7: from_did - 8: to_did - 9: to_query - 10:
schema - 11: qos - 12: capabilities_ref - 13: attestations - 14:
payload - 15: sig
CBOR encoding SHOULD be negotiated during ADVERTISE or DISCOVER
phase.
10. Extensibility
10.1. Custom Intent Types
Agents MAY define custom intent types beyond the core set. Custom
intents MUST: - Include @context with unique URI - Include version
field - Include embedding field - Include budget constraints -
Register schema URI in public registry (future)
10.2. Custom Negotiation Terms
Proposal.terms field allows extensible negotiation parameters.
Common extensions: - privacy_guarantees: ZK proof requirements -
sla_guarantees: Service level agreements - data_retention: Data
retention policies
10.3. Versioning
AINP uses semantic versioning. Breaking changes MUST increment major
version. Phase 0.1 is backwards-compatible within 0.x series.
10.4. Lite Profile (Trusted Networks)
In trusted or closed-network deployments, the following
simplifications are PERMITTED: - Omit capabilities_ref and
attestations if peers are pre-authorized - Prefer JSON-LD for small
payloads; negotiate CBOR for payloads > 4KB - Allow to_query-only
routing within a single administrative domain
Nagulapalli Expires 28 May 2026 [Page 15]
Internet-Draft AINP Protocol November 2025
Nodes MUST still sign messages, enforce TTLs, and implement replay
protection.
11. Success Metrics
11.1. Route Success Rate
route_success_rate = (intents_delivered_correctly /
total_intents_sent) × 100%
*Target (Phase 0.1)*: >=95%
11.2. Latency (p95)
95th percentile time from INTENT sent to RESULT received.
*Target (Phase 0.1)*: <=2000ms
11.3. Negotiation Completion Rate
negotiation_completion_rate = (negotiations_accepted /
total_negotiations) * 100
*Target (Phase 0.1)*: >=80%
11.4. False Route Rate
false_route_rate = (intents_misrouted / total_intents_sent) * 100
*Target (Phase 0.1)*: <=5%
11.5. Abuse Resilience
Detection rate of: - DoS attacks (>1000 requests/min from single
agent) - Sybil attacks (multiple DIDs from same source) - False
capability advertising (capability mismatch >0.5 cosine distance)
*Target (Phase 0.1)*: >=90% detection rate
12. IANA Considerations
This document has no IANA actions.
13. References
13.1. Normative References
Nagulapalli Expires 28 May 2026 [Page 16]
Internet-Draft AINP Protocol November 2025
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[W3C.DID] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July
2022, <https://www.w3.org/TR/did-core/>.
[W3C.VC] W3C, "Verifiable Credentials Data Model v1.1", 3 March
2022, <https://www.w3.org/TR/vc-data-model/>.
13.2. Informative References
[Ed25519] Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B.
Yang, "High-speed high-security signatures", 26 September
2011, <https://ed25519.cr.yp.to/>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
Author's Address
Eswara Prasad Nagulapalli
Servesys Labs
Email: contact@servsys.com
Nagulapalli Expires 28 May 2026 [Page 17]