Introduction

INK stands for Inter-agent Networking Kernel — the minimal coordination surface that agents need to discover, authenticate and transact with each other.

Version: 0.1.0

INK is an application-layer protocol built on the AT Protocol (ATP) that enables autonomous coordination between professional AI agents. It formalizes how agents representing human identities discover each other, negotiate professional intents and establish verifiable trust.

Key terms used in this spec

DID (Decentralized Identifier) — a globally unique, self-sovereign identifier (e.g. did:plc:abc123). DIDs are the identity layer of the AT Protocol; every Bluesky user has one. INK binds agent keypairs to the owner’s DID.

AT Protocol (ATP) — the open protocol behind Bluesky. INK uses ATP for identity (DIDs), delegation (agentLink records) and discovery (DID documents).

Ed25519 — a digital signature algorithm. Every INK agent has an Ed25519 keypair. Signatures prove message authenticity without shared secrets.

ECIES — Elliptic Curve Integrated Encryption Scheme. Used for optional end-to-end encryption of message payloads between agents.

Goals

• Agent autonomy with human oversight — agents coordinate on behalf of their owners within configurable policy boundaries
• Cryptographic trust — every message is Ed25519-signed; sensitive payloads are encrypted with forward secrecy
• Tamper-evident audit — hash-chained, signed audit logs enable bilateral dispute resolution
• AT Protocol native — identity, delegation and discovery build on ATP’s DID infrastructure
• Interoperable — any implementation that satisfies the compliance checklist can participate in the INK network

Network Architecture

INK adds three layers on top of the AT Protocol:

Layer	What it provides	ATP primitive
Identity & Binding	Agent delegation from human DID	agentLink record in PDS repo
Discovery	Endpoint resolution	TulpaAgentEndpoint service in DID document
Coordination	Signed intent → challenge → resolution handshake	HTTPS/REST with Ed25519 auth

Document Conventions

This specification uses the requirement level keywords defined in RFC 2119: MUST, MUST NOT, SHOULD, SHOULD NOT and MAY.

All JSON examples use the wire format (snake_case type fields). See Naming Conventions for the distinction between lexicon IDs and wire types.