MQTT.Agent

FAQ

Is MQTT.Agent a framework?

No. It's a substrate, a wire-level protocol bundle. Frameworks (orchestration, agent runtimes, decision graphs) live one layer above. MQTT.Agent is what those frameworks talk over when their agents are on different hosts.

Does MQTT.Agent replace MCP?

No. MCP-over-stdio (Anthropic's reference) is still the right choice when your tool runs as a subprocess next to its caller: editors, CLI tools, local-only setups. The MCP over MQTT part of MQTT.Agent covers the case where tool servers are network services that need to be called from multiple hosts, replicated, or load-balanced.

The two are complementary, not competing. The semantics are the same; the transport is different.

Is MQTT.Agent just one company's project?

No. The specification is public (CC-BY-4.0). The reference SDKs are MIT. Any MQTT 5 broker can carry the wire format. CloudSignal is the current steward; broader contribution and governance are intended.

Has MQTT.Agent been ratified by MCP or A2A?

No. The specification is at draft v0.1; neither the Anthropic Model Context Protocol working group nor the Linux Foundation Agent2Agent project has formally accepted it. Formal recognition is on the roadmap through two sequenced paths:

  • A2A first, as a Custom Protocol Binding under Linux Foundation governance. The binding lifecycle (experimental-cpb-{name} to TSC vote to official cpb-{name}) is purpose-built for new transports, and the TSC composition is enterprise-integration heavy where MQTT is established.
  • MCP after A2A reaches experimental status, as a Specification Enhancement Proposal on the Extensions track. MCP's 2026 roadmap currently scopes transport work to evolving Streamable HTTP rather than admitting new transports, so the SEP path is slower and materially benefits from the A2A experimental binding existing first as adoption evidence.

The implementation is operational today - reference SDKs publish to npm, conforming MQTT 5 brokers carry the wire format - but readers evaluating adoption should treat MQTT.Agent as a working draft, not a ratified standard. The v0.x window permits breaking changes between minor releases; pin to an exact spec and SDK version in production.

Can I run this on Mosquitto / EMQX / HiveMQ?

Yes. The protocol is broker-agnostic at v0.1. You'll get the messaging semantics on any conforming MQTT 5 broker.

You won't get identity-bound enforcement unless your broker implements claim-based ACL. That's a separate companion document (forthcoming, deferred to v0.2). Without identity enforcement, the wire still works; you just lose the impersonation-resistance guarantee.

Why MQTT?

Because the problem MQTT.Agent solves (multi-host, identity-aware, presence-aware, retained-state messaging) is what MQTT was designed for.

We considered REST, in-process calls, MCP-over-stdio, and various ad-hoc buses for our own multi-agent stacks; each broke at the boundary of the same five problems listed on the home page. MQTT 5 with Response Topic, Correlation Data, Will Delay Interval, retained messages, and shared subscriptions handles the four hardest parts of distributed agent comms out of the box.

What's the relationship to Anthropic's MCP and Google's A2A?

Sibling specs. Complementary positioning.

  • MCP (Anthropic) defines tool-server semantics over stdio.
  • A2A (Google) defines agent-to-agent semantics over HTTP.
  • MQTT.Agent defines both A2A over MQTT and MCP over MQTT.

The intent is co-citation: implement MCP-over-stdio for editor-local tools and MCP-over-MQTT for shared tool servers; implement A2A-over-HTTP where it fits and A2A-over-MQTT where it fits. The acknowledgments section of the spec credits both.

What about EMQX's MQTT.AI?

MQTT.AI is a broader framing: "MQTT for AI workloads" generally. MQTT.Agent is narrower and more specific: agent-to-agent and agent-to-tool comms.

The two are concept-adjacent and not in conflict; both leverage MQTT for AI use cases. They differ in scope and posture: MQTT.AI is a vendor's product umbrella; MQTT.Agent is an open specification with reference implementations.

When will the spec stabilize?

The goal is v1.0 after 4 - 6 weeks of public feedback in the v0.x window. Breaking changes are possible during v0.x; they will be documented in CHANGELOG.md. Production users should pin to an exact spec version.

What's not in v0.1?

  • The companion ACL profile. Identity-bound enforcement is described conceptually in the Security considerations section but not normatively specified. The companion document is the next deliverable.
  • Python SDK parity. Reference SDKs are Node-only today. Python is on the roadmap.
  • Multi-broker / regional failover. Single-broker topology only at v0.1.
  • Authorization grammar / claim-binding rules. These belong to the ACL profile.

How do I provide feedback?

A public spec repository with issue tracker and an RFC process is being prepared. Until it lands, send feedback to efi@cloudsignal.io. Substantive changes to normative sections will be discussed in writing before being merged.

Where does the spec live, exactly?

  • mqtt-agent.dev is the rendered spec, FAQ, and docs - currently the canonical readable source.
  • A public spec repository (SPEC.md, LICENSE, issue tracker, submission packaging) is being prepared as a separate deliverable.
  • Each reference SDK package on npm bundles a copy of the spec text so implementers have it offline.