ADK-Rust: A 43-Crate Rust Agent Framework With Its Own Runtime UI

What ADK-Rust Is Actually Assembling

The problem ADK-Rust addresses is the gap between a model call and a running agent service. Calling a model is a few lines in any language. Keeping a session, streaming events, storing artifacts, resuming a paused workflow, and exposing all of that over HTTP is the part that turns into a project. ADK-Rust packages that layer for Rust developers, and the README frames it as model-agnostic, type-safe, and async, spread across 43 publishable crates for agent orchestration. The audience is narrow and clear: engineers who already build in Rust and would rather not run a Python agent process beside a Rust service. The topics list on the repository names the pieces directly (adk-agent, adk-artifact, adk-cli, adk-memory, adk-model, adk-server, adk-tool, adk-google, realtime), which is a fair summary of the decomposition. What it is not is a hosted product. There is no managed control plane in the material; you install a CLI, generate a project, and run a server yourself.

How the Pieces Fit: Models, Tools, Memory, Runtime

The architecture is a crate-per-concern layout rather than a single library with feature flags. Models, tools, memory, artifacts, and the server are separate crates, which means you can depend on a subset and skip the rest. On top of that sits a graph workflow layer: v2.2.0 adds native tool confirmation pauses to graph workflows, and the v2.0.0 release notes describe subgraphs, where a graph is used as a node and nesting is checked at compile time so channel mismatches surface when the parent compiles rather than as an absent value at run time. There are two orchestration APIs, and the project states plainly in its episode highlights that it kept both when other ADKs deprecated one. That is a deliberate compatibility decision, and it also means you have to choose which one your codebase follows. State persistence runs through SQLite checkpointers with delta checkpoints, and the release notes describe a pause that resumes in a fresh process sharing only the database file. Tracing was reworked in v2.2.0 so one invocation exports as one trace instead of several disconnected ones.

Scaffolding an Agent With cargo-adk

The documented path is short. Install the scaffolder, generate a project, fill in a key, run it:

cargo install cargo-adk cargo adk new quickstart_agent --template api --provider openai cd quickstart_agent cp .env.example .env cargo run

After that the README points at http://127.0.0.1:8080/ui/, where the UI creates the session, streams the run, renders Markdown and tool results, and keeps the event timeline, state, artifacts, and telemetry beside the conversation. The README also gives a server check that does not go through the browser: curl -fsS http://127.0.0.1:8080/api/health. Two details are worth noticing. The template flag is api, which implies other templates exist without the HTTP runtime, and the README mentions a console-only alternative in the quickstart doc. The provider flag is openai in the example, while the topics list also names adk-google. For an existing project the README gives the dependency line directly: adk-rust = "2.2.0" in [dependencies]. The README requires Rust 1.95 or newer, which is a recent toolchain; check that against your CI images before you start.

The Gemini Enterprise Path Is Opt-In and Additive

The v2.2.0 notes are the most concrete description of scope in the material. The release completes what it calls the Gemini Enterprise Agent Platform consumption path: a Gen AI Evaluation Service bridge, Vertex AI RAG Engine retrieval and grounding, an Agent Retrieval vector store, Agent Registry discovery and registration, Skill Registry consumption with remote skill loading, and remote ReasoningEngine agents callable as sub-agents. The wording matters: every one of those is opt-in and composable with any preset, and they are appended to a gemini-agent-platform feature. So the default build does not drag in Vertex AI. If you are not on Google Cloud, most of v2.2.0 is irrelevant to you, and that is fine. If you are, this is the release that makes the framework a plausible front end for an existing Vertex deployment rather than a standalone agent library. The realtime topics (realtime, realtime-audio, realtime-adk) and the adk-audio crate point at voice agents; the README notes that the project's own podcast episodes were generated with its Chirp3-HD multi-speaker TTS synthesis via adk-audio. That is a self-hosted demonstration rather than a benchmark, but it does show the audio path being used for a non-trivial output.

Where ADK-Rust Is the Wrong Tool

The project's own v2.0.0 episode highlights list limitations, which is more candour than most release notes offer. No automatic crash recovery: if a process dies outside a checkpoint boundary, the framework does not reconstruct the run for you. An unbounded child ledger, meaning sub-agent bookkeeping is not capped by the framework. And two orchestration APIs retained rather than one, which the maintainers defend on compatibility grounds but which doubles the surface a new contributor has to learn. The migration note is the sharper constraint. Coming from 1.x, six APIs changed shape and the fan-in default changed behaviour without an API change, which is the worst kind of break because the compiler will not catch it. There is a migration guide at docs/official_docs/migration/1.0-to-2.0.md and a CHANGELOG, but the burden is on you to read them. Beyond that, the obvious mismatch: if your team writes Python, this is the wrong tool regardless of its qualities, because the cost of adopting Rust for agent work exceeds the cost of the framework itself. The license field on the repository reads NOASSERTION even though the README badge and the LICENSE link point at Apache 2.0. That discrepancy is worth resolving with the maintainers before you depend on the terms.

Comparing It With LangGraph on Approach, Not Speed

The release material compares ADK-Rust's agent-loop overhead against LangGraph, citing 568 microseconds against 1,228 milliseconds. Treat that number with suspicion: it is a project-published figure from a podcast episode, the two systems are not described as running the same workload, and loop overhead is rarely the bottleneck in an agent that spends most of its wall time waiting on a model API. The more useful difference is structural. LangGraph is a Python graph library that assumes a Python process and the Python agent ecosystem around it. ADK-Rust is a Rust workspace of 43 crates that assumes cargo, a recent toolchain, and a willingness to write agent logic in a compiled language. The trade is real in both directions: Rust gives you type-checked graph composition (the subgraph channel mismatch caught at parent compile time is a genuine example) and a single static binary to deploy, while Python gives you a much larger pool of existing integrations and a much larger pool of engineers who can read the code. If your agent is mostly prompt orchestration over HTTP APIs, the Rust advantage is small. If your agent is embedded in an existing Rust service with strict latency and memory budgets, it is large.

Maintenance Cost and the Version Cadence

The release cadence is fast. v2.0.0 landed on 2026-08-17, v2.1.0 on 2026-08-25, and v2.2.0 on 2026-09-01, roughly one minor release per week across that window, with the last push to main on 2026-09-08. v2.2.0 is described as an API-compatible minor release, so the immediate upgrade is cheap, but the 1.x to 2.x step was not, and a weekly minor cadence means you should expect to read release notes regularly rather than pin and forget. The crate count is the other maintenance line item: 43 publishable crates means 43 version numbers to keep aligned, though the workspace model normally handles that for you if you depend on the umbrella adk-rust crate. The README also notes that the episode 3 video and slides are not in the repository because the video alone is about 900 MB, over GitHub's 100 MB per-file limit; the script and deck source are. That is a small thing, but it tells you the project generates large binary artifacts and keeps them out of git, which is the right call. On licensing, the README badge says Apache 2.0 and links a LICENSE file, while the repository metadata says NOASSERTION. Confirm which text actually applies to the crates you depend on before shipping, and get your own legal read rather than taking a badge as authoritative.

Editorial conclusion

Adopt ADK-Rust if you are already writing Rust services and want agent orchestration, checkpointing, and a runtime UI in the same language and toolchain, or if you specifically need the Gemini Enterprise Agent Platform path that v2.2.0 completes. Do not adopt it if your team is not fluent in Rust, if you need a Python ecosystem of existing agent code, or if you cannot absorb the 1.x to 2.x migration: the project's own notes say six APIs changed shape and the fan-in default changed behaviour without an API change. Verify first that the crate split matches your deployment, that the NOASSERTION license metadata resolves to the Apache 2.0 text the README badge points at, and that you can run the five-minute quickstart end to end on your own machine before committing a service to it.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zavora-ai/adk-rust on GitHub