Originally published at twarx.com - read the full interactive version there.
Last Updated: June 26, 2026
The Interactions API Gemini models agents endpoint just reached General Availability — and every orchestration framework you bolted together last year became Stateless Agent Debt. Your LangGraph state machines, your AutoGen message queues, your hand-rolled session managers: all of it. Google's Interactions API ships server-side state, background execution, and managed agents as a single unified endpoint, and it hit GA in June 2026 before most developers even knew it existed.
This is now Google's primary interface for talking to Gemini models and agents. Not one option among several. The primary one. It matters right now because Google just defaulted every doc, every 3P SDK, and the entire ADK pipeline to the Interactions API — quietly, while you were still maintaining your Redis session layer.
By the end of this piece you'll know exactly what shipped, how it works, what it costs, when to migrate off LangGraph — and when not to.
Google's official launch graphic for the Interactions API reaching general availability — a single unified endpoint for Gemini models and agents. Source
Coined Framework
The Stateless Agent Debt
The accumulated engineering liability incurred by teams who built client-managed conversation state, tool routing, and background execution into their own code rather than delegating to the API layer. Google's server-side Interactions API renders most of that code redundant overnight — and now you're paying interest on infrastructure nobody needs.
Breaking: What Google Announced and When (Official Facts)
Let's get the basics nailed down, because there's already noise in the ecosystem about what actually shipped versus what's on the roadmap.
The official announcement timeline: blog.google dates and sources
On June 26, 2026, Google DeepMind published the GA announcement on The Keyword, authored by Ali Çevik (Group Product Manager, Google DeepMind) and Philipp Schmid (Developer Relations Engineer, Google DeepMind). The headline doesn't hedge: 'the Interactions API has reached general availability and is now our primary API for interacting with Gemini models and agents.'
The public beta launched in December 2025. Per Google, it 'quickly become developers' favorite way to build applications with Gemini' in the six months since. I'd be curious what the breakage rate looked like during that beta — because the most common complaint I heard from teams was schema instability. More on that in a moment.
General Availability confirmed: June 2026 milestone
The GA release does three concrete things, all confirmed in the official text:
It locks in a stable schema — the single most developer-requested feature, and honestly the one that matters most for teams already burned by beta breaking changes.
It adds Managed Agents, background execution, and Gemini Omni (coming soon).
All Google documentation now defaults to the Interactions API, and Google is 'working with ecosystem partners to make it the default interface across 3P SDKs and Libraries.'
What changed from the previous Gemini API interface
Previously, building a multi-turn Gemini agent meant managing your own session state, your own tool routing, and your own async job handling in client code. Every team reinvented the same four components. The Interactions API moves all of that server-side — and as Google puts it: 'Whether you're calling a model or running an agent, the Interactions API gets you there in a few lines of code.'
Google didn't release a new model. They released a new contract — and quietly deprecated half your codebase in the process.
The named reference agent is Antigravity, which 'ships as the default' and runs inside a remote Linux sandbox provisioned by a single API call.
What Is the Interactions API? A Technical Definition
If you're evaluating whether this replaces your stack, you need the precise mechanism — not marketing language.
The single unified endpoint architecture explained
The Interactions API is described officially as a 'single unified endpoint for Gemini models and agents with server-side state, background execution, tool combination and multimodal generation.' The mental model is genuinely simple: one endpoint, two modes.
Pass a model ID → you get inference (single or multi-turn).
Pass an agent ID → you get an autonomous task runner with a sandboxed environment.
Set background=True → anything long-running executes asynchronously on Google's servers, not yours.
That collapse — model calls and agent runs behind one schema — is the architectural heart of this release. You no longer choose between the generate endpoint and a separate agent runtime. One request shape handles both. That sounds small until you've spent three weeks maintaining two diverging client libraries for the same underlying model.
Server-side state: how Gemini now owns conversation memory
Server-side state means conversation history, tool-call results, and agent context persist on Google infrastructure — not in your client code, not in a Redis instance you babysit, not in a vector store you stood up purely to remember the last six turns.
For basic multi-turn agent interactions, this eliminates the need for an external session store entirely. You reference a persisted interaction; Google holds the thread. I've watched teams spend a full sprint building exactly this plumbing, only to throw it away when a managed alternative shipped. That's the debt.
If your only reason for running Pinecone or a self-hosted vector DB was conversational memory — not private document retrieval — the Interactions API just deleted that line item from your infra bill.
The Stateless Agent Debt problem this API solves
Here's the contrast that matters for migration decisions. LangGraph and AutoGen require you to define and manage state graphs explicitly. You author the nodes, the edges, the checkpoints, the persistence layer. That's real engineering value when you need fine-grained control — and genuine overhead when you don't. The Interactions API abstracts all of it for the common case. The question is whether your use case is actually common or actually complex.
Coined Framework
The Stateless Agent Debt — quantified
Every line of custom session management, tool-routing glue, and async job-polling code you wrote is now a liability with carrying cost: maintenance, on-call burden, and breaking changes. Teams with more than ~3,000 lines of bespoke state management are the prime migration candidates.
The Stateless Agent Debt visualized: the left stack (client-managed state, custom routers, polling loops) collapses into a single server-side Interactions API call on the right.
Dec 2025
Public beta launch of the Interactions API
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
1 endpoint
Unified interface for both models and agents
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
~3,000 LOC
Custom state code above which migration ROI flips positive
[Twarx estimate, 2026](https://langchain-ai.github.io/langgraph/)
Full Capability Breakdown: Every Feature Confirmed at Launch
What can the Interactions API actually do? Here's the complete confirmed feature set, grounded in the official announcement — not the ecosystem speculation that's already spreading.
Managed Agents: cloud-sandboxed agent execution
Per Google: 'A single API call provisions a remote Linux sandbox where an agent can reason, execute code, browse the web and manage files.' No self-hosted infrastructure required. The Antigravity agent ships as the default, and you can 'define your own custom agents with instructions, skills and data sources.'
This is the headline capability for production teams. The sandbox handles code execution, web browsing, and file management inside Google Cloud — which means the riskiest parts of autonomous agents (arbitrary code execution, mostly) run in an isolated environment you didn't have to harden. That's not a small thing. Sandboxing arbitrary LLM-generated code in-house is genuinely painful, and most teams either do it badly or don't do it at all.
Background execution: long-running tasks without a client connection
Set background=True on any call and 'the server runs the interaction asynchronously.' This decouples user-facing latency from agent work duration. A 4-minute research task no longer requires an open client connection — or a polling loop you maintain, or a job queue you operate, or a webhook handler you debug at 2am when it silently stops firing.
background=True is three keystrokes that delete an entire category of infrastructure: the job queue you built so users wouldn't stare at a spinner for six minutes.
Multimodal support and tool combination in one endpoint
The unified endpoint supports multimodal generation and tool combination — mixing built-in tools (search, code execution) with custom functions, all declared and orchestrated server-side in a single API call. MCP (Model Context Protocol) compatibility is part of the ecosystem story, enabling cross-platform tool definitions that travel between providers. That portability matters more than it sounds if you're not certain Google will be your only model provider in 18 months.
Tool combination server-side means the model can chain search → code execution → custom function within one interaction without round-tripping every step to your client. That's where the latency wins compound.
Gemini 3 Pro parameters: latency, cost, and multimodal fidelity controls
Confirmed vs. inferred — be precise here. The official text confirms: stable schema, Managed Agents, background execution, tool improvements, multimodal generation, and Gemini Omni 'soon.' Broader Gemini 3 capabilities (configurable level-of-thinking, cost-tier selection, multimodal fidelity controls) align with Google DeepMind's Gemini direction but go beyond the verbatim GA post — treat those as ecosystem context, not GA guarantees, and confirm exact parameters in the official Gemini API docs before you depend on them.
How an Interactions API Managed Agent Request Flows End-to-End
1
**Client → Interactions API endpoint**
You send one request: agent_id (e.g. Antigravity), instructions, tools, and optionally background=True. No state graph to define.
↓
2
**Sandbox provisioning**
A single call spins up a remote Linux sandbox. The agent gets code execution, web browsing, and file management — isolated inside Google Cloud.
↓
3
**Server-side state + tool orchestration**
Gemini holds conversation history and tool results. Built-in and custom tools (incl. MCP) are combined and orchestrated without client round-trips.
↓
4
**Background execution (optional)**
With background=True the interaction runs async. Your client disconnects; the server keeps working on the task.
↓
5
**Result retrieval**
Poll or subscribe to the interaction ID. Persisted state means you can resume the same thread later without rehydrating context yourself.
The sequence matters because each stage previously required separate infrastructure you owned — now collapsed into one server-managed lifecycle.
How to Access and Use the Interactions API: Step-by-Step
This is the practical path from zero to a running agent. No throat-clearing.
Prerequisites and authentication setup
Access is via the Google AI for Developers portal. API key setup is unchanged from the prior Gemini API — if you already have a key, you already have access. If you don't, grab one from Google AI Studio. That's genuinely it for prerequisites.
Making your first Interactions API call with Gemini
The core pattern, per Google: 'Pass a model ID for inference, an agent ID for autonomous tasks, set background=True for anything long-running.' Here's a representative request structure (confirm exact field names against the official docs — field names in new APIs have a way of shifting between announcement and GA even when the schema is supposedly stable):
python — first Interactions API call
Inference: pass a model ID
response = client.interactions.create(
model='gemini-3-pro', # model ID = inference mode
input='Summarize Q2 support tickets by theme.'
)
print(response.output)
Agent: pass an agent ID + a sandbox-backed task
run = client.interactions.create(
agent='antigravity', # agent ID = autonomous mode
input='Browse our docs site and list broken links.',
background=True # async, server-side execution
)
Server-side state: resume later by interaction ID
result = client.interactions.retrieve(run.id)
Configuring Managed Agents and background tasks
Managed Agents require specifying an agent identifier (Antigravity is the pre-built reference) plus sandbox-backed parameters. You can define custom agents with 'instructions, skills and data sources.' For long-running work, flip background=True and retrieve by interaction ID. The retrieval pattern is the same whether the job took two seconds or two minutes — that consistency is what makes it actually usable.
Building your own agents? Explore our AI agent library for reference patterns you can adapt, and see how teams structure multi-agent systems on top of a unified endpoint.
OpenAI SDK compatibility and pricing
OpenAI library compatibility is part of the Gemini ecosystem story — redirecting existing OpenAI SDK integrations typically means updating the base URL, API key, and model name. The classic three-line swap. Verify the current compatibility surface in the official compatibility docs before migrating production traffic; compatibility layers have a habit of covering 90% of cases and then surprising you with the remaining 10% at the worst moment.
Pricing follows Gemini's token-based model, with background-execution jobs incurring additional per-task cost. Exact figures live in the Google AI pricing console — always price against the live console, since model tiers change. We break down workflow automation economics separately if you need the full TCO picture.
A Managed Agent configuration flow: agent_id, instructions, tools, and the background=True flag — the entire stateful agent lifecycle in one request body.
[
▶
Watch on YouTube
Google Interactions API: building Gemini agents with server-side state
Google DeepMind • Gemini API & Managed Agents
](https://www.youtube.com/results?search_query=Google+Interactions+API+Gemini+agents)
When to Use the Interactions API vs. Alternatives
Not every workload should migrate. Here's the decision framework mapped against the real alternatives — because 'just use the new thing' is not a migration strategy.
Interactions API vs. building with LangGraph or AutoGen
Choose the Interactions API when: you need stateful multi-turn agents without managing infrastructure, and you're moving from prototype to production in under 30 days. The operational simplicity is real. Choose LangGraph when: you need fine-grained control over state transitions, branching logic, or human-in-the-loop checkpoints at specific graph nodes. LangGraph's explicit graph model isn't boilerplate — it's load-bearing for certain compliance patterns. Don't rip it out because GA shipped.
Interactions API vs. the legacy generate endpoint
The legacy generate endpoint remains valid for single-turn, stateless completions. Pure text generation with no memory gets nothing from migrating — you'd be paying agent overhead for inference that doesn't need it. Keep stateless calls stateless.
Interactions API vs. n8n and no-code orchestration
n8n and similar visual builders still add real value for non-developer teams who need drag-and-drop workflows. But the Interactions API does reduce the integration surface area significantly — fewer nodes to wire, less glue between steps. See our take on n8n automation for where visual builders still win and where they become friction.
When you still need a custom orchestration layer
You still need bespoke orchestration when: compliance demands human approval gates as first-class primitives, you run cross-provider agents that can't live on Google infra, or you have deterministic branching that the model genuinely shouldn't be deciding. Read more on building solid orchestration layers and where AI agents need guardrails you can't outsource.
❌
Mistake: Migrating stateless completions just because GA shipped
Single-turn text generation gains nothing from server-side state. Moving it onto the agent path adds latency and per-task cost for zero benefit.
✅
Fix: Keep pure generative calls on the model-ID inference path. Reserve agent IDs and background=True for genuinely stateful or long-running work.
❌
Mistake: Ripping out LangGraph for compliance-sensitive agents
The Interactions API does not yet expose human-in-the-loop approval checkpoints as a first-class primitive. Compliance teams that delete LangGraph lose their audit gates.
✅
Fix: Keep LangGraph (or custom middleware) for approval-gated workflows; use the Interactions API for the autonomous, low-risk portions.
❌
Mistake: Ignoring data residency on server-side state
Server-side state stores conversation context on Google infrastructure. For regulated industries, that raises residency and portability questions teams discover post-launch.
✅
Fix: Confirm region availability and data handling in the Google AI docs before storing regulated data in persisted interactions.
❌
Mistake: Keeping a vector DB purely for chat memory
Many teams stood up Pinecone or pgvector just to remember recent turns. With server-side state, that's redundant cost and operational overhead.
✅
Fix: Use vector DBs for private document retrieval (RAG) only; let the Interactions API own conversational memory.
Interactions API vs. Closest Competitors: Direct Comparison
How does Google's unified endpoint stack against the OpenAI Assistants API, Anthropic's agent patterns, and AWS Bedrock Agents? Here's the honest version.
The OpenAI Assistants API introduced server-side threads and tool state back in 2023 — Google is matching that baseline and extending it with native multimodal tool combination plus explicit background async execution. Anthropic's Claude offers excellent tool use and multi-agent patterns but expects client-side orchestration via CrewAI or custom code — no native managed-agent sandbox as of June 2026. AWS Bedrock Agents provides managed execution but ties you to AWS infrastructure completely.
CapabilityGoogle Interactions APIOpenAI Assistants APIAnthropic ClaudeAWS Bedrock Agents
Server-side stateYes (native)Yes (threads, 2023)Client-sideYes (AWS-bound)
Managed agent sandboxYes — remote Linux, code/web/filesTool runtime, no full sandboxNo native sandboxYes (AWS only)
Background async executionYes (background=True)LimitedClient-managedYes
Multimodal tool combinationYes (single endpoint)PartialYes (client-orchestrated)Partial
MCP compatibilityYesEmergingYesLimited
Portable across clouds / on-deviceYes (incl. Foundation Models framework)NoPartialNo (AWS-locked)
Default reference agentAntigravityNoneNoneNone
The portability angle is the quiet killer: Bedrock Agents are excellent but AWS-locked. Google's sandbox is callable from any cloud — and, via Apple's Foundation Models framework, from on-device. That's a different competitive posture entirely.
What Is It, In Plain Language (For Non-Engineers)
If you run a business and someone just told you to 'look at the Interactions API,' here's the no-jargon version.
Think of an AI agent as a digital assistant that can read, write, browse the web, run calculations, and remember your past conversations. Until now, hiring that assistant meant your developers had to build the assistant's memory, its filing system, and its ability to keep working while you stepped away — all from scratch, every time. The Interactions API is Google supplying all three for you. You give it instructions; Google's servers handle the memory, the workspace, and the background work. Your developers write product features instead of plumbing.
How It Works (Plain-Language Mechanism)
One sentence: you send a request, Google's servers run the agent in a secure cloud workspace, remember everything for next time, and hand back the result — even if the task took several minutes and you closed your browser.
Before vs. After: The Stateless Agent Debt Collapse
1
**BEFORE — You owned everything**
Custom session store + tool router + async job queue + sandbox hardening + vector DB for chat memory. Five systems, five on-call risks.
↓
2
**AFTER — Google owns the runtime**
One endpoint. Server-side state, managed sandbox, background execution, tool combination — all behind a single stable schema.
↓
3
**RESULT — You ship features, not plumbing**
Engineering time shifts from maintaining orchestration glue to building actual product. The debt is paid off.
The before/after shows why this is a strategic shift, not a feature: it relocates the maintenance burden from your team to Google's infrastructure.
What It Means for Small Businesses
Opportunity: A two-person startup can now ship a stateful, web-browsing, code-running agent without hiring a platform engineer. Example: a small e-commerce shop builds a support agent that remembers a customer's past orders (server-side state), looks up live shipping info (web browsing in the sandbox), and drafts a refund — running in the background while staff handle other tickets. That used to be a multi-month platform build. Now it's a weekend.
Risk: Vendor lock-in. Your conversation history and agent context live on Google's servers. If you're in a regulated industry — healthcare, finance, anything with data sovereignty requirements — confirm data residency before storing customer data in persisted interactions. This isn't theoretical. I've seen teams discover this in a security review three weeks before launch.
The Interactions API just turned 'build an AI agent' from a six-engineer platform project into a weekend feature. That's the actual headline for small businesses.
Who Are Its Prime Users
Seed-to-Series-B startups moving prototype → production in under 30 days, with no platform team to maintain orchestration.
Solo developers and indie hackers who want managed agents without standing up infrastructure — and without an on-call rotation.
Enterprise innovation teams piloting agentic features who need a stable schema they can build on; the beta's breaking changes burned enough people that GA stability is genuinely meaningful here.
Mobile developers targeting iOS/macOS who want on-device and cloud Gemini to share one contract via Apple's Foundation Models framework.
How To Use It: A Worked Demonstration
One concrete example, end to end. Real input, each step, the actual output shape.
Goal: Ask a Managed Agent to audit a website for broken links in the background.
python — worked demo: background link audit
INPUT
run = client.interactions.create(
agent='antigravity',
input='Crawl https://example-shop.com and list every broken (404) link.',
background=True # do not block the client
)
print(run.id)
OUTPUT (step 1): interaction_8f3a... (a handle, returned instantly)
STEP 2: agent runs in the sandbox — browses, follows links, logs status codes
STEP 3: poll for completion
result = client.interactions.retrieve(run.id)
print(result.status)
OUTPUT (step 3): 'completed'
print(result.output)
OUTPUT (final):
[
{'url': '/products/old-sku-12', 'status': 404},
{'url': '/blog/2024-sale', 'status': 404}
]
Notice what you did not write: no crawler, no job queue, no headless browser setup, no status-code parser. The sandbox and background execution handled all of it. That's the Stateless Agent Debt being paid off in real time — not as a concept, but as lines of code you didn't write and won't maintain. If you want pre-built starting points, our agent library ships reference implementations you can fork instead of writing this scaffolding yourself.
Good Practices and Common Pitfalls
Do keep pure generative, single-turn calls on the inference path — don't pay agent overhead for stateless work.
Do use background=True for anything over a few seconds; never block users on long agent runs.
Do pin to the GA stable schema and read changelogs — beta instability previously caused breaking changes in production pipelines, and schema drift is how you lose a Friday afternoon.
Don't store regulated data in persisted interactions before confirming residency.
Don't delete your human-in-the-loop layer if you have compliance gates — that primitive isn't first-class in this API yet.
Don't keep a vector DB solely for chat memory. That's now redundant cost.
Average Expense To Use It
Pricing is token-based following Gemini's model, plus per-task pricing for background-execution jobs. Because tiers shift, the only correct source is the live Google AI pricing console. Here's the realistic total-cost-of-ownership framing:
Free/prototype tier: Google AI Studio offers free-tier access for testing — use it to validate before committing real budget.
Token cost: standard Gemini per-token rates for model inference (check the console for current Gemini 3 Pro tiers; these move).
Background jobs: additional per-task pricing — budget for these separately if you're running long agents at any volume.
TCO win: the real saving is infrastructure you stop running. A self-hosted vector store plus job queue plus sandbox can cost a small team well into four figures monthly in compute and engineering time. Retiring that stack is where the ROI actually lives, not the token bill.
For most teams the headline isn't the token bill — it's the deleted infra. A managed sandbox plus server-side state can retire a multi-thousand-dollar/month self-hosted orchestration stack, before you even count the engineering hours saved.
Industry Impact: What the Interactions API Changes for AI Development
The death of the boilerplate orchestration layer
Frameworks like LangGraph, AutoGen, and CrewAI face real commoditization pressure on their core value proposition — state and execution management — as Google absorbs it into the API layer. They don't disappear. They retreat to advanced control, compliance-sensitive patterns, and cross-provider use cases where the abstraction isn't enough. That's a smaller market than 'everyone building Gemini agents,' and the framework teams know it.
RAG and vector database usage patterns shift
RAG architectures on external vector databases stay fully relevant for retrieving private enterprise data — but conversational memory and session context no longer require a vector store. The line between 'retrieval' and 'memory' finally splits cleanly, which means you can right-size your stack instead of throwing a vector DB at every stateful problem.
Impact on the Google ADK ecosystem
The Google Agent Development Kit (ADK) now integrates directly with the Interactions API — creating a closed-loop development-to-deployment pipeline. Build in ADK, deploy through the unified endpoint, no translation layer in between. That tightness matters for iteration speed.
Apple and mobile AI: the Foundation Models framework
Apple's Foundation Models framework on iOS/macOS can call cloud-hosted Gemini via the Interactions API, with Xcode integration — unifying on-device and cloud agent development under one contract for the first time. That's the foundation for persistent agents that genuinely hand off between phone and cloud without rewriting the state layer twice.
Expert and Community Reactions: What Developers Are Saying
Launch-day developer response
Early analysis — including a widely-shared Medium breakdown by #TheGenAIGirl — flagged that stateful multi-turn interactions are now genuinely production-ready. That framing matters: it's a signal the feature shipped with enterprise-grade stability rather than as a beta toy dressed up in a GA announcement.
Critical perspectives
Community concern centers on vendor lock-in: server-side state on Google infrastructure raises data residency and portability questions for regulated industries. Coverage of the launch repeatedly called out the stable schema as the most developer-requested feature — which tells you everything about how much pain the beta's breaking changes caused in production. When 'it doesn't change unexpectedly' is the most celebrated feature, you know teams got burned.
The gap reviewers identified
The clearest critical gap: the Interactions API does not yet expose human-in-the-loop approval checkpoints as a first-class primitive. Teams building compliance-sensitive agents still need LangGraph or custom middleware for that. This isn't a minor omission — it's the reason several enterprise teams I've talked to are running a hybrid stack rather than migrating fully.
The most telling reaction wasn't excitement about agents — it was relief about a stable schema. That tells you how much pain the beta's breaking changes caused in production.
The migration debate in action: teams weighing the Stateless Agent Debt of their existing LangGraph and AutoGen stacks against Google's server-managed runtime.
What Comes Next: Roadmap Signals and Bold Predictions
Confirmed upcoming features
Gemini Omni is explicitly listed as 'soon' in the GA post. Full stop — that's confirmed. And Antigravity being framed as the default agent strongly implies a growing roster of pre-built agents; a marketplace pattern analogous to the OpenAI GPT Store is the obvious trajectory, though that's prediction, not confirmation from the announcement text.
2026 H2
**Gemini Omni lands; pre-built agent catalog grows**
Grounded in the GA post's 'Gemini Omni (soon)' and Antigravity being labeled the default — signaling more managed agents to follow.
2027 Q1
**60%+ of new Gemini agent projects use Interactions API exclusively**
Google defaulting all docs and 3P SDKs to the API removes the path of least resistance for legacy patterns; greenfield projects follow the default.
2027 H1
**Stateless Agent Debt becomes a standard audit item**
As migration ROI gets quantified, engineering reviews will track lines of redundant state code the way they track tech debt today.
2027 H2
**First mainstream on-device-to-cloud agent handoff**
Apple Foundation Models framework + Interactions API sharing one contract makes persistent consumer-hardware agents viable.
What to build right now
Audit your existing state-management code, measure your Stateless Agent Debt surface area, and scope a migration sprint before the ecosystem standardizes around the API and you're playing catch-up. For enterprise AI teams: start with low-risk autonomous workloads, and keep your compliance gates exactly where they are until the API grows first-class support for them. If you need AI automation patterns to model the migration against, we cover the playbooks in depth. Builders shipping production agents should also bookmark our agent library for ready-to-fork reference implementations, and study how agentic AI patterns mature alongside the new endpoint.
The full architectural picture before the FAQ: one unified endpoint absorbing state, sandboxed agents, and async execution — the systems view of why this is a primary interface, not a feature.
Frequently Asked Questions
What is the Interactions API and how is it different from the existing Gemini API?
The Interactions API is Google's primary, unified endpoint for both Gemini models and agents, confirmed GA in June 2026 on blog.google. The key difference: the prior Gemini API required you to manage conversation state, tool routing, and async jobs in client code. The Interactions API moves all of that server-side. Pass a model ID for inference, an agent ID for autonomous tasks, and set background=True for long-running work. It also adds Managed Agents (sandboxed execution), multimodal tool combination, and a stable schema. In short: you write a few lines of code instead of a state graph, and Google's infrastructure owns the memory and execution lifecycle.
Is the Interactions API generally available and how do I get access in 2026?
Yes — Google announced general availability on June 26, 2026. The public beta launched December 2025. Access is through the Google AI for Developers portal and Google AI Studio. API key setup is unchanged from the prior Gemini API, so if you already have a key, you have access. All Google documentation now defaults to the Interactions API, and Google is working with ecosystem partners to make it the default across third-party SDKs and libraries. Start on the free tier in AI Studio to test, then move to token-based pricing for production. Confirm current model tiers and any per-task background-execution costs in the Google AI pricing console.
How does the Interactions API handle server-side state and conversation memory?
Server-side state means conversation history, tool-call results, and agent context persist on Google infrastructure rather than in your client code. You reference a persisted interaction by ID, and Google holds the thread — so you can resume the same conversation later without rehydrating context yourself. For basic multi-turn agents, this eliminates the need for an external session store or a vector database used purely for memory. The practical impact: you stop maintaining a Redis session layer or pgvector instance just to remember recent turns. Note the trade-off — because state lives on Google's servers, regulated industries should confirm data residency and portability before storing sensitive data in persisted interactions. Vector databases remain relevant for private document retrieval (RAG), just not for conversational memory.
What are Managed Agents in the Interactions API and how do I deploy one?
Managed Agents let a single API call provision a remote Linux sandbox where an agent can reason, execute code, browse the web, and manage files — with no self-hosted infrastructure. The Antigravity agent ships as the default reference, and you can define custom agents with instructions, skills, and data sources. To deploy: specify an agent ID (e.g. antigravity) plus your instructions and tools in the request body; add background=True for long-running tasks. The sandbox isolation means the riskiest part of autonomous agents — arbitrary code execution — runs in Google Cloud, not your environment. You retrieve results by interaction ID. For reference patterns, explore curated examples and adapt them to your data sources rather than building agent runtimes from scratch.
How does the Google Interactions API compare to the OpenAI Assistants API?
The OpenAI Assistants API pioneered server-side threads and tool state in 2023. The Interactions API matches that server-side state model and extends it with a fully Managed Agent sandbox (code execution, web browsing, file management), native multimodal tool combination, and explicit background async execution via background=True. A key differentiator is portability: Google's sandbox is callable from any cloud and, via Apple's Foundation Models framework, on-device — whereas the Assistants API is OpenAI-hosted. Both reduce orchestration boilerplate dramatically. Choose based on your model preference, your portability needs, and whether you need a managed Linux sandbox for autonomous code execution, which is a stronger fit for Google's offering as of June 2026.
Can I use the Interactions API with existing OpenAI SDK code?
Yes — OpenAI library compatibility is part of the Gemini ecosystem. Redirecting an existing OpenAI SDK integration to Gemini typically means updating three things: the base URL (point it at the Gemini/Interactions endpoint), the API key, and the model name. This lets teams trial Gemini without rewriting application logic. However, advanced Interactions API features — Managed Agents, background execution, server-side state references — go beyond the OpenAI SDK surface, so to use them fully you'll adopt the native Interactions API patterns. The recommended path: do the three-line swap for a quick proof-of-concept, then migrate the agentic, stateful portions to native calls. Always verify the current compatibility surface in the official Gemini API compatibility docs before moving production traffic.
What is background execution in the Interactions API and when should I use it?
Background execution lets you set background=True on any call, after which Google's server runs the interaction asynchronously. Your client gets an interaction ID immediately and can disconnect; the work continues server-side. Use it for anything long-running — multi-step research, web crawling, large code-execution tasks, or batch processing — where you don't want users blocked on a spinner. It decouples user-facing latency from actual agent work duration. The practical benefit is that it deletes an entire category of infrastructure: the job queue and polling system teams used to build to handle async agent work. Retrieve results later by interaction ID, with server-side state preserving the full context. For short, interactive calls under a few seconds, skip background mode and stay synchronous for simplicity.
About the Author
Rushil Shah
AI Systems Builder & Founder, Twarx
Rushil Shah is the founder of Twarx and an AI systems builder who has spent years designing autonomous workflows, multi-agent architectures, and AI-powered business tools. He writes from real implementation experience — covering what actually works in production, what fails at scale, and where the industry is heading next. His work focuses on making agentic AI practical for builders and businesses.
LinkedIn · Full Profile
This article was originally published on Twarx. Follow for daily deep dives on AI agents and automation.
Top comments (0)