Source availableADK-Rust v2 test matrix verified

Multi-channel agent operations

Run your agents where your users already work.

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.

ADK Gateway operating

People and systems

Telegram
Slack
WhatsApp
Discord
Matrix

Identity · Router · Runner

sessionspolicyeventsdelivery

Agent team

System agent
Support agent
Research agent
Coding agent
toolsmemoryprotocolscontrol

Why a gateway?

An agent is useful. An operated agent system is a product.

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.

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

With ADK Gateway

  • Channel adapters share one inbound contract
  • Routing selects an agent and session deliberately
  • Capabilities and policy stay attached to agent roles
  • One control panel shows agents, channels, work, and health

Architecture

One gateway around a team of independently controlled agents.

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

  • Telegram · Slack
  • WhatsApp · Discord
  • Matrix · webhooks
  • AWP requests

Trust edge

  • Pairing + identity
  • Allow lists + roles
  • Rate limits
  • JWT / SSO

Gateway runtime

  • Message router
  • ADK-Rust Runner
  • Sessions + events
  • Delivery

Agent team

  • System agent
  • Specialist agents
  • Graph workflows
  • ACP coding agents

Capabilities

  • Models + fallback
  • Rust tools + MCP
  • Memory + RAG
  • Artifacts + storage

Operator control plane

Configure, approve, observe, recover, and audit the complete request path.

Control panelWebSocket eventsMetricsLogsHealth
Interfaces and deliveryIdentity and operating policyRouting and executionState and capabilities

Follow one request

From a Telegram message to the right specialist agent.

The same flow applies to every supported channel. Only the adapter and delivery format change; routing, sessions, agent execution, policy, and evidence remain shared.

  1. 01Channel adapter

    Receive one message shape

    Telegram, Slack, WhatsApp, Discord, Matrix, and webhooks arrive in different formats. Each adapter turns them into the same inbound message contract.

  2. 02Access boundary

    Identify who may continue

    Pairing rules, allow lists, group mention policy, multi-user identity, rate limits, and optional JWT checks run before the request reaches an agent.

  3. 03Message router

    Choose the right agent

    Routing checks the channel, account, and person or group. The most specific match wins; the system agent is the final fallback.

  4. 04ADK-Rust Runner

    Restore the conversation

    The Runner attaches the correct session, user context, memory, cancellation state, and model fallback chain before agent execution begins.

  5. 05Specialist agent

    Use only assigned capabilities

    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.

  6. 06Delivery + evidence

    Return progress and keep a record

    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

Routing is explicit and testable.

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.

router.rs · simplified resolution order
/// 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)
}
gateway.json · agent, channel, and role
{
  "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

See the system. Change it deliberately.

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.

Set up

Choose model providers, store credentials, connect channel accounts, and validate the gateway before opening it to users.

First-run wizardModel fallbacksChannel connection testsValidated JSON configuration

Direct the agents

Create specialists, assign tools and channels, start or stop their processes, and define which agents may delegate work.

Agent lifecycleChannel bindingsDelegation permissionsScheduled tasks

Stay in control

Review sensitive tool calls, pair users, terminate sessions, inspect consent, and intervene when a task should not continue.

Tool approvalsPairing and rolesSession terminationAWP consent

Operate

Watch channels and agents in real time, inspect errors, search memory, and follow the health of the running gateway.

Live WebSocket dashboardLogs and metricsMemory browserComponent health

Open protocol boundaries

Connect tools, coding agents, websites, and applications.

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

Give agents external tools

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

Delegate coding work

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

Expose an agent-facing web surface

Publish discovery, capabilities, health, consent, subscriptions, and an agent message endpoint so other software can understand how to work with the gateway.

HTTP + WebSocket

Integrate and operate

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

Give agents room to work inside visible boundaries.

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.

01

Identity

Pairing, allow lists, multi-user sessions, JWT/JWKS, and role mapping answer who is making the request.

02

Authority

Per-agent allow and deny rules plus tool approval determine which capabilities a person or agent may use.

03

Limits

Rate limiting, request timeouts, cancellation, bounded tool loops, and health policy limit how long work can continue.

04

Evidence

Audit events, logs, metrics, task history, tool results, and health history provide an operational record.

Deployment

Choose where the gateway should run.

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.

01

Single binary

The Rust service embeds the compiled React control panel. Install or copy one executable and keep configuration beside it.

02

Container

The repository includes a Dockerfile and documented volume and port contracts for container deployment.

03

Linux service

A systemd unit supports boot startup, restart policy, readiness, logs, and operator-owned environment files.

04

macOS service

A launchd definition runs a persistent local gateway for developer and workstation agents.

Migration and verification

What is verified today?

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.

Verified source

Gateway product architecture

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.

Tests verified

Local ADK-Rust v2 migration

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.

Published release

crates.io remains on v1

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.

Operator verification

Credentialed and deployed behavior

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.

Explicit limitation

Experimental surfaces

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

Connect one channel. Route one request. Keep every decision visible.

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.