New to Aiway? Start with the overview.

KubeMQ Aiway is an AI Agents Fabric: agents register, callers discover them by capability, and anyone invokes them — synchronously or as a live stream — over an enterprise message broker. The scenarios below show where that fabric is uniquely strong, grouped by the problem they solve. Each one names the scenario, how Aiway delivers it, and why it is hard to get this cleanly any other way.

A few terms recur:

Agent Bridge — the per-agent virtual subscriber KubeMQ spawns for each registered agent. It translates broker messages into HTTP POSTs to your agent's URL and relays the response (or live stream) back, which is why agents need no KubeMQ SDK. See Building agents.
Skill tags — the capability labels (tags[]) an agent advertises on each skill, used to discover agents by what they can do rather than by URL. See the Agent registry.
The transport-vs-application error split — Aiway returns Executed: false when the agent never processed the request (unreachable, timeout, oversized response), so it is safe to retry; an Executed: true response with a JSON-RPC error means the agent ran and returned an error, so don't blind-retry. See Error handling.

Onboarding & orchestration

Zero-SDK agent onboarding

Scenario: Turn an existing internal HTTP microservice — a Python summarizer, a Go OCR service, a Node scraper — into a first-class AI agent in minutes.

How: the service stays a plain HTTP server. It registers an Agent Card; the Agent Bridge does all protocol translation.

Why Aiway: no KubeMQ client library, broker SDK, protobuf, or special runtime in the agent — most frameworks force an SDK and a specific language, while Aiway onboards any HTTP service in any stack. Walk it end-to-end in the Tutorial.

LLM as orchestrator over a real agent fleet

Scenario: An LLM host (Claude Desktop, an IDE, an agent framework) plans a task, discovers the right specialist agents, invokes them, and persists intermediate results — all from one MCP connection.

How: agent_list / agent_info to discover, agent_send / agent_query to invoke, events_store_publish to log, queue_send to hand off — same session, same fabric.

Why Aiway: the LLM gets messaging and agent orchestration through one open-standard endpoint, with enterprise auth and high availability — no glue code, no custom tool server per agent. See the MCP agent-bridge tools.

Polyglot, mixed-protocol orchestration

Scenario: A gRPC backend, a REST web app, and an LLM all call the same agent during one workflow.

How: every transport — the A2A HTTP gateway, gRPC, REST, the MCP bridge — converges on the same Agent Bridge path.

Why Aiway: one agent, callable from every protocol your stack already speaks, with no per-protocol adapters or duplicated endpoints. See Synchronous messaging.

Real-time & long-running work

Real-time long-running tasks with live progress

Scenario: A caller kicks off a multi-minute job — document generation, transcode, deep research, multi-step reasoning — and watches task.status and task.artifact events stream in with a progress bar.

How: message/stream opens an SSE relay with keepalive, idle timeout, and auto-cancel when the caller disconnects.

Why Aiway: streaming, cancellation, and backpressure (per-agent concurrency cap, response-size limits) are built in — production streaming, not a fragile long-poll. See Streaming (SSE).

Human-in-the-loop and approval flows

Scenario: An agent streams a draft, a human reviews it, and on approval the workflow resumes or hands off to another agent.

How: streaming for live drafts; durable queues or persisted events park the task while it awaits a decision; a second agent invocation continues the work.

Why Aiway: real-time streaming and durable hand-off coexist on one fabric, so long-lived, human-gated workflows don't need a separate workflow engine. See the Streaming task pipeline.

Ephemeral, on-demand agents

Scenario: Spin up specialist agents on demand — per job, per tenant — have them register, take work, then disappear, without callers caring.

How: an agent registers on start, heartbeats while alive, and TTL-expires when gone; discovery and routing always reflect the live set.

Why Aiway: the self-healing, capability-indexed roster makes transient agents first-class — callers always see only what is actually available right now. See the Agent registry.

Routing & multi-tenancy

Capability-based dynamic routing

Scenario: "Find an agent that can translate-legal for de-DE, prefer the lowest-latency one, call it, and fall back to another if it errors."

How: discover via GET /agents?skill_tags=… (or agent_list), select at runtime, invoke, and use the transport-vs-application error split to fail over.

Why Aiway: agents are addressed by capability, not by URL — new agents appear in discovery the moment they register, and the routing logic never changes. See the Multi-agent gateway.

Multi-tenant agent directory

Scenario: Multiple teams publish agents into one shared directory; each team can manage only its own; everyone can discover and call them, subject to authorization.

How: ownership is bound to the registering identity (only the owner can modify or deregister; a blank owner fails closed); discovery is open, invocation is authenticated.

Why Aiway: a built-in, fail-closed ownership model turns a shared registry into a safe internal agent marketplace, without bespoke RBAC plumbing. See the Agent registry.

Distributed, multi-region agent mesh

Scenario: Agents run close to data or users in different nodes or regions; callers anywhere reach any agent.

How: the registry replicates cluster-wide; agents register on a local node; the cluster routes calls to the owning node; on node loss, agents re-register elsewhere.

Why Aiway: location transparency and a self-healing registry come from the broker, so callers never track where an agent physically runs. See the A2A architecture.

Reliability & governance

Resilient, retry-aware agent calls

Scenario: A flaky agent or a slow network shouldn't corrupt a workflow, and the orchestrator needs to know what failed.

How: the Executed: false (transport, safe-retry) vs Executed: true plus error (application, don't blind-retry) split, with specific A2A error codes and per-agent timeouts.

Why Aiway: the fabric encodes retry-safe semantics at the protocol level, so orchestration logic gets clean, correct failure signals for free. See Error handling.

Secure enterprise agent gateway

Scenario: Expose agents to partners or teams behind authentication, mutual TLS, and origin controls, and reject traffic when the platform is degraded.

How: the shared security chain — auth, ownership, TLS/mTLS, trusted origins, traffic gating — wraps every agent call.

Why Aiway: an enterprise security envelope is built into the fabric, so you don't bolt a gateway in front of every agent. See Agent authentication.

Governed agent fleet

Scenario: An ops team needs per-agent traffic, error rates, latency, active streams, and a live roster across a large fleet, surviving restarts.

How: per-agent metrics (Prometheus plus a durable store) and a live dashboard; TTL and heartbeat keep the roster honest.

Why Aiway: fleet-grade observability and lifecycle are native — not something you assemble from logs after the fact. See the A2A configuration for the limits that govern a fleet.

Hybrid pipelines & safe LLM access

Agents plus durable messaging

Scenario: An agent's streamed artifacts are written to a persisted, replayable event log; downstream agents and classic consumers read from it; failed work lands in a dead-letter queue for human review.

How: mix events_store_publish / events_store_read (or queues with a dead_letter_queue) with agent invocation, on one fabric.

Why Aiway: agents and enterprise messaging are the same substrate, so you compose durable, replayable, at-least-once pipelines with AI agents inside them — no integration layer. See the Events Store tools.

MCP tool gateway for safe enterprise access

Scenario: Give any MCP-speaking LLM safe, governed access to enterprise messaging — queues, events, persisted logs, RPC — without handing it the raw broker.

How: the MCP messaging tools expose curated operations with input schemas, reserved-channel protection, timeouts, and auth.

Why Aiway: the LLM gets a bounded, schema'd, authenticated surface onto real enterprise messaging — a controlled blast radius, not a firehose. See the Queue tools.

Use cases