ADK-Rust v2: from agent framework to production runtime.
The story of how tools, workflows, state, realtime media, coding agents, open protocols, and operating controls became one composable Rust system.
In March, we published the story of ADK-Rust v0.5. That release made the framework capable of more: retrieval, code execution, additional model providers, durable graphs, encrypted sessions, and a CLI that could create a useful starting project.
The next question was harder. Could those capabilities become one production system that a developer could compose, observe, secure, deploy, and keep running? The journey to v2 is the answer. It changed ADK-Rust from a growing agent toolkit into a Rust runtime for products whose agents speak, use tools, coordinate work, create artifacts, and collaborate across open protocols.
Read the previous chapter: ADK-Rust v0.5The road to v2
Six months of turning agent features into a system.
Each release solved a different part of the production problem. Together, they changed what developers can reasonably build around one Rust runtime.
The framework learned more kinds of work
RAG, code execution, provider improvements, durable graphs, encrypted sessions, and cargo-adk expanded what one Rust agent could do.
Agents crossed real system boundaries
A2A reached full remote-task flows. AWP gave websites an agent interface. MCP servers gained managed lifecycles, while memory and shared state became safer for larger products.
Composition became a developer experience
Feature tiers reduced the default dependency surface. ACP arrived, schemas adapted to each model provider, and templates plus add-ons made architecture a choice instead of a copying exercise.
The foundation became stable
Thirty-nine crates reached the stable tier with semantic-versioning commitments, stronger documentation gates, security work, evaluation, managed runtimes, and enterprise deployment APIs.
The runtime became the product backbone
CodingAgent and CodeAct joined the agent family. Tool calls, progress, results, cancellation, realtime media, knowledge-graph memory, and open protocols now travel through explicit runtime contracts.
The turning point
A production agent is much more than a model call.
Early agent examples naturally centered on a prompt, a model, and a response. Real products quickly exposed the rest of the work: deciding who can call a tool, preserving state, showing progress, resuming after an approval, moving a generated file, tracing a failure, and talking to services that belong to another team.
v2 treats those responsibilities as framework concerns with Rust contracts. The model remains important, but it runs inside an invocation with tools, sessions, events, callbacks, boundaries, and operating policy. You can replace the model without redesigning the product around it.
That is the architectural shift behind the major version: agent behavior and product infrastructure now meet in the same runtime, while remaining separate enough to compose and test.
The v2 architecture
Follow one piece of work through the whole product.
A request can arrive through a human interface or an agent protocol. The Runner gives it context, invokes the right agent shape, and streams typed events while tools, state, and operating controls support the work.
People and systems
Product surfaces
One execution contract
Runner and typed event stream
Choose the shape of the work
Composable agents
Give the agents useful reach
Tools, knowledge, and state
Keep production understandable
Operating controls
Inside the process
Agents, tools, sessions, callbacks, events, and cancellation share Rust traits and types.
Across a boundary
MCP, A2A, ACP, AWP, HTTP, and realtime transports connect systems with different owners.
Visible to the product
The same event stream can drive a CLI, web UI, API client, trace viewer, or remote agent.
See how it works
The execution trail is a product interface.
A useful agent needs to show more than its final sentence. v2 gives every meaningful step a place in the event stream, so developers can build interfaces around the work as it happens.
Request
A person, service, or agent starts the work.
Decide
An agent or workflow chooses the next meaningful action.
Act
A tool, specialist, model, or remote system performs the step.
Stream
Typed events carry calls, progress, results, and state changes.
Continue
The runtime responds, pauses for input, retries, or resumes later.
Imagine a coding agent running a test suite. The UI receives the tool call, line-by-line stdout and stderr, the typed result, any state or artifact changes, and the agent's next decision through one correlated stream. If the task needs approval or the process is interrupted, the session and checkpoint provide a clear place to continue.
What v2 gives a developer
One framework for the agent lifecycle.
You can begin with one conversational agent and add structure only as the product needs it. The same core contracts remain in place as the system grows.
Agents can work in different ways
Use an LLM agent for flexible reasoning, deterministic workflow agents for known sequences, graphs for branching and durable work, realtime agents for voice and video, CodingAgent for repository work, or CodeAct when a model should express a multi-step action as executable code.
Progress is part of the API
Tool calls and tool results are typed events. Long-running tools can emit progress into the same stream as the agent response, with call IDs linking the request, live output, and final result. A UI can render the work without scraping logs.
State can outlive one model turn
Sessions preserve the conversation, artifacts keep generated files, graph checkpoints resume workflows, and semantic or bi-temporal knowledge-graph memory gives agents context that remains useful across later sessions.
Open protocols have clear jobs
MCP connects tools and resources, A2A connects independently deployed agents, ACP connects coding-agent clients and servers, and AWP gives a website a structured interface for agents alongside its human interface.
Autonomy has operating boundaries
Authorization callbacks, scoped tools, guardrails, approvals, sandbox policies, cancellation, telemetry, evaluation, and audit evidence let a team decide what an agent may do and inspect what happened afterward.
You compile the product you need
The minimal tier keeps a first agent small. Standard adds the common production stack; enterprise adds realtime, browser, RAG, payments, and AWP; full adds the heaviest audio and execution capabilities. Individual features remain available when a preset is too broad.
The starting experience
Choose a working shape, then make it yours.
The v2 CLI can scaffold the execution shape and add the surrounding capabilities. The generated project still looks like Rust you would write and review yourself.
Create and verify
cargo install cargo-adk
cargo adk new support-agent \
--template tools \
--addon sessions \
--addon telemetry \
--addon guardrails
cd support-agent
cargo adk build
cargo runCompose the agent
let agent = LlmAgentBuilder::new("support")
.description("Resolves customer issues")
.instruction("Use the reviewed tools and cite evidence.")
.model(Arc::new(model))
.tool(Arc::new(LookUpOrder))
.before_tool(approval_gate)
.build()?;
Launcher::new(Arc::new(agent))
.run()
.await?;Twelve templates cover common starting architectures. Nine add-ons compose capabilities such as sessions, telemetry, MCP, auth, browser tools, and guardrails. Five enterprise patterns provide larger deployment shapes. cargo adk build checks the generated project before deployment.
Verified against the v2 source
The details behind the story.
The next chapter starts with a real agent
Build the first workflow. Keep the path to production open.
Start with one request, one visible tool call, and one session you understand. ADK-Rust v2 gives that small agent a direct path to workflows, memory, open protocols, realtime interfaces, security, and deployment when the product is ready for them.