Firebase Genkit Agents API: Stateful Chat Agents

Google shipped the Genkit Agents API on July 1 — a chat() interface that packages session history, tool loops, streaming, session persistence, and HTTP deployment behind a single call. If you’ve been stitching together message buffers, Redis-backed session tables, and hand-rolled approval queues to run production agents, the point of this release is to make all of that someone else’s problem. This is a distinct surface from the Genkit 2.0 flows and Middleware we covered in May — it’s a stateful agent conversation runtime, available now in TypeScript and Go.

One API, Two Deployment Modes

The headline capability of the Genkit Agents API is deceptively simple: define an agent once on the server and drive it with the same chat() call whether it runs in-process or behind an HTTP endpoint.

const chat = ai.chat(myAgent);
const response = await chat.send("Process this order for $500.");

That parity matters more than it sounds. Most frameworks require you to rewire your code when you move from local development to a deployed server. Genkit’s approach means your test suite runs exactly what ships — no translation layer, no behaviour drift. The Agent Runner in the Genkit Developer UI gives you a full conversation interface, tool interrupt controls, and snapshot inspection without writing a single line of client code.

Alongside message history, an agent session carries two additional kinds of state: custom state (typed application data — task lists, workflow status, selected entities) and artifacts (generated outputs users can inspect, download, or version — reports, patches). Tools update both through the active session, and Genkit streams the changes to the client as they happen.

Interruptible Tools: Human Approval, Finally Standardized

This is the feature that makes the Genkit Agents API viable for enterprise. Without a built-in mechanism to pause an agent before irreversible actions, you’re running autonomous systems against production infrastructure with no kill switch.

Interruptible tools solve this: a tool pauses the agent and hands control back to the user. The model decides outside input is needed, the interrupt fires, and the client approves, rejects, or supplies a missing value before the turn continues. Payments, deployments, database mutations — any action you don’t want running automatically without a human confirmation step belongs here.

The security detail worth noting: the runtime validates every resume payload against session history, so a tool cannot be tricked into executing with forged input. That’s not a small thing when these agents have access to production APIs. Go developers get the same capability via genkitx.DefineInterruptibleTool and tool.Interrupt() — human-in-the-loop is not a TypeScript-only feature in this release.

Session Stores: From Demo to Production in One Config Line

The Genkit Agents API ships three session stores, and the choice maps directly to deployment stage:

• In-memory — tests, demos, single-process experiments. No config, no persistence across restarts.
• File — local development and single-host apps that need snapshots to survive a process restart.
• Firestore — production. Managed, multi-instance, zero-configuration if you’re already on Google Cloud or Firebase.

Leave the store off and the agent is client-managed: the server returns full state after each turn and the client echoes it back on the next. Add a Firestore store and the agent is server-managed: the server persists messages, custom state, and artifacts as snapshots automatically. Clients continue a conversation by sending a session ID.

For long-running work, the API adds detachable turns:

const task = await chat.detach('Write the quarterly market report.');
savePendingSnapshot(task.snapshotId); // any client reconnects later

The client detaches, closes the tab, the agent keeps running server-side, and writes progress to a pending snapshot. Any session — or the same user returning later — can poll, wait, or abort using the snapshotId. This replaces the pattern of routing long agent runs through a message queue just to get reconnect capability. It’s one method call now.

Frontend Integration and Go Support

For teams building with Next.js or the Vercel AI SDK, the @genkit-ai/vercel-ai package provides a GenkitChatTransport adapter that connects the SDK’s useChat hook directly to a Genkit agent. You assemble the UI from Vercel’s AI Elements components; Genkit handles everything on the backend. Both client-managed and server-managed session modes work through the adapter.

Go support deserves a separate mention because the Go agent framework ecosystem has been sparse compared to Python and TypeScript. The Genkit Agents API ships production-grade HITL, session persistence, and streaming for Go simultaneously with TypeScript — not as an afterthought six months later. If you’re running Go services and evaluating agent frameworks, that matters. The Go implementation guide for HITL interruptions covers the pattern end to end.

One important caveat: the Python and Dart SDKs are not part of the Agents API preview. Google has not announced a timeline. Flutter and Python developers: watch the Genkit release notes on GitHub — there’s no ETA yet, but the framework direction is clear.

How It Stacks Up

The Genkit Agents API is not the right choice for every team. The honest breakdown:

• vs. LangGraph — LangGraph’s graph model gives you explicit control over branching, looping, and state transitions at every node. If your agent logic is inherently graph-shaped with complex conditional routing, LangGraph is the better fit. Genkit’s conversation-first model is simpler but less flexible for those use cases.
• vs. Mastra — Mastra is TypeScript-only and deploys anywhere Node.js runs (Cloudflare, Bun, Deno). If you’re not on Google Cloud and don’t need Firestore persistence, Mastra’s broader deployment surface and strong built-in OpenTelemetry observability may suit you better.

The official Genkit Agents API announcement covers the full feature surface. The session management documentation is the right starting point for Firestore-backed sessions. If your stack is Firebase or Google Cloud, the Agents API gives you stateful, interruptible agent infrastructure with zero custom glue. For teams on other stacks, the framework choice still comes down to where you’re deploying and how much graph control you need.