Originally published at twarx.com - read the full interactive version there.
Last Updated: June 27, 2026
Google just made your agent orchestration layer optional — and most teams haven't noticed yet. The Interactions API Gemini models agents release just changed the rules of production AI architecture, turning third-party frameworks into optional add-ons overnight.
On June 27, 2026, Google announced that its Interactions API reached general availability and is now the primary interface for every Gemini model and agent. A single endpoint now carries server-side state, background execution, tool combination, and Managed Agents that run in a Google-provisioned Linux sandbox. The fragmented, model-specific endpoints are done.
By the end of this article you'll know exactly what shipped, how to migrate an OpenAI or LangGraph workflow, what it costs, and whether you should move at all. For a wider view of where this fits, see our guide to AI agents in production.
Coined Framework
The Middleware Collapse Event — the architectural moment when a foundation model provider absorbs orchestration, state management, and tool-routing directly into the API layer, rendering third-party agent frameworks redundant for most production use cases
This is the structural shift the Interactions API triggers: the work you paid LangGraph, AutoGen, and CrewAI to do — holding conversation state, routing tools, running long tasks — moves inside the provider's API. The middleware doesn't die, but it stops being mandatory.
Google's Interactions API is not a developer-experience update — it is a calculated infrastructure takeover that turns LangGraph, AutoGen, and CrewAI into optional add-ons overnight. If you're still routing agent state through your own servers, you're already running legacy architecture.
Google's official launch graphic for the Interactions API general availability — the new single unified endpoint for Gemini models and agents. Source
What Google Announced: Interactions API Official Launch
Announcement date, source, and GA status
Google posted on its official blog that the Interactions API has reached general availability. The public beta launched in December 2025 and, per the announcement, 'has quickly become developers' favorite way to build applications with Gemini.' The GA release ships a stable schema plus a set of capabilities developers explicitly asked for during beta. That last part matters — Google was listening, and you can see it in what landed.
The post was authored by Ali Çevik, Group Product Manager at Google DeepMind, and Philipp Schmid, Developer Relations Engineer at Google DeepMind — both attached directly to the Google DeepMind team that ships the Gemini stack.
Exact official language and positioning from blog.google
The single most consequential line in the announcement: 'the Interactions API is now our primary API for interacting with Gemini models and agents.' That word — primary — isn't casual. Google also stated: 'All of our documentation now defaults to Interactions API and we are working with ecosystem partners to make it the default interface across 3P SDKs and Libraries.' Read that twice. This isn't a feature flag. It's a distribution takeover.
When a foundation-model provider says its new surface is the 'default interface across 3P SDKs and Libraries,' they're not describing a feature. They're describing a distribution strategy aimed directly at the orchestration middle layer.
What changed from the previous Gemini API surface
Before GA, building with Gemini meant juggling model-specific endpoints, holding conversation history yourself, and bolting on a framework like LangGraph for state and orchestration. The Interactions API collapses that into one canonical endpoint where you pass a model ID for inference, an agent ID for autonomous tasks, and set background=True for anything long-running. New since December: Managed Agents, background execution, Gemini Omni (soon), and tool improvements. That's not incremental. That's the whole stack shifting. If you're choosing a framework today, our AI agent frameworks comparison puts these options side by side.
Dec 2025
Interactions API public beta launch
[Google Blog, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
1
Unified endpoint for both models and agents
[Google Blog, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
GA
Stable schema with versioned deprecation
[Google AI for Developers, 2026](https://ai.google.dev/)
What the Interactions API Is: Architecture and Core Design
The unified endpoint model explained
The core design is brutally simple: one endpoint surfaces both Gemini models (such as Gemini 3 Pro) and agents (such as Google's native Antigravity agent). As the official post 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.' One request shape. Done.
That collapses two historically separate concerns — stateless inference and stateful agentic execution — behind the same call. You no longer pick an SDK based on whether you're 'doing a chatbot' or 'doing an agent.' That distinction just stopped mattering at the API layer.
Server-side state and what it replaces
This is the feature that detonates the middleware layer. With server-side state, Google holds the conversation history, session continuity, and context window for you. You stop managing session tokens, replaying message arrays, or maintaining a Redis-backed memory store. I've seen teams burn three or four engineers' worth of quarterly time on exactly this problem. The classic reason teams reached for an orchestration framework — 'I need somewhere to keep the agent's state' — evaporates for most use cases. We unpack the patterns this replaces in our breakdown of AI agent memory architectures.
The moment state lives on the provider's side, half of every agent framework's value proposition becomes a convenience wrapper instead of a load-bearing dependency.
How background execution works at the infrastructure level
Set background=True on any call and 'the server runs the interaction asynchronously,' per the official documentation. Practically: you fire a long-horizon task — a multi-step research agent, a code-generation job, a document pipeline — and you don't hold an open HTTP connection waiting for it. The server executes, persists state, and you poll or subscribe for results. This is the capability that long-running agent builders previously hacked together with queues, workers, and websockets. We burned two weeks on that exact plumbing in a previous project. It's not fun work, and now it's Google's problem.
Interactions API Request Lifecycle: From Call to Managed Agent Execution
1
**Client call to single endpoint**
Developer sends one request: model ID (e.g. Gemini 3 Pro) or agent ID (e.g. Antigravity), plus optional background=True. No SDK switching.
↓
2
**Server-side state resolution**
Google retrieves prior conversation/session state automatically. No client-side history array, no token bookkeeping.
↓
3
**Tool combination & routing**
Built-in tools (Search, Code Execution) merge with your custom function calls in a single request. The API routes them.
↓
4
**Managed Agent sandbox (if agent ID)**
A remote Linux sandbox is provisioned where the agent reasons, executes code, browses the web, and manages files.
↓
5
**Sync return or async background**
Short tasks return inline. Long tasks run asynchronously server-side; client polls/subscribes for the result.
The full lifecycle shows why no external orchestration layer is required for standard agentic workloads — state, routing, and execution all live server-side.
The role of the Interactions API in the broader Google ADK ecosystem
The Agent Development Kit (ADK) plugs directly into the Interactions API. Where ADK previously needed a separate orchestration loop, it can now lean on server-side state and Managed Agents as the runtime. The combination — ADK for definition, Interactions API for execution — is the most coherent agentic stack Google has shipped to date. Compare that with assembling multi-agent systems from independent libraries, and the appeal for production teams is obvious. It's not perfect. But it's the first time the pieces actually connect.
Before/after of the Middleware Collapse Event: legacy architecture routes state through your own servers and an orchestration framework; the Interactions API absorbs state, tool-routing, and execution server-side.
Full Capability Breakdown: Every Feature Shipping at GA
Managed Agents: what they are and how they run
Per Google's announcement, '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 instructions, skills and data sources.' Crucially, there is no self-hosted execution environment required — the sandbox is Google-managed. That's the structural difference from running a CrewAI or AutoGen worker on your own infrastructure. No VM to provision. No container to babysit. One call. If you want ready-made building blocks, browse our AI agent library for patterns that map onto Managed Agents.
Tool combination and multimodal input support
The GA release lets you 'mix built-in tools' — Search and Code Execution among them — with custom function calls inside a single request. This eliminates the manual tool-routing orchestration that frameworks like AutoGen traditionally handle. Multimodal generation is part of the unified endpoint, with Gemini Omni flagged as 'soon' in the official post. Not there yet, but close enough to plan around.
Stateful multi-turn interaction model
Because state lives server-side, multi-turn conversations and long-running agent loops persist without client-side replay. This is the stateful primitive that previously forced teams onto LangGraph's checkpointing or a custom session store. If you've built that store yourself, you know exactly how much undifferentiated work it is. Now you don't have to.
The first question to ask before any migration: 'What in my stack exists only to hold state between turns?' If that's most of your middleware, the Interactions API just deleted your reason to maintain it.
Gemini 3-specific parameters: latency, cost, and multimodal fidelity controls
Gemini 3 Pro is callable directly through the unified endpoint, and the broader Gemini 3 family exposes request-level controls so you can trade quality against cost. For builders running high-volume pipelines, per-request fidelity tuning is the difference between a sustainable unit economics model and a runaway bill. I'd verify the exact current parameters on the live Gemini API pricing documentation — these change, and the docs don't always keep up with the dashboard.
Stable schema and what developer-requested features shipped
The headline GA guarantee is the stable schema: breaking changes now follow a versioned deprecation cycle — a first for the Gemini API. For production teams, this is worth more than any single feature on the changelog. It converts 'we might have to rewrite our integration next quarter' into a predictable, announced deprecation path. That's the difference between a roadmap and a maintenance treadmill.
For production teams, a stable, versioned schema beats every flashy feature on the changelog. Stability is what lets you build a roadmap instead of a maintenance treadmill.
How to Access and Use the Interactions API: Step-by-Step Guide
Prerequisites and API key setup via Google AI Studio
You access the Interactions API through Google AI Studio or Vertex AI — same API key concept, different quota pools and governance. AI Studio is the fastest path for prototyping; Vertex AI is where you go when enterprise data residency and IAM controls are non-negotiable. Generate a key in AI Studio, store it as an environment variable, and you're actually ready to go. The setup is not the hard part.
If you're assembling reusable agent components, you can also explore our prebuilt AI agents for patterns that map cleanly onto Managed Agents.
Making your first Interactions API call: worked demonstration
Here's a real, minimal call. Sample input: a single user question routed to Gemini 3 Pro through the unified endpoint.
Python — first Interactions API call
Sample input: ask Gemini 3 Pro a question via the unified endpoint
import os
from google import genai
client = genai.Client(api_key=os.environ['GEMINI_API_KEY'])
Pass a model ID for inference
response = client.interactions.create(
model='gemini-3-pro',
input='Summarise what changed at GA for the Interactions API.'
)
print(response.output_text)
Output (illustrative): 'At GA, the Interactions API became Google's primary
interface for Gemini models and agents, adding Managed Agents, background
execution, a stable schema, and tool combination in a single endpoint.'
Enabling server-side state and managing sessions
To keep a multi-turn conversation, you reference the server-side session instead of resending history. The server resolves prior turns automatically. No history array. No context-window math on your side.
Python — server-side state across turns
Turn 1 creates a stateful interaction
first = client.interactions.create(
model='gemini-3-pro',
input='My deployment region is europe-west4. Remember that.'
)
Turn 2 references the same server-side session - no history replay
second = client.interactions.create(
model='gemini-3-pro',
interaction_id=first.id, # state lives on Google's side
input='Which region did I say I deploy to?'
)
print(second.output_text) # -> 'You deploy to europe-west4.'
Deploying a Managed Agent with the Antigravity sandbox
To run an autonomous task, pass an agent ID and set background=True for anything long-running. The Antigravity agent is the default. This is the call that replaces your queue, your worker, and your open websocket.
Python — background Managed Agent run
Provision a Managed Agent in a Google-hosted Linux sandbox
job = client.interactions.create(
agent='antigravity', # default Google-native agent
input='Research the top 3 vector DBs and write a comparison file.',
background=True # runs asynchronously server-side
)
Poll for completion - no open HTTP connection held
result = client.interactions.retrieve(job.id)
print(result.status) # 'running' -> 'completed'
A Managed Agent executing in the Google-provisioned sandbox via a background Interactions API call — code execution, web browsing, and file management with zero self-hosted infrastructure.
Pricing tiers, rate limits, and free-tier availability as of June 2026
Model inference is billed per token — confirm exact rates on the official Gemini API pricing page, because they move. The genuinely new pricing primitive is for Managed Agents: execution-time billing rather than pure token counting, because a sandboxed agent consumes compute time, not just tokens. That distinction will surprise you on your first invoice if you don't plan for it. Free-tier access via AI Studio includes server-side state for prototyping; treat background-execution and sandbox limits as quota-dependent and verify them against your AI Studio dashboard before committing production budget.
[
▶
Watch on YouTube
Interactions API for Gemini models and agents — walkthrough and Managed Agents demo
Google DeepMind • Gemini agentic stack
](https://www.youtube.com/results?search_query=Google+Interactions+API+Gemini+agents+walkthrough)
When to Use the Interactions API vs Alternatives
Interactions API vs raw Gemini Generate Content endpoint
If you're doing pure, stateless, single-shot inference and want minimal abstraction, the older generate-style call is still the simplest path. But Google has explicitly defaulted its documentation to the Interactions API, so for anything multi-turn or agentic, the unified endpoint is the path of least resistance — and least future migration pain. I wouldn't start a new project on the legacy endpoint today.
Interactions API vs LangGraph for stateful agent workflows
LangGraph remains the better choice when you need graph-level control over agent topology that isn't expressible in the Managed Agents schema — conditional branching, cyclic state machines, fine-grained checkpointing, and human-in-the-loop gates across nodes. If your agent is a DAG you genuinely need to inspect and mutate at runtime, keep LangGraph. If your agent is 'reason, call tools, return' — the Interactions API does it with less code and zero infrastructure. Don't overcomplicate the decision.
Interactions API vs AutoGen and CrewAI multi-agent patterns
AutoGen's conversational multi-agent patterns and CrewAI's role-based crews have no direct equivalent in Interactions API GA — native agent-to-agent coordination isn't shipping at launch. If your design depends on several agents debating or delegating among themselves, AutoGen and CrewAI still win today. That gap is real, and Google hasn't closed it yet.
Interactions API vs Anthropic MCP tool-use patterns
MCP (Model Context Protocol) is an open standard; the Interactions API uses a proprietary tool schema and MCP support is a roadmap item, not a GA feature. If open-protocol portability across providers is a hard requirement right now, Anthropic's MCP path is the cleaner bet. Full stop.
Decision framework: the Middleware Collapse Event and when to stay self-hosted
Coined Framework
The Middleware Collapse Event — applied as a migration test
Run this test: if your middleware exists primarily to hold state, route tools, or run long tasks, it has collapsed — migrate. If it exists to express custom topology, coordinate multiple agents, or stay model-agnostic, it survives — keep it.
For RAG pipelines backed by external vector databases like Pinecone or Weaviate, the Interactions API handles the retrieval tool call but doesn't manage the vector store itself — so your data layer is untouched. The storage moat stays yours.
Interactions API vs Closest Competitors: Detailed Comparison
vs OpenAI Assistants API v2: state, threads, and tool parity
OpenAI's Assistants API introduced persistent threads in 2024 — the Interactions API matches that with server-side state but adds background execution that OpenAI doesn't offer at GA in the same first-class form. That's a real gap, and it's the feature most production teams building long-running agents will notice immediately.
vs Anthropic Claude API with MCP: tool protocol differences
Anthropic's MCP is an open protocol designed for cross-provider tool portability. Google's proprietary tool schema is a deliberate ecosystem-lock-in tradeoff in exchange for tighter native integration. Neither choice is wrong — but you should make it consciously, not accidentally.
vs AWS Bedrock Agents: cloud-native agent execution comparison
AWS Bedrock Agents require IAM configuration and VPC setup before an agent runs. The Interactions API sandbox requires zero infrastructure from the developer — a single call provisions the Linux environment. For teams without a dedicated platform engineer, that difference is enormous.
vs LangGraph Cloud: managed orchestration head-to-head
LangGraph Cloud offers comparable managed execution but is model-agnostic. The Interactions API is Gemini-only — which is simultaneously its constraint and its optimization advantage. If you're already committed to the Gemini stack, that constraint costs you nothing.
CapabilityInteractions APIOpenAI Assistants v2Anthropic + MCPAWS Bedrock AgentsLangGraph Cloud
Server-side stateYes (native)Yes (threads)PartialYesYes
Background execution at GAYes (background=True)Not first-classNoPartialYes
Managed sandbox, zero infraYes (Antigravity)Code interpreterNoNeeds IAM/VPCManaged
Open tool protocol (MCP)Roadmap onlyNoYes (open)NoVia integrations
Multimodal generationYes (Omni soon)PartialYesModel-dependentModel-agnostic
Model coverageGemini onlyOpenAI onlyClaude onlyMulti-vendorModel-agnostic
Pricing primitiveToken + agent-execToken + toolTokenToken + infraSeat/exec
Industry Impact: The Middleware Collapse Event
What this means for the LangChain and AutoGen ecosystems
The framework layer doesn't vanish. But its default-tool status erodes fast. When state, tool-routing, and execution ship inside the API, the marginal team building a standard support agent or research bot no longer needs LangGraph or AutoGen at all. The frameworks retreat to their genuine strongholds: complex topology and multi-agent coordination. That's a smaller addressable market than 'everyone building on Gemini.'
Coined Framework
The Middleware Collapse Event — the economic reading
Every dollar a startup spent maintaining a self-hosted state and orchestration layer becomes a dollar of avoidable infrastructure once the provider absorbs it. The collapse isn't only architectural — it's a line-item that disappears from the build budget.
Apple developer integration and hybrid routing
Tighter native integrations — Gemini reachable from existing developer toolchains — mean mobile and desktop developers can call Gemini 3 Pro without leaving their environment, with hybrid on-device/cloud routing reducing latency for simple tasks. That broadens Gemini's reach well beyond server-side Python shops. This is the underreported part of the announcement.
Enterprise implications: Vertex AI customers and data residency
Vertex AI customers get the same API surface with enterprise governance and regional data residency — the path most regulated industries will take to the Interactions API. If you're in financial services or healthcare and wondering whether this is usable: yes, through Vertex AI, with the controls you already require.
The n8n and workflow automation layer
Low-code platforms like n8n will need to rearchitect their Gemini nodes to expose Interactions API session management — current nodes hitting the legacy generate endpoint won't surface server-side state. For teams running workflow automation on n8n, that's a near-term node upgrade to watch. It'll happen, but probably not in the next thirty days.
RAG and vector database vendors
Vector vendors like Pinecone and Weaviate are unaffected at the data layer but lose the orchestration integration point if managed tool calls become the standard retrieval interface. Their moat stays in storage and recall quality — not in being the glue between the model and the index. That's a real but survivable shift for them.
❌
Mistake: Migrating everything to Managed Agents on day one
Teams assume the unified endpoint replaces all orchestration immediately and rip out LangGraph before validating that their custom topology fits the Managed Agents schema.
✅
Fix: Migrate stateful single-agent and multi-turn flows first. Keep LangGraph for anything needing graph-level control until native multi-agent coordination ships.
❌
Mistake: Ignoring the proprietary tool schema lock-in
Building deeply against Google's proprietary tool schema while assuming MCP portability exists today — it doesn't; MCP is roadmap-only at GA.
✅
Fix: Abstract your tool definitions behind your own interface so a future MCP migration (or a multi-provider strategy) is a swap, not a rewrite.
❌
Mistake: Budgeting agents like pure token spend
Managed Agents introduce execution-time-based billing. Estimating cost purely on token counts undershoots the real bill for long-running sandboxed tasks.
✅
Fix: Model both token cost and agent-execution time. Use background execution caps on the free tier to benchmark real durations before scaling.
Expert and Community Reactions
Developer community response on X, Hacker News, and Reddit
The dominant Hacker News thread centered on the proprietary tool schema versus the MCP open standard — the lock-in concern drew the most upvotes, with developers split between 'the integration is worth it' and 'never tie tools to one provider.' That split is real and probably won't resolve until Google ships MCP support or someone gets burned badly enough to write about it.
Industry analyst takes: platform play or developer tool
Analysts framed the launch less as a developer-experience update and more as a platform-distribution move — the 'default interface across 3P SDKs and Libraries' language being the tell. Hard to disagree. The stable, versioned schema was widely cited as the single most-requested feature from the beta period, which tracks with what I hear from teams actually shipping production systems.
The ADK + Interactions API analysis
Independent developer commentary highlighted the ADK-plus-Interactions-API combination as the most coherent agentic stack Google has shipped — a single definition-to-execution pipeline rather than a bag of libraries. That framing is accurate. It's also the first time Google's agentic story hasn't required three different docs tabs open simultaneously.
The loudest critique isn't about capability — it's about lock-in. A proprietary tool schema with MCP only on the roadmap is the precise pressure point open-protocol advocates will keep pressing.
Critical perspectives: lock-in concerns and open-protocol advocates
LangChain contributors publicly questioned whether LangGraph's value proposition survives once server-side state is the default. The honest answer from the framework side: it survives where topology and multi-agent control matter, and it contracts everywhere else. That's not a death sentence — but it is a smaller market than before.
What Comes Next: Roadmap and Open Questions
MCP support timeline
MCP support is explicitly a roadmap item with no confirmed date as of June 2026. This is the single biggest open question for portability-conscious teams. Plan accordingly — and don't let anyone tell you otherwise based on vague roadmap language.
Gemini Omni and future model availability
Google flagged Gemini Omni as 'soon' in the official post — multimodal generation deepening through the same unified endpoint. Higher-tier model access through the Interactions API for enterprise Vertex AI customers is the expected next expansion. 'Soon' from Google has historically meant anywhere from six weeks to six months, so I wouldn't block a roadmap on it.
Multi-agent coordination beyond Managed Agents GA
Native agent-to-agent coordination is signaled but not confirmed as a post-GA feature — and that gap is exactly what currently keeps AutoGen and CrewAI relevant. Until it ships, those frameworks aren't going anywhere.
2026 H2
**Gemini Omni ships through the unified endpoint**
Google explicitly listed Omni as 'soon' in the GA announcement, signaling deeper multimodal generation in the same API surface.
2026 H2
**OpenAI ships a first-class background execution equivalent**
Grounded in competitive dynamics: once background execution drives Interactions API adoption, OpenAI faces direct pressure to match it at GA within roughly two quarters.
2027 H1
**MCP or MCP-compatible support lands on the Interactions API**
With MCP already a confirmed roadmap item and sustained open-protocol pressure on Hacker News, some interoperability path is the most defensible medium-term prediction.
2027 H1
**Native agent-to-agent coordination enters preview**
Google has signaled multi-agent coordination; closing this gap is the logical next move to neutralize AutoGen and CrewAI's remaining advantage.
What It Is: A Plain-Language Explanation for Non-Experts
Think of the Interactions API as one universal phone number for everything Google's AI can do. Before, you needed different numbers for different tasks and had to keep your own notebook of the whole conversation. Now you call one number, Google keeps the notebook for you, and if you ask for something that takes a while — like researching a topic and writing a report — you can hang up and Google calls you back when it's done. It can also do work for you in its own secure computer in the cloud: run code, browse the web, organize files. You provide none of that computer yourself. That's the whole thing, stripped of jargon.
What It Means for Small Businesses
The opportunity: a small business can now ship an AI assistant or research agent without hiring a backend team to manage memory, queues, and servers. A two-person agency could build a client-facing research agent for a fraction of the previous engineering cost, because Google absorbs the infrastructure. The risk: the proprietary tool schema means you're building on Google's rails, so switching providers later costs real rework. For a concrete example — a local accounting firm could deploy a background agent that drafts client summaries overnight, billed on usage, with no server to maintain. That wasn't practical eighteen months ago. It is now. Teams exploring this should review our notes on AI automation for small business.
For a small team, the real saving isn't the API price — it's the backend engineer you no longer need to hire to run state and queues. That's a five-figure annual line item the Interactions API quietly deletes.
Who Are Its Prime Users
The clearest beneficiaries: AI engineers and developer-side product leads building production LLM apps on Gemini; startups that want agentic features without an infra team; enterprises already on Vertex AI needing governed, region-resident agent execution; and mobile developers wanting native Gemini access. Company sizes range from solo builders on the free tier in AI Studio all the way to Fortune 500 Vertex AI customers. Roles that benefit most: backend engineers, ML platform leads, and technical founders who currently spend disproportionate time maintaining orchestration glue that doesn't differentiate their product. That last group should move first.
Average Expense to Use It
Model inference is per-token — confirm current rates on the official pricing page, because they change more often than the docs reflect. The genuinely new cost dimension is Managed Agents, billed on execution rather than tokens alone, because a sandboxed agent consumes compute time. Realistic total cost of ownership for a small production agent: free tier for prototyping (server-side state included), then a monthly bill driven by request volume plus agent run-time. The hidden saving sits on the other side of the ledger — eliminating self-hosted orchestration infrastructure and the maintenance headcount it required. Always benchmark real agent run durations against the free-tier background-execution cap before you scale. I'd treat any cost estimate that ignores execution time as wrong by definition.
The Interactions API introduces an agent-execution pricing primitive alongside token billing — modeling both is essential before scaling Managed Agents to production.
Good Practices and Common Pitfalls
Abstract your tool definitions behind your own interface so a future MCP migration is a swap, not a rewrite.
Use server-side state for multi-turn flows — don't keep replaying history arrays out of habit.
Benchmark agent run-time against the free-tier cap before scaling, since execution-based billing differs from token math.
Keep LangGraph for genuine graph topology and multi-agent coordination — don't force those into Managed Agents prematurely.
Prefer Vertex AI when you need data residency and IAM governance; AI Studio for fast prototyping.
Watch the versioned deprecation cycle — the stable schema is your friend; subscribe to release notes and actually read them.
Frequently Asked Questions
What is the Interactions API for Gemini models and agents, and how is it different from the existing Gemini API?
The Interactions API is Google's single unified endpoint for both Gemini models and agents, now generally available and named the 'primary' interface as of June 2026. Unlike the older fragmented, model-specific endpoints, it adds server-side state (Google holds your conversation history), background execution via background=True, tool combination, and Managed Agents that run in a Google-hosted Linux sandbox. You pass a model ID for inference or an agent ID for autonomous tasks through the same request shape. The practical difference: you stop managing session tokens, context windows, and orchestration glue yourself. Google has defaulted all its documentation to this API and is pushing it as the default across third-party SDKs, so it is the recommended path for any new multi-turn or agentic build on Gemini.
Is the Interactions API generally available and free to use in June 2026?
Yes — Google announced general availability on June 27, 2026, after launching the public beta in December 2025. There is a free tier accessible through Google AI Studio that includes server-side state for prototyping, making it free to start. Production usage is paid: model inference is billed per token, and Managed Agents introduce an agent-execution-based pricing primitive because sandboxed agents consume compute time, not just tokens. Background execution and sandbox usage are quota-dependent on the free tier, so verify current limits in your AI Studio dashboard. Enterprise access via Vertex AI uses the same API with separate quota pools and governance. Always confirm exact rates on Google's official Gemini API pricing page before committing production budget.
How do I migrate from the OpenAI Python SDK to the Interactions API in three steps?
Google maintains an OpenAI-compatibility path that keeps migration minimal. Step one: change the base URL to Google's compatibility endpoint. Step two: swap your OpenAI API key for a Gemini API key generated in Google AI Studio. Step three: change the model name to a Gemini model such as gemini-3-pro. Your existing chat-completion calls then route to Gemini with little code change. To gain the new capabilities — server-side state, background execution, and Managed Agents — migrate fully to the native Interactions API client, where you pass a model or agent ID and set background=True for long-running tasks. Start with stateless calls via the compatibility layer to validate output quality, then progressively adopt the native client for stateful and agentic features.
What are Managed Agents in the Interactions API and how do they differ from LangGraph agents?
Managed Agents are agents that run inside a Google-provisioned remote Linux sandbox — a single API call gives an agent a place to reason, execute code, browse the web, and manage files, with zero self-hosted infrastructure. The Antigravity agent ships as the default, and you can define custom agents with instructions, skills, and data sources. The difference from LangGraph: LangGraph gives you graph-level control over agent topology — branches, cycles, checkpoints, and human-in-the-loop gates you fully own and run. Managed Agents trade that fine-grained control for a fully managed runtime. Use Managed Agents for standard reason-act-tool loops where you want no infrastructure; keep LangGraph when your agent is a complex state machine or requires multi-agent coordination not yet available in the Interactions API at GA.
Does the Interactions API support MCP (Model Context Protocol) for tool use?
Not at general availability. The Interactions API uses Google's proprietary tool schema, and MCP support is listed as a roadmap item with no confirmed date as of June 2026. This is the most significant ecosystem difference versus Anthropic, whose MCP is an open, cross-provider protocol. If open-protocol portability is a hard requirement today, Anthropic's MCP path is currently cleaner. If you adopt the Interactions API now, the practical mitigation is to abstract your tool definitions behind your own interface so that a future MCP migration — or a multi-provider strategy — becomes a swap rather than a full rewrite. Watch Google's release notes closely, since some MCP-compatible interoperability is the most defensible medium-term prediction given sustained community pressure.
Can I use the Interactions API with my existing RAG pipeline and vector database?
Yes. The Interactions API handles retrieval as a tool call, so it can query your existing vector database — Pinecone, Weaviate, or others — through a custom function call combined with built-in tools in a single request. What it does not do is manage the vector store itself; your data layer, embeddings, and recall logic remain entirely yours. This means your RAG architecture is unaffected at the storage level, and you only change the orchestration touchpoint: instead of a framework calling your retriever, the Interactions API routes the retrieval tool call. The strategic shift for vector vendors is that they lose the orchestration integration point but keep their moat in storage and retrieval quality. For most teams, this is a low-risk migration: keep your vectors, expose retrieval as a tool, and let the API route it.
How does Interactions API pricing work compared to the standard Gemini token-based billing?
Standard model inference through the Interactions API continues to be billed per token, consistent with the rest of the Gemini API — confirm current rates on Google's official pricing page. The new dimension is Managed Agents, which introduce an agent-execution-based pricing primitive rather than pure token counting, because a sandboxed agent consumes compute time while reasoning, executing code, and browsing. Practically, this means a long-running background agent can cost more than its token count alone would suggest, so you should model both token spend and agent run-time. The offsetting saving is real: you eliminate self-hosted orchestration infrastructure and the engineering maintenance it required. Benchmark actual agent durations against the free-tier background-execution cap before scaling, and budget Managed Agents separately from simple inference workloads.
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)