Originally published at twarx.com - read the full interactive version there.
Last Updated: June 24, 2026
The Interactions API Gemini models agents release just ended the Session Sovereignty Problem — the invisible engineering tax that has been silently killing Gemini agent projects before they ever reached production. If you're still building state-management middleware around your Gemini calls, you're already behind the architecture that the Interactions API makes the new baseline. This is Google's primary way to talk to Gemini models and agents — a single unified endpoint with server-side state, background execution, tool combination, and multimodal generation.
The Interactions API is now Google's primary interface for talking to Gemini models and agents. It went general availability with a stable schema, plus Managed Agents and async execution. That last part matters more than the headline.
By the end of this, you'll know exactly what changed, how the architecture works, how to access it, what it costs, and when to choose it over LangGraph, AutoGen, CrewAI, n8n, or the OpenAI Assistants API.
Google's official Interactions API GA graphic — a single unified endpoint for Gemini models and agents with server-side state, background execution, tool combination and multimodal generation. Source: Google
Coined Framework
The Session Sovereignty Problem — the hidden architectural tax every AI developer pays when an API forces them to own, store, and reconstruct conversational and agentic state client-side, turning a product feature into an infrastructure burden
It names the moment your team realizes the hard part of an agent product isn't the model — it's owning conversation history, tool results, and intermediate agent state in your own database. The Interactions API hands that sovereignty back to the server, deleting an entire class of infrastructure work.
What Google Announced: Interactions API Becomes the Default Gemini Interface
Official announcement details and exact release date from blog.google
On the official Google blog, Group Product Manager Ali Çevik and Developer Relations Engineer Philipp Schmid of Google DeepMind announced that the Interactions API has reached general availability and is now Google's primary API for interacting with Gemini models and agents. The public beta launched in December 2025, and per Google it "quickly became developers' favorite way to build applications with Gemini." I'll be honest — that framing usually reads as marketing, but the architectural reasoning behind the GA is real enough to take seriously.
Why Google is making Interactions API the primary — not optional — interface
This isn't a side feature. Google stated plainly that "all of our documentation now defaults to Interactions API" and that it is "working with ecosystem partners to make it the default interface across 3P SDKs and Libraries." When a foundation-model provider re-points its entire docs surface at one endpoint, that's a platform strategy shift. Not an A/B test. Not a soft recommendation. A declaration. For context on how Google's wider strategy has evolved, see the Vertex AI generative documentation.
The stable schema milestone: what it means for production developers
The single most consequential line in the announcement: the GA release ships a stable schema. In production terms, a stable, versioned schema is the difference between "experimental" and "build your roadmap on it." I've been burned before by shipping against beta schemas that changed underneath us mid-sprint — this matters. Google also added the most-requested capabilities: Managed Agents, background execution, Gemini Omni (coming soon), and tool improvements.
Dec 2025
Interactions API public beta launch
[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/)
background=True
One flag for async long-running agent runs
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
When a model provider re-points its entire documentation at one endpoint, that is not a feature launch — it is a declaration that everything else is now legacy.
What Is the Interactions API and How Does It Work
The core architecture: stateful sessions, server-side memory, and unified routing
The Interactions API introduces server-side state management: Google's infrastructure — not your client code — owns and persists conversational context across turns. A single endpoint routes to two destinations. Pass a model ID for raw inference; pass an agent ID for an autonomous task. That's the whole mental model, and it collapses the dual-path architecture developers have been maintaining for years.
How the Interactions API resolves the Session Sovereignty Problem
Before this, every serious Gemini agent team rebuilt the same plumbing: a Redis layer for session tokens, a vector database for history, and a reconstruction step that replays context on every call. We burned two weeks on exactly this bug on a production agent in late 2024 — a context-truncation edge case that silently dropped the most recent tool result before reconstruction. That's the Session Sovereignty Problem. You were forced to own state because the API refused to. Server-side state hands that ownership back to Google's servers.
Coined Framework
The Session Sovereignty Problem in production
The tax isn't just storage cost — it's the latency of reconstruction, the bugs hiding in context truncation logic, and the on-call burden of a stateful service you never wanted to run in the first place. The Interactions API converts that liability into a server-side default.
Request lifecycle: from user input to multimodal agent response
Interactions API Request Lifecycle — Model Call vs Agent Run
1
**Client sends an interaction**
Your app posts input (text, image, audio, or video) plus either a model ID or an agent ID. No history payload required — the server already holds it.
↓
2
**Unified router decides the path**
Model ID → Gemini inference. Agent ID → orchestrated agent run inside a Managed Agent sandbox. One endpoint, two destinations.
↓
3
**Server-side state is loaded**
Conversation history, prior tool results, and agent intermediate states are read from Google infrastructure — no client reconstruction.
↓
4
**Sync or background execution**
Set background=True and the server runs the interaction asynchronously, decoupling user-facing latency from agent compute time.
↓
5
**Tools combine and chain**
RAG retrievals, function calls, and MCP-compatible tools fire within the session — no external orchestration middleware required.
↓
6
**Multimodal response returns**
The result streams back; state is persisted server-side for the next turn. Switch modality next turn without re-establishing context.
The sequence matters because steps 3 and 5 — server-side state and in-session tool chaining — are exactly the layers developers used to build by hand.
The quiet revolution is step 3. By loading state server-side, Google removed the single biggest source of agent bugs in my experience: client-side context truncation that silently drops the message that mattered most.
The unified routing model: one endpoint handles both raw Gemini inference and full agent runs, eliminating the dual-path architecture that defined the Session Sovereignty Problem.
Full Capability Breakdown: Every Feature in the Interactions API
Managed Agents: cloud-sandboxed agent execution explained
Per Google, 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. This is the headline capability: you no longer run the sandbox. Google does. That's not a small thing — anyone who's debugged a containerized agent execution environment at 2am knows exactly what that's worth.
Multimodal input and output support across a single session
The API supports text, image, audio, and video within a single stateful session. The practical win: when a user uploads an image mid-conversation, you don't re-establish context. The session already knows everything that came before. No re-send, no reconstruction, no dropped prior turns.
Background execution and async task handling
Set background=True on any call and the server runs the interaction asynchronously. This targets workflows where agent reasoning time exceeds acceptable synchronous latency — the exact pattern that previously required custom queue infrastructure or the async agent patterns in AutoGen and workflow engines like n8n. One flag replaces an entire queue architecture. I'd verify the polling behavior carefully before going to production, but the concept is sound.
Tool combination: MCP, function calling, and RAG in one interface
Google explicitly cites tool improvements that let you "mix built-in tools" with your own. Tools built to the Model Context Protocol (MCP) schema become discoverable within a session — addressing the integration fragmentation that plagues LangGraph and CrewAI deployments where every tool surface is bespoke. Combining RAG, function calls, and MCP tools in one session without external orchestration middleware is a genuine reduction in moving parts.
Server-side state and session persistence mechanics
Server-side state supports multi-turn interactions natively, storing conversation history, tool results, and agent intermediate states — without a developer-managed vector database or session token system. For more on where RAG still fits, see our guide to retrieval-augmented generation.
Managed Agents quietly make Google the host of your agent logic. That is not a model feature — that is the opening move of an agent marketplace.
Antigravity shipping as the default agent is the tell. Defaults are distribution. The provider who owns the default agent owns the ecosystem's center of gravity.
How to Access and Use the Interactions API: Step-by-Step Guide
Prerequisites: Google AI Studio, Gemini API key, and ADK setup
Access starts with an API key from Google AI Studio. No exotic SDK required beyond the standard Gemini client library or the Agent Development Kit (ADK), which Google recommends as the companion framework for building custom agents — it provides scaffolding for tool registration, session management, and agent lifecycle hooks. If you've worked with the Gemini client before, the surface area here is familiar. The mental shift is the routing model, not the SDK itself. For deeper background on the ecosystem, see our Gemini API guide.
Initialising a stateful session and running your first Managed Agent
python — Interactions API (illustrative)
Pseudocode based on the GA announcement pattern.
Verify exact signatures at ai.google.dev before shipping.
from google import genai
client = genai.Client(api_key='YOUR_AISTUDIO_KEY')
1) Raw model inference — pass a model ID
res = client.interactions.create(
model='gemini-omni', # model ID = inference path
input='Summarise our Q2 churn drivers.'
)
2) Agent run — pass an agent ID instead of a model ID
agent_run = client.interactions.create(
agent='antigravity', # agent ID = Managed Agent sandbox
input='Pull the CSV, compute churn, and chart it.',
background=True # async long-running execution
)
3) Continue the SAME session — no history payload needed.
Server-side state already holds the prior turns.
followup = client.interactions.create(
agent='antigravity',
session=agent_run.session_id,
input='Now break churn down by plan tier.'
)
Look at that third call. No conversation history passed. None. That single omission is the death of the Session Sovereignty Problem. Building a multi-agent pipeline on top? Start from our multi-agent systems primer, and browse ready-made patterns in our AI agent library.
Apple developers: Foundation Models framework + Gemini in Xcode
The simultaneous Apple developer integration via the Foundation Models framework enables secure cloud-hosted Gemini calls from Xcode without exposing API keys directly in client apps — a meaningful expansion beyond web and server-side use. For broader context, see our coverage of enterprise AI deployment patterns.
Pricing and availability: what is free, what costs, and regional access
Pricing follows Gemini API token-based billing. Critically, Managed Agent sandbox execution carries compute costs separate from token costs — you pay for the Linux sandbox runtime as well as the tokens. I'd treat this like EC2 billing: the inference tokens are the predictable part, the sandbox runtime is where costs surprise you. Confirm exact figures at ai.google.dev/pricing, as they're subject to change post-launch. Background execution and Managed Agents may have limited regional availability at launch, tied to the Gemini API regional footprint. For more on connecting agents to existing systems, see our agent integration library.
The implementation path: AI Studio key → unified endpoint → model ID or agent ID → server-side session. The ADK adds lifecycle scaffolding for custom agents.
[
▶
Watch on YouTube
Google Gemini Interactions API & Managed Agents walkthrough
Google DeepMind • Gemini API architecture
](https://www.youtube.com/results?search_query=Google+Gemini+Interactions+API+Managed+Agents)
When to Use the Interactions API vs Alternatives: Decision Framework
Interactions API vs direct Gemini generateContent calls
Use direct generateContent only for single-turn, stateless completions where session overhead is genuinely unnecessary. For anything stateful, multimodal, or agentic, the Interactions API is now the default — Google's own docs reflect exactly that. If you're wrapping generateContent in a conversation loop today, that's the migration target.
Interactions API vs Google ADK standalone usage
The ADK and the Interactions API are complements, not competitors. ADK gives you the scaffolding for custom agents; the Interactions API is the runtime they execute against. Pointing the Gemini CLI at the Interactions API session model gives ADK builders a considerably more powerful backend than they had before.
Interactions API vs LangGraph, CrewAI, and AutoGen
Choose LangGraph when you need deterministic, auditable, graph-based state transitions you can't delegate to a vendor's server-side logic. Choose CrewAI or AutoGen when your agent loop must orchestrate across providers — mixing Anthropic Claude with Gemini, for instance. The Interactions API is Gemini-native and cannot orchestrate non-Google models. Full stop. Compare frameworks in our orchestration deep-dive.
Interactions API vs n8n and no-code agent builders
n8n wins for non-developer workflow automation where visual orchestration and hundreds of pre-built integrations beat programmatic control. Different user, different job. See our workflow automation guide for where each fits.
Rule of thumb: if your product is Gemini-native and multimodal, the Interactions API wins decisively. The moment you need a second model provider in the same agent loop, you're back in LangGraph or AutoGen territory.
Interactions API vs Closest Competitors: Honest Technical Comparison
vs OpenAI Assistants API, Anthropic Claude, and LangGraph Cloud
The OpenAI Assistants API pioneered server-side thread management and file retrieval. The Interactions API matches that and adds native multimodal input, background execution, and MCP compatibility. Anthropic's Claude API offers extended thinking and tool use but is stateless by design — you implement context management externally, which means the Session Sovereignty Problem persists on your side. LangGraph Cloud offers managed graph execution with persistence, but it's an orchestration layer — it doesn't include native model inference at all.
CapabilityInteractions API (Gemini)OpenAI Assistants APIAnthropic Claude APILangGraph Cloud
Server-side stateYes (native)Yes (threads)No (stateless)Yes (persistence)
Native model inferenceYesYesYesNo (orchestration only)
Managed agent sandboxYes (Antigravity default)Code Interpreter toolNo native sandboxSelf-managed
Background / async executionbackground=TrueRuns (polling)External queueYes
Native MCP tool discoveryYesLimitedMCP originator, API-side variesVia integrations
Multimodal in-sessionText/image/audio/videoText/imageText/imageModel-dependent
Cross-provider orchestrationNo (Gemini-native)NoNoYes
Stable versioned schemaYes (GA 2026)YesYesYes
The honest verdict: the Interactions API is the first single endpoint from a major foundation-model provider to combine inference, agent execution, tool orchestration, and server-side state in one stable, versioned schema. That's a genuine architectural first — not a marketing claim I'd normally let pass unchallenged. For a wider competitive view, see our AI agent frameworks comparison.
What Is It (For a Non-Expert)
Imagine hiring a brilliant assistant who forgets everything the second you leave the room — so you have to re-read them the entire conversation every single time you return. That was the old way of building with AI. The Interactions API gives that assistant a permanent memory that Google maintains, plus a private workspace where it can run code, browse the web, and handle files on your behalf. You just send a message. The system remembers the rest.
How It Works (Plain Language, With a Diagram)
You send one request to one address. Name a model and you get a straight answer. Name an agent and the system spins up a secure computer in the cloud, lets the agent do real work, and remembers everything for next time. That's it. The complexity lives on Google's servers, not yours.
Before vs After: The Session Sovereignty Shift
A
**BEFORE — You owned state**
Your servers stored history in Redis + a vector DB, rebuilt context on every call, and ran async queues. Bugs, latency, on-call pain.
↓
B
**AFTER — Google owns state**
One endpoint. Server-side session memory. background=True for long jobs. Tools chain in-session. Your code shrinks to: send message, read reply.
The before/after shows why this is an architecture change, not a feature — an entire infrastructure layer disappears.
What It Means for Small Businesses
The opportunity is brutal in its simplicity: features that used to need a backend engineer and a monthly database bill now need a few lines of code. A small e-commerce shop can build a Gemini agent that reads order CSVs, computes refunds, and emails customers — running in Google's sandbox, not on a server you maintain.
The risk: vendor lock-in. Server-side state lives on Google's infrastructure, so portability to another provider is harder than it looks. And Managed Agent sandbox time is billed separately from tokens — a chatty agent that browses the web for ten minutes costs more than a one-shot model call. Budget for compute, not just tokens. I'd model this out before committing to the architecture on a cost-sensitive product. Our small business AI guide goes deeper on budgeting.
$0
Cost of the state layer you no longer build
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
2 paths
Model ID or agent ID — one endpoint
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
4 modalities
Text, image, audio, video in one session
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
Who Are Its Prime Users
The clearest beneficiaries: AI engineers and developer advocates building multi-agent pipelines on Gemini who are tired of inconsistent interfaces between model calls and agent orchestration. Beyond them — SaaS startups shipping Gemini-native chat products, indie iOS/macOS developers using the Xcode + Foundation Models path, and internal automation teams at mid-market companies that want agent capability without standing up a stateful service. Company size sweet spot: anyone too small to want an infrastructure team, and anyone large enough to be drowning in middleware.
When to Use It (And When Not To)
Use it when: you're Gemini-native, need multi-turn memory, mix modalities, or run long agent jobs. Avoid it when: you need cross-provider orchestration (use AutoGen/CrewAI), deterministic auditable routing (use LangGraph), visual no-code workflows (use n8n), or stateless single-shot calls (use generateContent). The fastest way to waste money here is wrapping the Interactions API around a task that never needed state to begin with.
How to Use It: A Worked Demonstration
Scenario: a churn-analysis agent for a SaaS founder.
Worked demo — input → steps → output
INPUT (turn 1)
agent = 'antigravity'
input = 'Read churn.csv, compute monthly churn %, and chart it.'
background = True
WHAT THE SANDBOX DOES
- provisions Linux sandbox
- loads churn.csv, runs pandas to compute churn
- renders a matplotlib chart
- persists results to server-side session state
OUTPUT (turn 1)
'Monthly churn: Jan 4.1%, Feb 3.8%, Mar 5.2%. Chart saved. Spike in Mar.'
INPUT (turn 2) — no history re-sent
input = 'Now break March down by plan tier.'
OUTPUT (turn 2)
'March churn by tier: Starter 8.9%, Pro 3.1%, Enterprise 1.2%.
Starter tier drives the spike.'
Turn 2 carries zero history payload — the agent already remembers March from turn 1. That's the entire value proposition in two API calls.
Good Practices and Common Pitfalls
❌
Mistake: Keeping your old Redis/vector state layer "just in case"
Running client-side state alongside server-side state creates two sources of truth that drift — the classic dual-write bug. Your agent answers from one history while your UI shows another. I've seen this wreck demo days.
✅
Fix: Migrate fully. Treat server-side session state as canonical and delete the middleware. Keep a vector DB only for retrieval corpora, not conversation state.
❌
Mistake: Using background=True for fast interactive chat
Async execution adds polling complexity. For sub-second turns it hurts UX and adds code for no benefit.
✅
Fix: Reserve background=True for jobs whose reasoning time exceeds your acceptable synchronous latency — web browsing, multi-step code execution, large file processing.
❌
Mistake: Ignoring sandbox compute as a cost line
Teams budget tokens and get surprised by Managed Agent sandbox runtime billed separately. A web-browsing agent can burn far more on compute than on tokens. This will catch you off guard in your first month.
✅
Fix: Track sandbox-seconds as a first-class metric. Set timeouts and skill scopes per agent. Verify rates at ai.google.dev/pricing.
❌
Mistake: Building deep dependencies on legacy generateContent for agents
Google now defaults all docs to the Interactions API. Anchoring agent logic to legacy patterns is accruing technical debt against an interface Google is clearly steering away from.
✅
Fix: Use generateContent only for stateless single-turn calls. Route all agentic and multi-turn work through the Interactions API.
Average Expense to Use It
Realistic cost model: you pay Gemini API token-based billing for inference, plus separate compute cost for Managed Agent sandbox execution. There's a free experimentation tier in Google AI Studio for prototyping. Total cost of ownership often drops for stateful products because you eliminate the Redis/vector-DB session layer and the engineering time to maintain it — that hidden cost was the Session Sovereignty tax. Always confirm current rates at ai.google.dev/pricing, since figures are subject to change post-launch.
Industry Impact: What the Interactions API Changes for AI Development
The death of the middleware tax
Developers who built custom Redis or vector-database session layers now face a build-vs-migrate decision. Server-side state is effectively free infrastructure that removes an entire class of engineering work. The middleware many teams shipped last year just became technical debt — and the teams that built it cleanest will migrate fastest.
Impact on ADK, Gemini CLI, and Google's ecosystem
The ADK gains a far more powerful runtime, and the Gemini CLI becomes more capable when pointed at the session model. Enterprise platforms can replace custom orchestration middleware with native sessions, shrinking integration surface area significantly.
Implications for MCP and the tool-calling ecosystem
MCP's inclusion as a first-class tool standard accelerates adoption well beyond Anthropic's original ecosystem. This is a competitive move: Google is positioning to co-own the tool-interoperability standard. And by hosting third-party agent logic in a secure sandbox, Google sets the precedent for an agent marketplace — not just a model provider. Read our take on AI agents as a platform layer.
The custom state-management layer you shipped last quarter is now technical debt. The most valuable engineering work in 2026 is deleting code, not adding it.
Expert and Community Reactions to the Interactions API Launch
Developer community response
Within the developer community, the framing "one interface for models and agents" resonated strongly — circulated widely on Medium and reposted across X and LinkedIn as the cleanest summary of what changed. Analysts focused on the stateful multi-turn interaction capability as the defining feature, calling it a new interface paradigm rather than an incremental API update. That read feels right to me.
Named voices
The announcement itself is authored by Ali Çevik, Group Product Manager at Google DeepMind, and Philipp Schmid, Developer Relations Engineer at Google DeepMind — both Google DeepMind practitioners, which anchors the source authority. Community technical writers framed the launch around the same thesis Google leads with: a single unified endpoint replacing the model/agent split.
Critical perspectives: what it still does not solve
The honest gaps the community flagged: no cross-provider agent orchestration, uncertainty about background-execution pricing at scale, and limited documentation on Managed Agent customisation limits at launch. The simultaneous Apple integration drew attention to Google's platform breadth — shipping the Interactions API the same week as Xcode access is not a coincidence.
What most people get wrong: they read this as a convenience API. It's not. It's Google making a land-grab for two standards at once — server-side agent state and MCP tool interoperability — in a single stable schema.
What Comes Next: Roadmap, Predictions, and Open Questions
Google explicitly named Gemini Omni (soon) as a coming capability, and the pairing of Managed Agents with a stable schema strongly signals a hosted agent registry on the near-term roadmap. Antigravity, shipped as the default, reads as a proof-of-concept for a broader catalog. That's the pattern: ship a default, prove demand, open the catalog.
2026 H2
**Gemini Omni lands in the Interactions API**
Google named it as "coming soon" in the GA post — expect richer multimodal generation within the same stateful session model.
2026 H2
**Client-side SDK wrappers for iOS/macOS expand**
The Foundation Models + Xcode integration signals native client SDKs beyond web and server-side use cases.
2027
**Legacy endpoints consolidate**
With all docs now defaulting to the Interactions API, expect Google to absorb or deprecate standalone agent endpoints — avoid deep generateContent dependencies for agents.
2027
**An agent marketplace emerges**
Hosting third-party agent logic in a sandbox is the foundation for a catalog. Antigravity-as-default is the seed.
Open questions to track: What are the SLA guarantees for background execution at enterprise scale? How does Managed Agent sandboxing handle egress and data-residency requirements? And will Google ever open the Interactions API to non-Gemini models as a neutral orchestration layer — or keep it strictly Gemini-native? For ongoing analysis, follow our AI news coverage.
The provider who owns server-side agent state owns the switching costs. Google just made it free to enter — and quietly expensive to leave.
The trajectory: from unified endpoint to agent marketplace. Gemini Omni and native client SDKs are the next signposts Google has publicly hinted at.
Frequently Asked Questions
What is the Interactions API in the Gemini API and how is it different from generateContent?
The Interactions API is Google's new primary, unified endpoint for both Gemini model inference and agent runs, announced at general availability with a stable schema after a December 2025 beta. The key difference from generateContent is server-side state: the Interactions API persists conversation history, tool results, and agent intermediate states on Google's infrastructure, so you don't re-send context each turn. You pass a model ID for inference or an agent ID for autonomous tasks, and set background=True for long-running work. Use generateContent only for single-turn, stateless completions where session overhead is unnecessary. For multi-turn, multimodal, or agentic applications, Google now defaults its documentation to the Interactions API — making it the recommended path for production builds.
How do Managed Agents work in the Interactions API and what is the Antigravity agent?
Per Google, a single API call provisions a remote Linux sandbox where an agent can reason, execute code, browse the web, and manage files. That sandbox is fully hosted by Google — you don't stand up infrastructure. The Antigravity agent ships as the default Managed Agent, demonstrating code execution in an isolated environment. You can also define custom agents with your own instructions, skills, and data sources, using the Agent Development Kit (ADK) for scaffolding. Because the sandbox runs server-side, you avoid building queue infrastructure for long tasks — just set background=True. Note that sandbox compute is billed separately from tokens, so a web-browsing agent can cost more in runtime than in inference. Verify customisation limits and pricing at ai.google.dev.
Does the Interactions API support MCP (Model Context Protocol) tools?
Yes. The GA release improves tool handling so you can mix built-in tools with your own, and MCP-compatible tool schemas are discoverable within an Interactions API session. This matters because MCP, originally championed by Anthropic, is becoming the cross-ecosystem standard for tool interoperability. By making MCP a first-class citizen, Google addresses the integration fragmentation that affects LangGraph and CrewAI deployments, where each tool surface is often bespoke. Within a single session you can combine RAG retrievals, function calls, and MCP tools, chaining them without external orchestration middleware. The strategic read: Google is positioning to co-own the tool-interoperability standard rather than build a proprietary alternative — a notable competitive move that accelerates MCP adoption industry-wide.
How does the Interactions API compare to the OpenAI Assistants API?
The OpenAI Assistants API pioneered server-side thread management and file retrieval, and the Interactions API matches those fundamentals. Where it pulls ahead: native multimodal input across text, image, audio, and video in a single session; one-flag background execution; and native MCP tool discovery. Both offer stable versioned schemas and server-side state, so the gap is narrower than headlines suggest. The decisive factor is ecosystem: choose the Interactions API if you're building Gemini-native products and want a unified model-plus-agent endpoint with a hosted Linux sandbox via Managed Agents. Choose the Assistants API if you're committed to the OpenAI model family. Neither orchestrates across providers natively — for that, you still reach for AutoGen, CrewAI, or LangGraph as an orchestration layer above the model APIs.
Is the Interactions API available to Apple developers and in Xcode?
Yes — a simultaneous integration via Apple's Foundation Models framework enables secure cloud-hosted Gemini calls from Xcode without exposing API keys directly in client apps. This is significant because client-side key exposure has long been a security headache for native mobile AI features. Routing through the Foundation Models framework keeps credentials server-side while letting iOS and macOS developers tap Gemini and the Interactions API session model from native code. Combined with the GA of the Interactions API, this expands Google's reach beyond web and server-side use cases into Apple's native ecosystem. Expect Google to add more client-side SDK wrappers over time, given this integration signals a deliberate platform-breadth strategy. Developers should confirm the exact supported call patterns and regional availability in Google's official documentation before shipping to the App Store.
What does server-side state management mean in the Interactions API — do I still need a vector database?
Server-side state means Google's infrastructure owns and persists your conversational and agentic context across turns — conversation history, tool results, and agent intermediate states — so you don't store or reconstruct it in client code. This directly solves the Session Sovereignty Problem and removes the need for developer-managed session tokens or a vector database used purely for conversation memory. You do still want a vector database for retrieval-augmented generation over your own knowledge corpus (documents, product catalogs, policies) — that's a different job from session memory. Practically: delete your Redis/vector session layer and treat the Interactions API session as the canonical store, but keep a vector DB like Pinecone for RAG retrieval. Mixing both responsibilities into one store is the dual-write bug that causes drift between what your agent remembers and what your UI shows.
How much does the Interactions API cost and is background execution billed separately?
The Interactions API follows Gemini API token-based billing for inference. Critically, Managed Agent sandbox execution carries compute costs that are separate from token costs — you pay for the Linux sandbox runtime in addition to tokens. Background execution runs on that same Managed Agent infrastructure, so async long-running jobs accrue sandbox compute, which means a web-browsing or multi-step coding agent can cost more in runtime than in tokens. There is a free experimentation tier in Google AI Studio for prototyping. Total cost of ownership often drops for stateful products because you eliminate the Redis and vector-database session layer plus the engineering time to maintain it. Always confirm exact rates at ai.google.dev/pricing, since figures are subject to change after launch and regional availability for background execution and Managed Agents may be limited initially.
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)