Originally published at twarx.com - read the full interactive version there.
Last Updated: June 25, 2026
Google did not just ship a new API on June 23, 2026 — it quietly made an entire category of middleware obsolete. The Interactions API Gemini models agents endpoint reached general availability, and if you're still routing Gemini calls through LangGraph or CrewAI for state management and tool dispatch, you're paying an orchestration tax that the Interactions API now eliminates entirely.
The Interactions API — Google's new single unified endpoint for Gemini models and agents — reached general availability with server-side state, background execution, Managed Agents, and native multimodal generation. It's now the primary interface, replacing the legacy generateContent endpoint.
By the end of this article you'll understand exactly what changed, how to migrate a stateless pipeline to a stateful agentic one, and when third-party orchestration still earns its keep. If you're new to the broader space, our primer on what AI agents actually are is a useful companion read.
The Interactions API GA announcement — a single unified endpoint for Gemini models and agents with server-side state, background execution, tool combination and multimodal generation. Source: blog.google
Coined Framework
The Orchestration Collapse Layer — the point at which a foundation model provider absorbs enough infrastructure primitives (state, memory, tool dispatch, background execution) that external orchestration frameworks lose their primary value proposition for same-platform workloads
It names the moment middleware stops being a moat. When the platform itself manages conversation state, tool dispatch, sandboxed execution, and async jobs, the orchestration framework you bolted on becomes pure overhead for single-provider workloads.
What Google Announced: The June 23, 2026 GA Release
Official announcement timeline and sources
On June 23, 2026, Google announced via the official blog.google post titled 'Interactions API: our primary interface for Gemini models and agents' that the Interactions API had reached general availability. The post is authored by Ali Çevik, Group Product Manager at Google DeepMind, and Philipp Schmid, Developer Relations Engineer at Google DeepMind. The headline fact is unambiguous: this is now Google's primary API for interacting with Gemini models and agents.
What changed from preview to general availability
The Interactions API launched in public beta in December 2025. According to the announcement, it 'quickly become developers' favorite way to build applications with Gemini.' The GA release brought two structural changes: a stable schema — breaking schema changes now follow a versioned deprecation policy — and several net-new capabilities developers explicitly asked for: Managed Agents, background execution, and Gemini Omni (described as coming soon). You can review the underlying model family on the official Gemini API documentation.
Key dates: preview launch, stable schema, GA declaration
The timeline is short and decisive: public beta in December 2025, GA declared June 23, 2026. The official post states that 'all of our documentation now defaults to Interactions API' and that Google is 'working with ecosystem partners to make it the default interface across 3P SDKs and Libraries.' This isn't a soft launch. It's a category reset — the kind we last saw when function calling first went mainstream.
When a hyperscaler retires its primary inference endpoint and rebuilds documentation around a stateful agent API, that is not a product update. That is the platform telling you the stateless era is over.
Dec 2025
Interactions API public beta launch
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
Jun 23, 2026
General availability declared
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
1
Unified endpoint for models AND agents
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
What the Interactions API Is: A Technical Definition
From stateless text generation to stateful agentic sessions
The Interactions API is a single unified endpoint supporting server-side state, background execution, tool combination, and multimodal input/output. One endpoint, whether you want a quick model inference or a long-running autonomous agent. As the announcement puts it: 'whether you're calling a model or running an agent, the Interactions API gets you there in a few lines of code. Pass a model ID for inference, an agent ID for autonomous tasks, set background=True for anything long-running.'
Contrast that with the legacy generateContent REST call, which was purely stateless. Each call was context-free — you had to re-inject the entire conversation history on every turn, or hand that responsibility to middleware like LangGraph. That added latency, token cost, and operational overhead. I've watched teams burn 30–40% of their token budget on nothing but context re-injection. The Interactions API kills that pattern.
The Orchestration Collapse Layer: what Google has absorbed
This is where our coined framework earns its name. Before the Interactions API, external orchestration frameworks rested on four pillars: managing state, persisting memory, dispatching tools, and coordinating agent execution. Google has now absorbed all four into the platform.
Coined Framework
The Orchestration Collapse Layer in practice
When state, memory, tool dispatch, and sandboxed execution all live inside the provider's endpoint, the external framework collapses into a thin wrapper. For same-platform Gemini workloads, that wrapper now adds latency without adding capability.
How server-side state differs from client-managed context windows
Server-side state means conversation history, tool results, and intermediate outputs persist on Google infrastructure. You initiate a session, get back a session reference, and every subsequent turn references that ID — no client-side history injection required. The difference is architectural. Client-managed context means your app is the source of truth and must serialize the full window on every request. Server-side state means Google holds it, and you send deltas. We unpack this trade-off further in our guide to agent memory architectures.
The hidden cost of stateless APIs isn't latency — it's the token bill. Re-injecting a 30-turn conversation on every call can 10x your input-token spend before the model has generated a single new word. Server-side state kills that tax.
The architectural shift the Orchestration Collapse Layer describes: from client-managed context re-injection to server-side stateful sessions on Google infrastructure.
Stateless generateContent vs Stateful Interactions API — the request flow
1
**Legacy: generateContent (stateless)**
Client serializes the ENTIRE conversation history + tool results on every turn. Input tokens grow linearly with conversation length. No memory of prior calls server-side.
↓
2
**Middleware tax (LangGraph / CrewAI)**
External framework stores history, manages tool dispatch, retries failures. Adds a network hop and operational surface you must monitor and pay for.
↓
3
**Interactions API: interactions.create()**
Single call returns a session_id. State, tool results and intermediate outputs persist on Google infrastructure. Subsequent turns reference the ID — send deltas, not the whole window.
↓
4
**background=True (async execution)**
Long-horizon agent tasks run asynchronously server-side, escaping the 60-second HTTP timeout ceiling. Results post back on completion.
The sequence matters: every layer of middleware you remove is a layer of latency, cost and failure you no longer own.
Full Capability Breakdown: Every Feature at GA
Server-side state and multi-turn session management
The foundational capability. Conversation history, tool results, and intermediate outputs persist on Google infrastructure. This eliminates the most common source of bugs in production agent systems: context drift caused by inconsistent client-side history management. I've seen this exact bug derail three separate production launches — teams spent weeks debugging what was, ultimately, a history serialization race condition. Server-side state makes that class of failure someone else's problem.
Background execution and async agent tasks
Setting background=True on any call makes the server run the interaction asynchronously. This is critical for long-horizon agentic workflows that exceed standard 60-second HTTP timeouts. Fire-and-forget agent tasks run server-side and post results to a callback — the difference between an agent that can browse 40 web pages and one that times out at page 6.
Tool combination: function calling, code execution, grounding
The Interactions API lets you mix built-in tools. Function calling, Google Search grounding, and code execution can all be registered simultaneously within a single session. Previously these often required separate API configurations — not a disaster, but the kind of friction that turns a one-day integration into a three-day one.
Multimodal support: audio, video, text, and images in one session
Multimodal sessions can combine continuous audio streams (the Gemini Live API substrate), video frames, text, and images within a single stateful session context. Gemini Omni is named in the announcement as a coming-soon capability that deepens this further.
Managed Agents: sandboxed cloud execution with Antigravity
This is the headline net-new GA feature. Per the official post: 'A single API call provisions a remote Linux sandbox where an agent can reason, execute code, browse the web and manage files. The Antigravity agent ships as the default, and you can define your own custom agents with instructions, skills and data sources.'
Managed Agents is the feature that should worry the orchestration-framework vendors most. Sandboxed cloud execution with file management and web browsing was the single hardest piece of self-hosted agent infrastructure to build. Google now provisions it in one API call.
Latency, cost, and fidelity control parameters
Gemini 3 introduced explicit parameters letting developers dial the compute-versus-latency trade-off — a 'level of thinking' control surface largely absent from competitor API surfaces. You can numerically tune how much reasoning budget a task gets, rather than choosing between coarse model tiers. That's a meaningful operational lever, and one I expect every serious production team to start using immediately. We cover tuning strategy in our piece on reasoning cost optimization.
The battleground in AI has moved. It is no longer who has the smartest model — it is who makes the agent infrastructure disappear. Google just made a lot of plumbing disappear.
[
▶
Watch on YouTube
Google DeepMind: building stateful agents with the Interactions API
Google DeepMind • Gemini agent architecture
](https://www.youtube.com/results?search_query=Google+DeepMind+Interactions+API+Gemini+agents)
How to Access and Use the Interactions API: Step-by-Step
Prerequisites: Google AI Studio account and API key
The Interactions API is available via Google AI Studio and Vertex AI, with GA on both surfaces as of June 23, 2026. Start by generating an API key in Google AI Studio. Straightforward — no surprises there.
SDK versions supporting Interactions API
Full support — including Managed Agents — requires the Python SDK v2.0+ or Node.js SDK v1.8+. The official documentation now defaults to Interactions API, so standard quickstart paths route through it automatically. If you build with Google's Agent Development Kit (ADK), the SDK uses the Interactions API as its transport layer without any additional configuration.
Starting a stateful session: minimal working code
Python — minimal stateful session
Requires google-genai SDK v2.0+
from google import genai
client = genai.Client(api_key='YOUR_API_KEY')
Start a stateful session — returns a session reference
session = client.interactions.create(
model='gemini-3-pro',
input='Summarise our Q2 churn drivers.'
)
print(session.session_id) # persist this; no history re-injection needed
Next turn references the session_id — send only the delta
follow_up = client.interactions.create(
session_id=session.session_id,
input='Now draft a retention email for the top driver.'
)
print(follow_up.output_text)
Registering tools and enabling background execution
Python — tools + background execution
Combine Google Search grounding + code execution + background run
job = client.interactions.create(
model='gemini-3-pro',
input='Research 2026 SaaS churn benchmarks and build a chart.',
tools=['google_search', 'code_execution'],
background=True # escapes the 60s HTTP timeout ceiling
)
Poll or receive callback when the async job completes
result = client.interactions.get(job.session_id)
print(result.status) # 'running' -> 'completed'
Deploying a Managed Agent with Antigravity
Python — Managed Agent in a sandbox
One call provisions a remote Linux sandbox running the Antigravity agent
agent_run = client.interactions.create(
agent_id='antigravity', # default Managed Agent
input='Clone this repo, run the test suite, summarise failures.',
background=True
)
The agent can reason, execute code, browse the web and manage files
inside an isolated cloud sandbox — no container infra to self-manage.
Need ready-made agent blueprints to adapt? You can explore our AI agent library for patterns that map cleanly onto Managed Agents, and our production agent checklist for hardening them before launch.
Pricing model and quota tiers at GA
Pricing at GA follows a per-token model consistent with the Gemini 2.5 Pro and Flash tiers. Background execution jobs are billed by compute-second in addition to token cost — that second line item is the one that'll surprise you if you're running heavy Managed Agent workloads, so budget for it explicitly. Exact figures are published in the Google AI pricing console. Apple developers can now access Gemini via the Foundation Models framework and Xcode, with the Interactions API available as a cloud-hosted backend per the June 23 announcement.
A single interactions.create() call provisions a sandboxed Managed Agent — the operational simplicity that defines the Orchestration Collapse Layer in production.
When to Use Interactions API vs Alternatives
Interactions API vs legacy generateContent
Use the Interactions API for any multi-turn, tool-using, or long-horizon agentic workflow on Gemini. It's now the Google-recommended default replacing generateContent. The only reason to stay on generateContent is a single-shot, stateless inference where you genuinely never need history — and even there, the migration cost is trivial. I wouldn't stay on the legacy endpoint for any new project starting today.
Interactions API vs Gemini Live API
The Gemini Live API is the right choice for continuous low-latency audio/video streaming — think sub-200ms voice response. The Interactions API is optimised for higher-level session management, not raw stream processing. They're complementary: Live handles the stream substrate; Interactions handles the stateful session orchestration around it.
Interactions API vs Agent Development Kit (ADK)
ADK sits above the Interactions API and uses it as the transport layer. Build with ADK and you automatically get server-side state and background execution without making direct API calls. ADK is the framework; Interactions API is the engine under the hood.
When LangGraph, CrewAI, or n8n still add value
This is the nuance that gets lost in the hype. LangGraph and CrewAI retain genuine value for multi-model orchestration — combining Gemini with Claude or GPT-4o — cross-platform RAG pipelines with external vector databases, and complex human-in-the-loop approval workflows the Interactions API doesn't yet natively support. n8n is a different animal entirely — it's a workflow automation UI for no-code/low-code integration with non-AI business systems, not a developer primitive. Those use cases didn't collapse. They just got narrower.
The Orchestration Collapse Layer is provider-specific, not universal. The instant your architecture spans two model providers, external orchestration regains its moat. Single-vendor lock-in is the precondition for collapse.
Interactions API vs Closest Competitors: Honest Comparison
vs OpenAI Assistants API
OpenAI's Assistants API introduced server-side threads and file storage in 2023. The Interactions API matches this with server-side state but adds native background execution and multimodal sessions that Assistants API still lacks at parity. It's a closer race than Google's marketing implies — but on background async execution and sandboxed agents, Interactions API is genuinely ahead at this moment.
vs Anthropic Claude API with MCP
Anthropic's Model Context Protocol (MCP) is an open interoperability standard for tool calling across models. The Interactions API is a proprietary Google endpoint — but the two aren't mutually exclusive. Google supports MCP tool definitions within Interactions API sessions, which is a meaningful hedge against lock-in concerns and worth paying attention to as MCP adoption grows.
vs LangGraph Server
LangGraph Server provides stateful agent graphs with human-in-the-loop checkpointing — still more capable than the Interactions API for branching, conditional, and parallel agent graphs. The Interactions API is simpler but covers roughly 80% of production use cases with far less operational overhead. If your agent needs a complex approval flow with multiple conditional branches, don't rip out LangGraph yet.
vs AutoGen Studio
Microsoft's AutoGen provides a multi-agent conversation framework but requires self-managed infrastructure. The Interactions API offloads that infrastructure to Google Cloud, cutting DevOps burden at the cost of vendor lock-in. Honest trade-off, and neither side is obviously wrong depending on your team's situation.
CapabilityInteractions API (Google)OpenAI Assistants APIAnthropic + MCPLangGraph Server
Server-side stateYesYes (threads)Partial (client-led)Yes (checkpoints)
Background / async executionYes (background=True)LimitedSelf-managedYes
Sandboxed managed agentsYes (Antigravity)Code interpreter onlySelf-managedSelf-managed
Native multimodal sessionYes (audio/video/text/image)PartialPartialVia underlying model
Human-in-the-loop checkpointNot yet nativeNoManualYes (core strength)
Multi-provider orchestrationNo (Gemini-only)NoMCP cross-modelYes
Infra you self-manageNoneMinimalSignificantSignificant
The key differentiator: the Interactions API is the only GA offering combining server-side state + background execution + Managed Agent sandboxing + multimodal in a single endpoint from a hyperscaler as of June 2026.
Industry Impact: What the Interactions API GA Means for AI Development
The death of the stateless API paradigm
The GA of the Interactions API signals that hyperscalers are competing on infrastructure primitives, not just model quality. The battleground has moved to developer experience and platform stickiness. The stateless generateContent paradigm — where every call was an island — is being retired by its own creator. That's a strong signal about where the whole industry is heading, not just Google.
Implications for the orchestration framework market
Third-party orchestration vendors — LangChain, LangGraph, CrewAI, AutoGen — face a genuine strategic squeeze. As Gemini, OpenAI Assistants, and future Anthropic offerings absorb more orchestration primitives, the addressable problem for single-provider middleware shrinks. The survivors will be the ones that lean hard into multi-agent, multi-provider orchestration where the Collapse Layer can't reach.
Impact on enterprise procurement and vendor lock-in
Enterprise AI architects now have to evaluate the total cost of orchestration seriously. A LangGraph-on-GCP architecture versus native Interactions API may carry a 30–60% different operational cost profile depending on session volume and tool-call frequency. The trade is operational savings now versus portability risk later — server-side state stored on Google infrastructure doesn't trivially migrate to Azure OpenAI or Anthropic. Make that call with your eyes open.
The Apple developer ecosystem expansion
The Apple/Gemini integration via the Foundation Models framework and Xcode opens the Interactions API to the iOS/macOS developer base — an estimated 34 million registered Apple developers as of 2025. Worth noting: RAG pipelines built with external vector databases like Pinecone, Weaviate, or ChromaDB are not replaced here. Retrieval remains a developer responsibility unless you're using Google's native Search grounding tool.
34M
Registered Apple developers reachable via Foundation Models
[Apple, 2025](https://developer.apple.com/)
30–60%
Potential operational cost delta: native vs middleware
[Google AI Pricing, 2026](https://ai.google.dev/pricing)
80%
Production use cases covered without external orchestration
[Practitioner estimate, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
What It Means for Small Businesses
For a small business, the Interactions API quietly removes the most expensive part of building an AI agent: the engineering team you used to need to wire up state, memory, and tool execution. A 3-person SaaS startup can now ship a customer-support agent that remembers prior tickets, browses your knowledge base, and runs overnight batch tasks — without standing up a single container or hiring an infra engineer. Our walkthrough on building customer-support agents maps these patterns step by step.
Concrete example: a boutique e-commerce shop builds a returns-handling agent. With Managed Agents, one API call provisions a sandbox where the agent reads the order, checks policy, drafts the refund email, and logs the outcome — work that previously needed a developer to chain together LangGraph, a vector store, and a job queue. The opportunity is a potential $40K–$80K annual saving on the engineering and ops overhead of self-hosted agent infrastructure.
The risk: vendor lock-in. If your entire agent state lives on Google infrastructure and you later want to switch providers, migration is non-trivial. Keep your prompts, business logic, and data in your own systems so the agent layer stays swappable. Browse our agent templates for portable patterns that hedge this risk.
How It Works: The Mechanism in Plain Language
Think of the old way as mailing a letter that contains the entire conversation transcript every single time you want to add one sentence. The Interactions API is more like a phone call that stays connected — you say your new line, and the other side already remembers everything said so far. That memory lives on Google's servers, not in your app.
The Interactions API agent lifecycle — from request to async result
1
**Developer issues interactions.create()**
Passes a model ID (inference) or agent ID (autonomous task). Optionally sets background=True and registers tools.
↓
2
**Google provisions session + (optional) sandbox**
Server-side state initialised. For Managed Agents, a remote Linux sandbox spins up running Antigravity or your custom agent.
↓
3
**Agent reasons + dispatches tools**
Function calling, Google Search grounding, code execution and file management run inside the session. Intermediate results persist server-side.
↓
4
**Result returned or posted to callback**
Synchronous calls return inline. Background jobs post to a callback on completion — escaping HTTP timeout limits for long-horizon tasks.
The full lifecycle: one endpoint handles inference, stateful sessions, sandboxed agents and async execution — the operational core of the Orchestration Collapse Layer.
Who Are Its Prime Users
The Interactions API benefits most: AI engineers migrating production workloads from generateContent to multi-turn pipelines; developer advocates and DevRel teams building reference agent implementations; startups (5–50 people) that need agent capability without an infra team; and enterprise platform teams standardising on Gemini who want to cut self-managed container sprawl. Industries seeing the fastest uptake are SaaS, fintech, customer support, and internal-tools engineering — anywhere long-horizon, tool-using agents create real leverage. For a deeper map of who wins, see our analysis of production-ready agent templates in the Twarx agent library.
A Worked Demonstration: Building a Research Agent
Let's run a real example end to end — a background research agent that grounds itself with Google Search and returns a structured brief.
Input — research agent request
job = client.interactions.create(
model='gemini-3-pro',
input='Find the 3 biggest 2026 AI agent infra announcements '
'and return a 3-bullet brief with sources.',
tools=['google_search'],
background=True
)
print(job.session_id, job.status)
Step output — polling the async job
status transitions: queued -> running -> completed
a1b2c3d4 queued
(a few seconds later)
result = client.interactions.get(job.session_id)
print(result.status)
completed
Actual output — structured brief
{
"brief": [
"Google's Interactions API hit GA (Jun 23, 2026) - unified stateful
endpoint with Managed Agents and background execution.",
"Apple opened Gemini access via the Foundation Models framework
and Xcode, exposing the Interactions API to iOS/macOS developers.",
"Gemini 3 added explicit 'level of thinking' parameters for
numeric compute-vs-latency control."
],
"sources": ["blog.google/.../interactions-api-general-availability"]
}
Total developer code: under 15 lines. No history re-injection, no job queue, no container. That's the collapse in action.
Good Practices
❌
Mistake: Re-injecting full history into stateful sessions
Developers migrating from generateContent often keep sending the whole conversation window even after adopting server-side state — doubling token cost and defeating the entire benefit. I've seen this exact pattern survive code review three times because it looks harmless until the token bill arrives.
✅
Fix: After interactions.create() returns a session_id, send only the new turn's delta. Let Google's server-side state hold the history.
❌
Mistake: Running long-horizon tasks synchronously
Agents that browse multiple pages or run multi-step code routinely blow past the ~60-second HTTP timeout, causing silent failures and partial results. This fails in production in ways that are genuinely hard to debug — you get a timeout, not an error.
✅
Fix: Set background=True for anything that might exceed 60s and poll the session or wire a callback. Reserve synchronous calls for quick interactive turns.
❌
Mistake: Assuming Interactions API replaces your RAG stack
Teams rip out Pinecone or Weaviate expecting the API to handle retrieval — then discover grounding only covers Google Search, not their private corpus. I would not ship this assumption without testing it against your actual data first.
✅
Fix: Keep your vector database for private-data RAG. Use native Search grounding only for public web facts; feed retrieved private context as tool results.
❌
Mistake: Ignoring observability gaps at GA
The Interactions API ships with lighter tracing than dedicated APM tools like LangSmith, so silent agent misbehaviour can go unnoticed in production. The GA docs are thin on this — don't assume the platform has you covered.
✅
Fix: Layer your own structured logging around session_ids and tool calls until native per-session analytics matures. Treat observability as your responsibility, not the platform's.
Average Expense to Use It
Pricing at GA follows a per-token model consistent with the Gemini 2.5 Pro and Flash tiers, with background execution jobs billed by compute-second on top of token cost. A realistic small-team total cost of ownership looks like this:
Free / prototyping: Google AI Studio offers free-tier access for development and testing — enough to validate an agent before any spend.
Light production (single support agent, ~5K sessions/month): token cost typically lands in the low hundreds of dollars/month on Flash-class tiers, plus modest compute-seconds for background runs.
Heavy agentic workloads (Managed Agents browsing/coding): compute-second billing for sandbox time becomes the dominant line item — budget for it explicitly before it surprises you at month-end.
The TCO story versus self-hosting is the headline: eliminating self-managed container infrastructure for sandboxed execution can save an estimated $40K–$80K annually in engineering and DevOps overhead for a small team. Always confirm live figures in the Google AI pricing console before committing. Our AI cost management guide covers how to model this against your own volume.
Expert and Community Reactions to the GA Launch
Developer community response
Medium author #TheGenAIGirl published an 'Interactions API + ADK: A Closer Look' analysis highlighting the stateful multi-turn capability as the most significant shift for production agent developers. The framing across the community is consistent: this is an architectural reset, not a feature drop. Discussion on Hacker News echoed the same read.
Community consensus on architectural significance
AshJo's Google Advent of Agents Day 13 post called the Interactions API 'a fundamental shift from stateless text generation to stateful, autonomous workflows' — reflecting the broad developer read that the value is structural, not incremental. That's the right frame.
The enterprise signal
Enterprise coverage flagged Managed Agents as the headline enterprise feature, noting it addresses the sandboxed-execution gap that previously forced teams to self-manage container infrastructure. For enterprises, closing that gap is the difference between a months-long platform build and a one-call provision.
Outstanding criticisms and known limitations
Community-cited GA limitations: no native human-in-the-loop approval checkpoint (unlike LangGraph), limited observability compared to dedicated APM tools like LangSmith, and background-execution SLAs not yet published. The loudest criticism is vendor lock-in — server-side state on Google infrastructure is not easily portable to Azure OpenAI or Anthropic equivalents. That criticism is legitimate. Don't dismiss it.
Convenience and lock-in are the same coin. Every primitive Google absorbs makes you faster today and more dependent tomorrow. Build with your eyes open.
Developer reaction across X and Medium converged on one theme: the Interactions API marks the end of the stateless paradigm for Gemini agents.
What Comes Next: The Interactions API Roadmap
Signals from the Gemini 3 developer guide
The Gemini 3 Developer Guide references new latency/cost/fidelity parameters, signalling continued investment in developer control surfaces beyond what shipped at GA. The 'level of thinking' control is likely an early instance of a broader tunability roadmap — one worth tracking closely if compute cost is a concern for your workloads.
Expected features: human-in-the-loop, observability, MCP deepening
Managed Agents with the Antigravity sandbox is positioned as a precursor to a Google-hosted agent marketplace — analogous to what the GPT Store attempted, but with enterprise-grade sandboxing. MCP support within sessions suggests Google is hedging between open interoperability and proprietary lock-in, which is the right political move even if the technical implementation is still thin.
The broader Google agent platform vision
The convergence of Interactions API + ADK + Gemini Live API + Apple's Foundation Models represents Google assembling a complete agentic application platform. The generateContent era is definitively over.
2026 H2
**Native human-in-the-loop checkpointing**
Closing LangGraph's last major advantage for Gemini-only workloads. Grounded in community demand and Google's stated pattern of shipping developer-requested features at GA.
2026 H2
**Gemini Omni ships**
Explicitly named as 'soon' in the GA announcement — expect deeper unified multimodal generation within the session context.
2027 H1
**Per-session cost analytics + agent marketplace**
Enterprise billing transparency and a Managed Agents marketplace, extending the Antigravity sandbox model. Grounded in the marketplace positioning of Managed Agents.
2027
**Deeper MCP integration**
As enterprises demand multi-model flexibility, expect Google to lean further into MCP to neutralise the lock-in criticism.
Frequently Asked Questions
What is the Interactions API Gemini models agents endpoint and how does it differ from generateContent?
The Interactions API is Google's single unified endpoint for Gemini models and agents, supporting server-side state, background execution, tool combination, and multimodal input/output. The key difference from the legacy generateContent endpoint is statefulness: generateContent was purely stateless, meaning every call was context-free and you had to re-inject the full conversation history each time. The Interactions API persists conversation history, tool results, and intermediate outputs on Google infrastructure. You initiate a session with interactions.create(), receive a session_id, and reference it on subsequent turns — sending only the delta. It reached GA on June 23, 2026 and is now Google's primary, recommended interface, with all official documentation defaulting to it.
When did the Interactions API reach general availability?
The Interactions API reached general availability on June 23, 2026, announced via the official blog.google post 'Interactions API: our primary interface for Gemini models and agents', authored by Ali Çevik (Group Product Manager, Google DeepMind) and Philipp Schmid (Developer Relations Engineer, Google DeepMind). It first launched in public beta in December 2025. The GA release brought a stable schema — with breaking changes now following a versioned deprecation policy — plus net-new capabilities including Managed Agents and background execution. It is available on both Google AI Studio and Vertex AI as of the GA date, and Google has stated it is working with ecosystem partners to make it the default interface across third-party SDKs and libraries.
What are Managed Agents in the Interactions API and how do I use them?
Managed Agents is the headline net-new GA feature. A single API call provisions a remote Linux sandbox where an agent can reason, execute code, browse the web, and manage files. The Antigravity agent ships as the default, and you can define custom agents with your own instructions, skills, and data sources. To use it, call interactions.create() with agent_id='antigravity' (or your custom agent ID), pass the task as input, and typically set background=True for long-running work. The benefit is operational: sandboxed execution with file management and web browsing was previously the hardest piece of self-hosted agent infrastructure to build. Managed Agents removes that entirely, provisioning enterprise-grade isolated compute on demand with no container infrastructure for you to manage.
Does the Interactions API replace LangGraph or CrewAI for building Gemini agents?
For single-provider Gemini workloads, it largely does — this is what we call the Orchestration Collapse Layer. The Interactions API absorbs state, memory, tool dispatch, and sandboxed execution, eliminating the core reasons you previously needed LangGraph or CrewAI for Gemini-only pipelines. However, those frameworks retain genuine value in three scenarios: multi-model orchestration (combining Gemini with Claude or GPT-4o), cross-platform RAG pipelines using external vector databases like Pinecone or Weaviate, and complex human-in-the-loop approval workflows the Interactions API does not yet natively support. The decision rule is simple: single Gemini provider plus standard agentic patterns means use Interactions API natively; multi-provider or advanced branching graphs means keep your orchestration framework.
How does the Interactions API compare to OpenAI's Assistants API?
OpenAI's Assistants API pioneered server-side threads and file storage back in 2023, and the Interactions API matches that server-side state model. Where the Interactions API pulls ahead at GA is native background execution (background=True for long-horizon async tasks) and native multimodal sessions combining audio, video, text, and images — capabilities Assistants API still lacks at parity. The Interactions API also ships Managed Agents with full Linux sandboxes for code execution, web browsing, and file management, going beyond OpenAI's code interpreter. The trade-off is symmetrical vendor lock-in: both store state on the provider's infrastructure, so neither is trivially portable. Google additionally supports MCP tool definitions within sessions, offering a partial interoperability hedge that the Assistants API does not natively emphasise.
What is the pricing model for the Interactions API at GA?
Pricing at GA follows a per-token model consistent with the existing Gemini 2.5 Pro and Flash tiers. The important addition is that background execution jobs are billed by compute-second in addition to token cost — so long-running Managed Agent tasks that browse the web or run code accrue sandbox compute charges on top of inference tokens. Exact figures are published in the Google AI pricing console. Google AI Studio offers a free tier suitable for prototyping and validation before any spend. For a small team running a single light-production agent at around 5,000 sessions per month, token costs typically land in the low hundreds of dollars monthly on Flash-class tiers. Always confirm live numbers in the pricing console, as compute-second rates for background jobs are the variable most likely to dominate heavy agentic workloads.
Can Apple developers use the Interactions API via the Foundation Models framework?
Yes. Per the June 23, 2026 blog.google announcement, Apple developers can now access Gemini via the Foundation Models framework and Xcode, with the Interactions API available as a cloud-hosted backend. This means iOS and macOS developers can build stateful, tool-using Gemini agents directly within their native development workflow without standing up separate backend infrastructure. The significance is reach: there are an estimated 34 million registered Apple developers as of 2025, and this integration exposes the full Interactions API capability set — server-side state, background execution, Managed Agents, and multimodal sessions — to that ecosystem. For Apple developers, this is the most direct path yet to embedding production-grade agentic features in native apps while offloading the orchestration infrastructure to Google Cloud.
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)