Without a gateway
- Each channel needs its own agent integration
- Sessions and identities drift between entry points
- Tools and permissions are configured in several places
- Operators cannot see the whole agent system
Multi-channel agent operations
ADK Gateway connects messaging channels, web applications, and other agents to a team of ADK-Rust agents. It routes each request, restores the right context, applies operating policy, and gives developers one place to see and control the system.
People and systems
Identity · Router · Runner
Agent team
Why a gateway?
An ADK-Rust agent can reason, call tools, and stream events. A real deployment also has to answer practical questions: Where do requests arrive? Which agent should receive them? Whose session should be restored? What is that agent allowed to do?
ADK Gateway provides that shared operating layer. Telegram, Slack, WhatsApp, Discord, Matrix, webhooks, and agent-facing web requests enter through adapters. The gateway turns them into one message shape, applies access rules, routes them to a system or specialist agent, and delivers progress back through the original channel.
The gateway does not merge every agent into one assistant. Developers can keep research, support, operations, and coding agents separate—with different models, tools, workspaces, permissions, and channel bindings—while operating them through one control surface.
Architecture
Read the architecture from left to right. Requests enter through human or agent channels. Identity and routing decide where they belong. ADK-Rust runs the selected agent with its own state and capabilities. The control plane observes every layer without becoming part of the conversation.
Entry points
Trust edge
Gateway runtime
Agent team
Capabilities
Operator control plane
Configure, approve, observe, recover, and audit the complete request path.
Follow one request
The same flow applies to every supported channel. Only the adapter and delivery format change; routing, sessions, agent execution, policy, and evidence remain shared.
Telegram, Slack, WhatsApp, Discord, Matrix, and webhooks arrive in different formats. Each adapter turns them into the same inbound message contract.
Pairing rules, allow lists, group mention policy, multi-user identity, rate limits, and optional JWT checks run before the request reaches an agent.
Routing checks the channel, account, and person or group. The most specific match wins; the system agent is the final fallback.
The Runner attaches the correct session, user context, memory, cancellation state, and model fallback chain before agent execution begins.
The selected agent can use its Rust tools, MCP servers, knowledge, workflows, or an approved ACP coding agent. Role policy limits what it can call.
Typed events become typing indicators, progress messages, images, or a final response. Metrics, logs, task history, and audit events explain what happened.
Routing in Rust
A developer can bind an agent to a whole channel, one account on that channel, or a specific person or group. The router checks the most specific rule first and falls back predictably.
The example condenses the source implementation for readability. The repository tests exact, account-level, channel-level, legacy, and default routing behavior.
/// Most-specific binding wins.
pub fn resolve_agent(&self, message: &InboundMessage) -> &str {
// 1. channel + account + person or group
if let Some(agent) = self.exact_binding(message) {
return agent;
}
// 2. channel + account, then channel-only
if let Some(agent) = self.account_binding(message)
.or_else(|| self.channel_binding(message))
{
return agent;
}
// 3. configured legacy rules, then the system agent
self.legacy_binding(message)
.unwrap_or(&self.default_agent_id)
}{
"agent": {
"model": {
"primary": "openai/gpt-5.4-mini",
"fallbacks": ["openai/gpt-5.4-nano"]
}
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "${TELEGRAM_BOT_TOKEN}",
"dmPolicy": "pairing"
}
},
"user_agents": [{
"id": "support",
"name": "Customer support",
"tools": ["order_lookup", "refund_request"],
"channel_bindings": [{ "channel_type": "telegram" }],
"role": {
"allow": ["order_lookup", "refund_request"],
"deny": ["refund_issue"]
},
"auto_start": true
}]
}Embedded control panel
The React control panel is compiled into the Rust binary and served at /ui. It is the operator interface for configuration, agent lifecycle, approvals, sessions, memory, scheduled work, logs, and health.
Choose model providers, store credentials, connect channel accounts, and validate the gateway before opening it to users.
Create specialists, assign tools and channels, start or stop their processes, and define which agents may delegate work.
Review sensitive tool calls, pair users, terminate sessions, inspect consent, and intervene when a task should not continue.
Watch channels and agents in real time, inspect errors, search memory, and follow the health of the running gateway.
Open protocol boundaries
Channels connect the gateway to people. Protocols connect it to capabilities and other software. Each boundary has a distinct job, so developers can add one without redesigning the whole runtime.
MCP
Connect capability servers for browsers, computers, media, data, and business systems. The gateway can add, list, and remove configured MCP servers without baking every integration into its binary.
ACP
Run supported coding-agent processes behind a supervised boundary. Workspace policy, permission requests, progress, cost, queue state, and task history stay visible to the gateway.
AWP
Publish discovery, capabilities, health, consent, subscriptions, and an agent message endpoint so other software can understand how to work with the gateway.
HTTP + WebSocket
Inbound webhooks bring work from other applications. HTTP APIs and live WebSocket events power the embedded control panel and external operations tooling.
Current boundary: the source exposes its agent-message route under the AWP surface. The page does not claim a separately verified, complete A2A server surface or production AWP commerce implementation.
Governance
Agent autonomy should be a configured operating decision. ADK Gateway places identity, authority, limits, and evidence around the same execution path that carries the request.
Pairing, allow lists, multi-user sessions, JWT/JWKS, and role mapping answer who is making the request.
Per-agent allow and deny rules plus tool approval determine which capabilities a person or agent may use.
Rate limiting, request timeouts, cancellation, bounded tool loops, and health policy limit how long work can continue.
Audit events, logs, metrics, task history, tool results, and health history provide an operational record.
Deployment
A developer workstation, an internal server, or a container can run the same gateway shape. Session storage can stay in memory for a local experiment or move to SQLite, PostgreSQL, Redis, or Firestore for a deployed system.
The Rust service embeds the compiled React control panel. Install or copy one executable and keep configuration beside it.
The repository includes a Dockerfile and documented volume and port contracts for container deployment.
A systemd unit supports boot startup, restart policy, readiness, logs, and operator-owned environment files.
A launchd definition runs a persistent local gateway for developer and workstation agents.
Migration and verification
The product capabilities on this page come from the local Gateway source, configuration, documentation, and test suites. The ADK-Rust v2 migration now passes its library, property, integration, generated-agent, and control-panel verification.
Channel adapters, message routing, agent registry, process lifecycle, sessions, memory, RAG, scheduled tasks, tool approval, access control, control-panel routes, AWP, MCP, ACP integration, deployment assets, and tests exist in the reviewed repository.
Every ADK dependency resolves to the local 2.0 workspace. Rust 2024 and Rust 1.95 compile across all targets and features. All 845 library tests, 276 standalone property and integration tests, and 81 control-panel tests pass.
The verified v2 state is currently a local source migration, not a published adk-gateway v2 crate. Installation guidance should continue to distinguish a source checkout from the crates.io v1 release.
Every messaging provider, model provider, external MCP server, persistent backend, identity provider, and production deployment still needs credentials, infrastructure, and security review from its operator.
Multi-agent code generation still documents placeholder A2A endpoints, and AWP commerce is declared but not implemented as a complete transaction system. Neither is presented here as production-ready.
Source review: All ADK dependencies resolve to the local v2.0.0 workspace, the project targets Rust 2024 with MSRV 1.94, and all-target/all-feature compilation passes. Verification passes 845 library tests, 276 standalone property and integration tests, and 81 control-panel tests; crates.io continues to publish the v1 release.
ADK Gateway is presented as source-backed software, not a website-hosted service. The local v2 migration is verified, while crates.io remains on v1. Messaging channels, model providers, external MCP tools, persistent backends, and production security depend on operator credentials and deployment configuration; experimental code generation and AWP commerce remain explicitly limited in the source documentation.
Build the operating layer
Start from the verified v2 source. The repository contains the gateway, embedded control panel, configuration reference, channel guides, deployment assets, and test suites needed to understand and operate the complete system.