Build agents around your application's state.

One application, different perspectives

Share structured results. Choose each agent's context.

A booking assistant and an availability specialist need the same proposed slot. They do not necessarily need the same conversation. In ADK, application state and model context are separate: agents work with a common data contract, and each agent has its own context renderers.

const app = adk({
	schema: {
		session: {
			slot: z.string().default(''),
			status: z.enum(['proposed', 'booked', 'declined']),
		},
	},
})

The app infers state types across tools, agents, steps, and renderers. Context starts empty before each model call; your renderers add instructions, selected history, and state. Keep a specialist focused, or deliberately share the wider session history.

Inspect both agents' context · Explore typed state · Compose context renderers

Control where you use AI

Choose which decisions belong to the model.

Use a model to interpret a request, reason through ambiguity, or hold a conversation. Use TypeScript to enforce a rule, select the next action, or decide what enters the model's context. You choose that balance for each part of your application.

Compose agents with steps, sequences, parallel branches, and loops. A step can execute an action directly or choose the next agent without a model call. A context renderer can select exact state fields and session events before each call. You can also let an agent choose among the tools you provide when the task needs that flexibility.

Hooks give you the same choice inside an agent's loop. A beforeModel hook can supply tool calls directly, bypassing the model while the runtime still validates arguments and executes the tools. Let other turns use the model as usual. You can make a specific action deterministic without turning the whole agent into a fixed sequence.

At Anima, this lets us put known decision rules in code and use models where interpretation is useful. An approval requirement can be a check that blocks execution, rather than an instruction we rely on the model to follow. As a workflow becomes better understood, more of its decisions can move into code while using the same state and session.

Run a deterministic check and router · Use hooks to run tools without a model call · Choose model context in code · Combine code and agent delegation

Work that continues

Wait for an answer without keeping a process alive.

A tool can ask for approval or missing information before it executes. The run returns the question, and a handler persists the session. A later request supplies the answer and continues the work, even in a different process or Lambda invocation.

You choose the persistent store and deployment. ADK records the pending work; it does not require a hosted orchestration service. The same session ledger records tool results and tracked state changes, so you can inspect how the application reached its current state.

Run the Bookings sample across two processes · Serve one turn per request

Text and voice

Keep your tools and state when the conversation becomes a call.

A voice agent can use the same booking lookup, state schema, and session ledger as a text agent. It can call text specialists during the conversation. A LiveKit handler and a supported realtime model provide the voice runtime, including speech and call lifecycle hooks.

Text agents can use OpenAI, Gemini, or Claude through provider-specific imports. Realtime voice supports OpenAI and Gemini. Change model configuration while keeping your application tools and state; provider capabilities and setup remain explicit.

Build a voice agent · Choose a model provider

Evidence from the same application

Test the code. Evaluate the conversation.

Why we build on it

Built for ongoing work at Anima.

We build clinical and operational applications where several agents contribute to the same work. They need structured information, different context, and a way to wait for people. We choose where models make decisions and where code enforces the rules. We also need to test application logic and evaluate conversations over text and voice. These requirements shape the ADK.

ADK fits TypeScript teams that want to own their application logic, runtime, and storage. Context selection controls model input; your application still owns access control. Durable pauses need a persistent store, and active voice calls need a LiveKit worker.

The package is pre-1.0. Core changes are documented in the changelog; experimental workflow and coding-agent APIs can change without a deprecation cycle. See the stability policy.