# KubeMQ Aiway (/aiway)



**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 [#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 [#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.

<Mermaid
  chart="`
graph LR
A2A[&#x22;A2A HTTP gateway&#x22;]
GRPCCLIENT[&#x22;gRPC / REST clients&#x22;]
MCP[&#x22;MCP host<br/>(LLM)&#x22;]

subgraph FABRIC[&#x22;KubeMQ Aiway · the AI Agents Fabric&#x22;]
  DISC[&#x22;Discovery<br/>+ Registry&#x22;]
  BRIDGE[&#x22;Agent Bridge<br/>(per agent)&#x22;]
  TOOLS[&#x22;MCP tools<br/>+ bridge&#x22;]
  RELAY[&#x22;Streaming relay<br/>(SSE)&#x22;]
end

BROKER[&#x22;Message Broker&#x22;]
AGENT[&#x22;Plain-HTTP agents<br/>/skills…&#x22;]

A2A --> DISC
GRPCCLIENT --> DISC
MCP --> TOOLS
DISC --> BROKER
TOOLS --> BROKER
BROKER --> BRIDGE
BRIDGE -. &#x22;HTTP POST&#x22; .-> AGENT
AGENT -. &#x22;live task events&#x22; .-> RELAY

class A2A,MCP client
class GRPCCLIENT client
class DISC,BRIDGE,TOOLS,RELAY aiway
class BROKER broker
class AGENT external
`"
/>

*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`.

<Callout type="info">
  The MCP **agent-bridge tools** (`agent_list`, `agent_info`, `agent_send`, `agent_query`,
  covered under [MCP](/aiway/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.
</Callout>

## One fabric, three planes [#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 [#two-doors-in]

<Cards>
  <Card title="AI Agents (A2A)" href="/aiway/a2a" description="A JSON-RPC 2.0 gateway and agent registry that routes requests between AI agents over plain HTTP — no SDK on the agent." />

  <Card title="MCP" href="/aiway/mcp" description="Expose KubeMQ messaging and the agent fabric as Model Context Protocol tools for Claude and other LLM hosts." />
</Cards>

## The enterprise envelope [#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](/connectors/concepts/shared-http-server) (port
9090\) and inherit its unified middleware. The shared foundations are documented once
under Connectors:

<Cards>
  <Card title="Shared HTTP server" href="/connectors/concepts/shared-http-server" description="Port 9090, the middleware chain, the enable model, and reserved channel prefixes." />

  <Card title="Auth & security" href="/connectors/reference/auth-and-security" description="JWT Bearer auth, CORS, origin validation, and TLS/mTLS across every gateway." />

  <Card title="Observability" href="/connectors/concepts/observability" description="Prometheus metrics, OpenTelemetry tracing, and the web AI dashboard." />
</Cards>

## Next steps [#next-steps]

<Cards>
  <Card title="Tutorial" href="/aiway/tutorial" description="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." />

  <Card title="Use cases" href="/aiway/use-cases" description="Where Aiway is uniquely strong: zero-SDK onboarding, LLM orchestration, streaming tasks, capability routing, and multi-tenant directories." />

  <Card title="Getting started (A2A)" href="/aiway/a2a/getting-started" description="Register an agent and send your first message/send in under 10 minutes." />

  <Card title="Getting started (MCP)" href="/aiway/mcp/getting-started" description="Connect an MCP client, list the tools, and drive messaging and agents from an LLM host." />
</Cards>