XMPP Agent Gateway protocol proposed for AI agent discovery and invocation

The XMPP Agent Gateway specification defines a complete protocol for hosting, discovering, and executing AI agents on federated XMPP infrastructure. At its core, each agent is represented by a bare JID (a stable, routable XMPP address) and an immutable versioned manifest—a JSON document that describes the agent's capabilities and its tools. Tools are named, callable capabilities compatible with the MCP Tool data model, and their schemas are published separately from discovery responses to avoid flooding directory listings with large JSON documents.

The protocol supports a range of practical workflows. A user operating an XMPP client can discover available agents by querying a gateway's endpoint directory, then inspect a selected endpoint's metadata, retrieve tool schemas, and invoke a tool asynchronously. The invocation produces a durable task with a unique ID, assigned before tool execution, ensuring that the caller and target can reliably correlate work even if network messages are lost. Tasks progress through defined lifecycle states (pending, running, input_required, cancelling, completed, failed, cancelled), and callers can cancel a running task, recover interrupted work by querying task state, or supply interactive input if a tool pauses waiting for human feedback.

An important design feature is deterministic correlation and terminal semantics. When a caller loses an admission acknowledgment and retries the same invocation using the same replay fingerprint during an advertised replay window, the target returns the original accepted task without executing the tool a second time. Once a task reaches a terminal state (completed, failed, or cancelled), later tool output cannot overwrite the result, eliminating ambiguity about which execution's outcome is authoritative. Idempotent replay and exactly-once semantics are achieved through message IDs, fingerprints, and atomic commitment at the gateway boundary.

Federated access is denied by default. A remote requester contacting a gateway or endpoint across an authenticated server-to-server XMPP link receives the same safe error (item-not-found) whether the endpoint is hidden, nonexistent, or simply forbidden to that principal. An operator can explicitly authorize visibility and invocation for trusted remote domains or principals, but authentication alone grants neither. This design prevents information leakage about agent availability in multi-tenant or inter-organizational scenarios.

The specification is modular. A gateway can implement a Core Directory profile (endpoint discovery and inspection), optionally add a Jabber Search Compatibility profile (legacy directory search), and separately adopt MCP bridging (mapping between XMPP and MCP Tool semantics) or human messaging (optional natural-language conversation separate from task execution). A bridge that implements MCP mapping preserves tool schemas, annotations, and execution metadata where the two protocols align, and explicitly reports semantic loss when XMPP's task model or MCP's capabilities cannot be represented exactly. The reference implementation, Openfire, was used during development and integration testing. The protocol is designed for future extension to additional MCP capabilities without requiring redefinition of the base specification.

The specification emerged from real-world multi-agent orchestration challenges, addressing gaps that HTTP services and MCP servers do not fill in isolation. By anchoring agent identity to XMPP's bare JID model, the protocol ensures stable, routable addressing across deployments. The design decision to keep XMPP addressing, routing, tenant identity, and task correlation authoritative at the gateway boundary—rather than delegating them to an LLM or tool runtime—reflects a security-first approach to multi-agent systems. The optional conformance profiles allow incremental adoption: a deployment can support Core Directory discovery without implementing search, or add MCP bridging only if needed, reducing barrier to entry for organizations beginning with agent orchestration.

Federation is treated as a security boundary by default. This contrasts with the openness of classic XMPP presence and messaging; the protocol explicitly denies visibility and invocation across server-to-server routes unless an operator grants trust to a specific remote domain or principal. Combined with error handling that treats denied, hidden, and nonexistent endpoints identically—and applies timing defenses and rate limits—this design mitigates information leakage in federated deployments where agent availability or capability must remain private.

No comments yet. Be the first to share your thoughts!