KubeMQ Aiway
KubeMQ Aiway is an AI Agents Fabric — register, discover, invoke, and stream AI agents over an enterprise message broker; A2A and MCP are the two doors in.
KubeMQ Aiway is an AI Agents Fabric — a switchboard that lets AI agents and AI applications find each other, talk to each other, and stream results in real time, with the reliability of an enterprise message broker underneath. A2A and MCP are the two doors into the same fabric: register an agent, discover it by capability, invoke it synchronously or as a live stream, and orchestrate the whole thing from an LLM.
What is KubeMQ Aiway
Aiway is a switchboard for AI agents. Agents register what they can do, callers find them by capability, and the fabric routes every call — synchronous or streamed — over an enterprise message broker. KubeMQ does the discovery, routing, protocol bridging, streaming, security, high availability, and observability so that no caller and no agent has to.
The agents themselves stay plain HTTP services — no KubeMQ SDK, no broker library, no protobuf, no special runtime. An agent is just an HTTP server that speaks JSON-RPC 2.0 (and, optionally, Server-Sent Events). Aiway bridges the broker to that endpoint for you, so you can wrap an existing internal microservice as a first-class AI agent in minutes.
Two doors open into the same fabric:
- A2A (Agent-to-Agent) — agents register their endpoint and capabilities; any caller discovers them by capability and invokes them, synchronously or as a live stream.
- MCP (Model Context Protocol) — LLM hosts (Claude Desktop, IDEs, agent frameworks) plug in over the open MCP standard and gain both messaging and agent orchestration through a single endpoint.
The big picture
A caller — over A2A HTTP, gRPC/REST, or an MCP host — reaches the fabric, which discovers the target agent, bridges the call to its plain-HTTP endpoint, and relays the response (or a live SSE stream) back. The agents never touch the broker directly.
Callers reach Aiway over A2A, gRPC/REST, or MCP; the Agent Bridge POSTs to each agent's plain-HTTP URL and the streaming relay carries live events back.
The Agent Bridge is the per-agent virtual subscriber that translates broker messages
into HTTP calls to your agent (and relays responses and SSE streams back). It is why
agents need zero KubeMQ dependency: the bridge does all the broker and protocol
translation, so the agent only ever sees an HTTP POST.
The MCP agent-bridge tools (agent_list, agent_info, agent_send, agent_query,
covered under MCP) invoke agents through this same Agent Bridge —
same concept at two layers, not two meanings. The tools are the LLM-facing door; the
Agent Bridge is the per-agent connector they (and A2A callers) route through.
One fabric, three planes
Aiway is not "A2A plus a separate MCP server." It is one fabric with three planes that share the same core and compose freely — an LLM over MCP can enqueue durable work and call an A2A agent in the same session, and a gRPC backend can invoke the same agent an LLM just used.
| Plane | Door | What it does |
|---|---|---|
| Agent plane | A2A | Agents register, get discovered by capability, get invoked, and stream results. |
| LLM plane | MCP | LLM hosts discover and drive both agents and messaging through one endpoint. |
| Messaging plane | KubeMQ core | Durable queues, pub/sub events, a persisted/replayable event log, and RPC (commands/queries) — the same primitives the MCP messaging tools expose. |
Two doors in
AI Agents (A2A)
A JSON-RPC 2.0 gateway and agent registry that routes requests between AI agents over plain HTTP — no SDK on the agent.
MCP
Expose KubeMQ messaging and the agent fabric as Model Context Protocol tools for Claude and other LLM hosts.
The enterprise envelope
What makes Aiway production-grade rather than a demo is the envelope around both doors — the same auth, HA, guardrails, and observability that the rest of KubeMQ runs on:
- Security — token-based authentication, per-agent ownership (only the registrant can modify or remove an agent), origin validation, and TLS / mutual-TLS.
- High availability — the agent registry is replicated to every node, so an agent registered on one node is reachable and discoverable cluster-wide; if a node fails, its agents expire and re-register elsewhere and the roster self-heals.
- Guardrails & backpressure — TTL liveness, default and max request timeouts, a max-agents ceiling, a per-agent concurrency cap, a max agent-response size, and traffic gating that rejects calls when the core isn't ready instead of hanging.
- Observability — per-agent request, error, latency, and active-stream metrics (Prometheus + a durable per-agent store) plus a live operations dashboard, so you can govern an entire agent fleet.
Both doors run on the shared HTTP server (port 9090) and inherit its unified middleware. The shared foundations are documented once under Connectors:
Shared HTTP server
Port 9090, the middleware chain, the enable model, and reserved channel prefixes.
Auth & security
JWT Bearer auth, CORS, origin validation, and TLS/mTLS across every gateway.
Observability
Prometheus metrics, OpenTelemetry tracing, and the web AI dashboard.
Next steps
Tutorial
Build the fabric end-to-end: register a plain-HTTP agent, discover and invoke it, stream live results, then orchestrate it from an LLM over MCP.
Use cases
Where Aiway is uniquely strong: zero-SDK onboarding, LLM orchestration, streaming tasks, capability routing, and multi-tenant directories.
Getting started (A2A)
Register an agent and send your first message/send in under 10 minutes.
Getting started (MCP)
Connect an MCP client, list the tools, and drive messaging and agents from an LLM host.
Was this page helpful?