Google's Genkit Ships Agents API to Kill Conversational AI Boilerplate

Genkit's new Agents API bundles message history, streaming, persistence, and human-in-the-loop into one interface for TypeScript and Go

·
·
Google's Genkit Ships Agents API to Kill Conversational AI Boilerplate
  • Genkit Agents API launched in preview for TypeScript and Go, packaging message history, streaming, tool loops, and persistence into one chat() interface.
  • Flexible state management: choose server-managed (Firestore snapshots, session IDs) or client-managed (stateless servers) persistence per app.
  • Human-in-the-loop built in: tools can pause execution mid-turn for user approval before payments, deployments, or risky actions.
  • Long-running detached tasks: clients can disconnect and reconnect by snapshot ID while the agent keeps working server-side.
  • Multi-agent coordination: an orchestrator agent can delegate to specialist sub-agents via middleware, with artifacts merging into the parent session.
  • Free and open-source; costs are only from underlying model APIs. Docs at genkit.dev/docs/agents/overview.

Genkit, Google's open-source full-stack AI framework, just shipped its Agents API in preview for TypeScript and Go. The pitch is simple: stop rebuilding the same scaffolding for every conversational AI feature you ship. Message history, the tool loop, streaming, session persistence, a client wire protocol -- all of it is now behind a single chat() interface.

The most compelling AI features are conversational -- a support assistant that remembers the ticket, a copilot that works across several turns. Each needs more than a single generate() call, and building one today means wiring up message history, the tool loop, streaming, persistence, and a frontend protocol by hand. That plumbing repeats on every project and has little to do with what makes your app distinct.

One interface, server to browser

Genkit solves this with the Agents API, which packages all of that behind one interface. You define an agent on the server, then drive it with the same chat() API whether it runs in process or behind an HTTP endpoint. The JavaScript client mirrors that same interface, so the code you use in backend tests is the same code you use from the browser -- no separate request/response protocol to design.

If you already have apps that use the Vercel AI SDK UI library, the @genkit-ai/vercel-ai package provides an adapter for its useChat hook. The GenkitChatTransport adapter connects useChat to your Genkit agent, so you can assemble the interface from Vercel's AI Elements components while getting all the benefits of Genkit on the backend.

State that lives where you want it

One of the more thoughtful design decisions here is how state ownership works. You choose whether the server or the client holds the conversation state, and the API adapts accordingly.

  • Server-managed: Add a session store and the server persists messages, custom state, and artifacts as snapshots. Clients continue a conversation by sending back a session ID. Best for persistent chat apps and shared devices.
  • Client-managed: Leave the store off and the server returns the full state, which the client sends back on the next turn. Good for stateless server deployments or when your app already owns persistence.
  • Branching: Every successful server-managed turn writes a snapshot. You can resume from the latest state by sessionId, or branch from an exact point in history by snapshotId -- letting a user explore an alternative from any saved moment without disturbing the original thread.

The API supports flexible, server- or client-managed state persistence -- allowing for advanced workflows like history branching, long-running detached tasks, and multi-agent coordination -- while seamlessly connecting backends to frontends via a unified wire protocol.

For production, you can deploy to Firebase, Google Cloud Run, or any environment that supports your chosen programming language, and monitor them in the Firebase console. Genkit ships in-memory and file-based stores for local development, and Firestore for production multi-instance deployments.

Human approval and long-running work, built in

A tool can pause an agent and hand control back to the user. The model decides outside input is needed, the tool interrupts, and the client approves, rejects, or supplies the missing value before the turn continues. This is how you put a human in the loop before a payment, a deployment, or any action you do not want to run automatically.

The Agents API also handles tasks that outlive the HTTP request. A client can detach a turn, close the tab, and reconnect later by snapshot ID. The agent keeps working on the server, writing progress to a pending snapshot that another session can poll, wait on, or abort. This makes long research jobs and tool-heavy workflows practical without holding a connection open or building a separate job queue.

Multi-agent coordination

When one prompt cannot do everything well, you can split work across specialized agents and let an orchestrator combine their results. The Agents middleware injects a delegation tool for each sub-agent, so the orchestrator model can route parts of a request to the right specialist. Delegation shows up as ordinary tool activity in the orchestrator's stream, and specialist artifacts can merge into the parent session.

The blog post is also explicit about when not to use Genkit agents. If multi-agent orchestration is the whole system rather than one feature inside a user-facing app, Google points to the Agent Development Kit (ADK) instead. ADK was designed from day one around Vertex AI and Google Cloud's agent infrastructure, including Agent Engine, Cloud Run, and GKE -- it is the framework Google recommends when you're building agents that will live in a Google Cloud environment at scale. Genkit is the right tool when the agent is a feature inside a full-stack, user-facing product.

Infographic comparing ADK 2.0 for Python and Go, highlighting graph-based workflows and human-in-the-loop capabilities

Developer UI and getting started

Agents are first-class in the Genkit Developer UI. The new Agent Runner lets you start a conversation, send turns, watch streamed output and state updates, drive tool interrupts, and inspect snapshots -- all without writing a client. It is the fastest way to exercise an agent while you are building it and to reproduce a conversation when you are debugging one.

Getting started is a few lines of code. Here is the minimal TypeScript client connecting to a remote agent:

import { remoteAgent } from 'genkit/beta/client';
const agent = remoteAgent({
  url: 'http://localhost:8080/api/weatherAgent',
});
const chat = agent.chat();
const res = await chat.send('Weather in Tokyo?');
console.log(res.text);

Streaming works through the same interface via sendStream(), which returns a chunk stream where each chunk can carry text, custom state, or an artifact as it is produced.

Availability and caveats

The Agents API is in preview today in TypeScript and Go. The API is in beta, so the team wants your feedback: file an issue with what you build and what you would change. Being in preview means it can introduce breaking changes in minor version releases, so treat it as a foundation to build on -- not a stable contract just yet. The framework itself is free and open-source; you pay only for whatever model API or cloud infrastructure you use underneath it.

Among the major JS/TS generative AI frameworks, Genkit stands out as the most versatile choice for teams that haven't already committed to a cloud platform. Its combination of multi-level abstractions, provider neutrality, and the Developer UI creates a development experience that genuinely accelerates iteration. The Agents API is the piece that was missing to make that story complete for production conversational apps. Head to the full-stack agents documentation to dive in.

Comments

avatar