# Use cases (/aiway/use-cases) New to Aiway? Start with the [overview](/aiway). 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](/aiway/a2a/guides/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](/aiway/a2a/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](/aiway/a2a/error-handling). ## Onboarding & orchestration [#onboarding--orchestration] ### Zero-SDK agent onboarding [#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](/aiway/tutorial). ### LLM as orchestrator over a real agent fleet [#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](/aiway/mcp/tools/agent-bridge). ### Polyglot, mixed-protocol orchestration [#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](/aiway/a2a/sync-messaging). ## Real-time & long-running work [#real-time--long-running-work] ### Real-time long-running tasks with live progress [#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)](/aiway/a2a/streaming). ### Human-in-the-loop and approval flows [#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](/aiway/a2a/scenarios/streaming-task-pipeline). ### Ephemeral, on-demand agents [#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](/aiway/a2a/registry). ## Routing & multi-tenancy [#routing--multi-tenancy] ### Capability-based dynamic routing [#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](/aiway/a2a/scenarios/multi-agent-gateway). ### Multi-tenant agent directory [#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](/aiway/a2a/registry). ### Distributed, multi-region agent mesh [#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](/aiway/a2a/architecture). ## Reliability & governance [#reliability--governance] ### Resilient, retry-aware agent calls [#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](/aiway/a2a/error-handling). ### Secure enterprise agent gateway [#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](/aiway/a2a/guides/authentication). ### Governed agent fleet [#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](/aiway/a2a/configuration) for the limits that govern a fleet. ## Hybrid pipelines & safe LLM access [#hybrid-pipelines--safe-llm-access] ### Agents plus durable messaging [#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](/aiway/mcp/tools/events). ### MCP tool gateway for safe enterprise access [#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](/aiway/mcp/tools/queues). ## Next steps [#next-steps]