MQTT for AI Agents: A Governed Event Bus for the Physical World

An AI agent can interpret telemetry, plan a response, and call tools. A device network has a different set of concerns: intermittent links, constrained clients, topic permissions, delivery guarantees, and commands that may affect the physical world.

MQTT is a useful boundary between those systems. It provides a common event plane for telemetry and commands while keeping device connectivity out of the agent runtime. It does not make an agent safe by itself. Safety comes from the policy, validation, and approval layers around the broker.

The reference architecture

A production flow usually has five parts:

1. Devices and gateways publish telemetry and state to MQTT topics.
2. The broker authenticates clients and enforces publish and subscribe policy.
3. An ingestion service validates payloads, enriches context, and exposes a narrow event stream to the agent.
4. The agent proposes an action through a typed tool rather than publishing arbitrary MQTT messages.
5. A command service checks policy, approval state, freshness, and device capability before publishing.

This separation prevents prompt content from becoming a broker credential or topic filter.

device -> MQTT broker -> validated event -> agent
agent -> typed tool -> policy and approval -> MQTT command -> device

Separate observation from control

Give observation and control different topics, identities, and permissions.

sites/{siteId}/devices/{deviceId}/telemetry
sites/{siteId}/devices/{deviceId}/state
sites/{siteId}/devices/{deviceId}/commands/request
sites/{siteId}/devices/{deviceId}/commands/result

The service that supplies context to the agent may subscribe to telemetry. It should not automatically inherit permission to publish commands. The command executor should have the narrowest publish scope possible and no ability to edit its own policy.

Turn commands into typed operations

Do not expose a generic tool such as mqtt_publish(topic, payload) to the model. Define operations around business intent:

{
  "operation": "set_temperature_target",
  "deviceId": "chiller-07",
  "targetCelsius": 6,
  "reason": "Reduce deviation from the approved range",
  "requestId": "req_01J..."
}

The command service resolves the destination topic, validates the target range, verifies the device capability, and creates an audit record. The agent never chooses a wildcard topic or embeds a credential.

Add an approval boundary by consequence

Not every action needs a human, but every action needs an explicit consequence class.

Physical systems must retain local safety limits. A cloud agent should never be the only protection against an unsafe actuator command.

Make every command expire

An instruction can become dangerous when delivered after its context is stale. Include:

• a unique request ID;
• issued and expiry timestamps;
• expected device state or version;
• the initiating principal;
• the policy decision and approval record;
• an idempotency key.

MQTT 5 message expiry helps prevent late delivery, but the device should still reject expired or out-of-sequence commands.

Treat responses as evidence, not certainty

A successful MQTT publish only confirms the broker accepted a message according to the chosen QoS flow. It does not prove the device performed the action.

Use a separate result topic with a correlation ID:

{
  "requestId": "req_01J...",
  "status": "applied",
  "deviceStateVersion": 1843,
  "observedAt": "2026-07-27T09:30:00Z"
}

The workflow can then distinguish accepted, delivered, applied, rejected, expired, and timed-out states.

Operational controls that matter

Before connecting an agent to MQTT:

• issue unique service identities and rotate credentials;
• allow-list exact topic patterns per tool;
• validate payloads against versioned schemas;
• cap command rate and concurrency per device;
• log proposals, approvals, policy decisions, publishes, and results;
• test duplicate delivery, reconnects, stale retained state, and partial failure;
• provide a kill switch outside the agent path.

Start with read-only telemetry and offline recommendations. Add bounded command execution only after the audit trail and failure handling are observable.

Read the MQTT security guide for identity and authorization design, the MQTT protocol overview for sessions and delivery behavior, and MQTT vs Kafka when the agent also needs durable event replay.