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.

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.