Originally published at twarx.com - read the full interactive version there.
Last Updated: June 24, 2026
The Interactions API Gemini models agents shift just turned every orchestration framework you spent months building on top of Gemini into technical debt. Google's Interactions API moves state, memory, and agent execution directly into the endpoint itself — and as of today it's Google's primary interface for Gemini models and agents.
The Interactions API hit general availability after a December 2025 public beta, replacing the stateless generateContent pattern with a single unified endpoint that handles server-side state, background execution, tool combination, and hosted Managed Agents. If you're running LangGraph, AutoGen, or CrewAI on top of raw Gemini calls, this changes your architecture math overnight. Not gradually. Overnight.
After this article you'll know exactly what shipped, how server-side state works, what it costs, when to migrate, and — just as importantly — when to leave your existing stack alone.
Google's official announcement graphic marking the Interactions API reaching general availability as the primary interface for Gemini models and agents. Source
Coined Framework
The Orchestration Collapse Layer — the architectural moment when a foundation model provider absorbs enough middleware functionality (state, memory, tool routing, background execution) that external orchestration frameworks lose their core value proposition, leaving developers to choose between ecosystem lock-in and engineering overhead
The Interactions API is the clearest example of this collapse to date: Google has pulled session state, async execution, and agent hosting into the endpoint itself. The systemic problem it names is that thousands of teams built middleware to solve problems the provider has now solved natively — and that middleware is now a liability, not an asset.
What Google Announced: The Interactions API Launch (Official Facts and Dates)
The Exact Announcement: Source, Date, and Scope
Google announced via The Keyword (blog.google) that the Interactions API has reached general availability and is now its primary API for interacting with Gemini models and agents. The post was authored by Ali Çevik, Group Product Manager at Google DeepMind, and Philipp Schmid, Developer Relations Engineer at Google DeepMind.
Per the official text, the API launched its public beta in December 2025 and, in Google's words, 'has quickly become developers' favorite way to build applications with Gemini.' The GA release ships with a stable schema — the explicit signal of production-readiness that enterprise teams had been waiting for. I'll come back to why that specific phrase matters more than any feature on the list. For context on how fast Google has been iterating, see the official Gemini API documentation, which now defaults to this interface.
Key Headlines from blog.google
The announcement bundled several capabilities developers had been asking for: Managed Agents, background execution, Gemini Omni (coming soon), and tool improvements. Critically, Google stated that all of its 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.' That's not a feature announcement. That's an ecosystem standardisation play.
What Changed from the Previous generateContent API
The previous generateContent endpoint was stateless: every call carried the full conversation history, and your application owned all state. All of it. The Interactions API introduces a single unified endpoint where, per the source, you pass a model ID for inference, an agent ID for autonomous tasks, and set background=True for anything long-running. One endpoint now handles a one-shot model call and a multi-step autonomous agent. Same key concept, radically different surface area.
The most underrated line in the announcement: 'a stable schema.' Google's 1.x Gemini API generation burned developer trust with breaking changes. A GA stable-schema commitment is the precise condition enterprise architects required before authorising a production migration — it matters more than any single feature.
What Is the Interactions API? Architecture and Core Concepts
Plain language version: it's a single web address you talk to whether you want a quick answer from a Gemini model or a long-running autonomous agent that browses the web, runs code, and manages files. Google remembers the conversation for you, on its own servers. That's the whole thing.
The Unified Endpoint Model: One API for Models and Agents
Per the official source, 'Whether you're calling a model or running an agent, the Interactions API gets you there in a few lines of code.' One endpoint. One mental model. Pass a model ID and you get inference. Pass an agent ID and you get an autonomous task runner. This collapses two previously separate developer journeys into one — which sounds small until you've actually maintained both paths in production and realised how much drift accumulates between them.
Server-Side State: Why This Is the Architectural Shift That Matters
Server-side state means conversation history, tool-call results, and agent context live on Google's infrastructure rather than in your application layer. Full stop. This is the single most consequential change in the release. The most common reason teams bolted on LangGraph or AutoGen was to manage multi-turn state — and the Interactions API supports multi-turn sessions natively, removing that reason entirely for a large class of applications. If you want the conceptual grounding first, our AI agents guide walks through state management from scratch.
The moment a foundation model provider owns your conversation state, your orchestration framework stops being infrastructure and starts being overhead. That moment arrived for Gemini today.
The Orchestration Collapse Layer — Why External Middleware Is Now Optional
Coined Framework
The Orchestration Collapse Layer in practice
When state, tool routing, and background execution move inside the endpoint, the middleware that used to provide them loses its differentiation. The collapse isn't that frameworks die instantly — it's that they must retreat to the narrow band of complexity the provider hasn't yet absorbed. That band is narrowing.
How Background Execution Changes Long-Running Agent Tasks
Setting background=True on any call tells Google's server to run the interaction asynchronously. This is a direct answer to the 30-second HTTP timeout problem that has plagued agentic workflows — I've watched it kill demos at the worst possible moment. Previously, developers wired up Celery, RQ, or AWS SQS to hold long jobs. Background execution removes the need to hold an open connection while an agent reasons over many minutes. No queue workers. No retry logic. Just poll.
Before/after view of the Orchestration Collapse Layer: the left shows developer-owned state plus external orchestration; the right shows Google-owned server-side state inside the Interactions API.
Interactions API Request Lifecycle: From Session to Background Agent
1
**Create session (POST /interactions/sessions)**
Returns a session_id. Google now owns conversation history. No more developer-managed message arrays.
↓
2
**Send a turn (model ID or agent ID)**
Pass a model ID for inference or an agent ID for autonomous work. Context auto-loaded from server-side state.
↓
3
**Tool combination resolves**
Google Search grounding, code execution, RAG retrieval, and custom MCP tools chain inside one interaction — no separate calls.
↓
4
**Background execution (background=True)**
Long-horizon work runs async on Google's servers. Poll for completion instead of holding an HTTP connection.
↓
5
**Managed Agent sandbox executes**
The Antigravity agent (default) reasons, runs code, browses, and manages files in an isolated Linux sandbox provisioned by one API call.
The sequence matters because each stage previously required separate infrastructure — session stores, queues, sandboxes — that the API now provisions natively.
Full Capability Breakdown: Every Feature of the Interactions API
Managed Agents: Cloud-Hosted Pre-Built Agents Explained
Per the official source, 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 developers can define custom agents with instructions, skills, and data sources. This is the headline new capability of the GA release — hosted agents you don't deploy, don't patch, and don't wake up at 3am to restart. If you're benchmarking these against your own designs, you can browse our AI agent library to see how pre-built patterns stack up.
Tool Combination: Google Search, Code Execution, and Custom MCP Integration
The source confirms developers can 'mix built-in tool[s]' within a session. In practice that means grounding via Google Search, code execution, vector retrieval (RAG), and custom tools that follow the Model Context Protocol (MCP) can chain inside one interaction rather than requiring orchestrated round-trips. Each eliminated round-trip is a network hop you don't have to debug at 2am.
Multimodal Support Across the Interaction Session
With server-side state, images, audio, video, and text inputs preserve context across turns without re-sending prior media. For multimodal agent workflows this matters significantly — re-uploading large media on every turn was a real cost and latency driver in the stateless era, and it made token budgets ugly fast.
New Developer-Requested Parameters and Gemini Omni
The source explicitly lists Gemini Omni (soon) among the new capabilities, alongside Managed Agents and background execution. Google frames these as direct responses to what developers asked for during the December beta. Whether 'soon' means weeks or quarters — that we don't know yet.
Tool combination inside a single session is the quiet killer feature. Every separate tool call you eliminate removes a network hop, a state-sync risk, and a place for your orchestration code to break. Fewer moving parts is the entire value proposition of the Orchestration Collapse Layer.
Dec 2025
Interactions API public beta launch date
[Google / The Keyword, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
1 call
API calls to provision a full Linux agent sandbox
[Google / The Keyword, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
40-60%
Estimated infra-code reduction for typical agentic apps using background execution
[Developer estimates vs. Celery/SQS baselines, 2026](https://docs.celeryq.dev/)
How to Access and Use the Interactions API: Step-by-Step Guide
Prerequisites: Google AI Studio, Vertex AI, and API Key Setup
The Interactions API is accessible through Google AI Studio (free tier for prototyping) and Vertex AI (enterprise tier with SLA coverage). It uses the same API key infrastructure as existing Gemini integrations, which keeps migration friction genuinely low for current developers. Start by generating a key in AI Studio. That part at least is straightforward.
Making Your First Interactions API Call vs the Old generateContent Pattern
The conceptual difference is this: instead of sending the whole transcript every time, you create a session once and reference it by ID. Everything else flows from that.
python — first Interactions API call
1. Create a stateful session (Google now owns the history)
session = client.interactions.sessions.create(
model='gemini-2.5-pro' # pass an agent_id here instead for autonomous tasks
)
2. Send a turn — no message-array bookkeeping required
reply = client.interactions.create(
session=session.id,
input='Summarise our Q2 support tickets and flag refund risks.'
)
print(reply.output_text)
3. Kick off a long-running agent job asynchronously
job = client.interactions.create(
session=session.id,
agent_id='antigravity', # the default Managed Agent
input='Audit our pricing page against 5 competitors and draft a memo.',
background=True # runs on Google servers, no open connection
)
poll job.id later for completion
Deploying a Managed Agent: The Antigravity Agent Quickstart
You don't need to stand up your own deployment infrastructure. Specify agent_id='antigravity' within a session and Google provisions the sandbox. Custom agents are defined with instructions, skills, and data sources per the official source. For teams comparing self-hosted patterns, you can explore our AI agent library to benchmark against pre-built agent designs.
Pricing and Availability
Pricing inherits standard Gemini model token pricing. Stateful sessions add a session-level fee structure, but session caching means high-turn conversations are typically cheaper than repeating large stateless calls — the math usually works in your favour once you're past a few turns per session. Confirm exact session-fee figures on the live pricing page — the announcement text doesn't publish per-session dollar amounts, so treat any specific number floating around the internet as estimate, not fact. GA SLA coverage is available for enterprise Vertex AI customers.
A worked Interactions API call: session creation, a synchronous model turn, and a background Managed Agent job — the three patterns that replace most custom orchestration code.
[
▶
Watch on YouTube
Google Gemini Interactions API and Managed Agents walkthrough
Google DeepMind • Interactions 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 Raw generateContent
If your app needs any multi-turn memory, migrate. Full stop. The stateless pattern only wins for genuine one-shot calls — single classification, single extraction — where you'll never need the prior context. If there's any chance of a follow-up turn, the session model is already cheaper.
Interactions API vs LangGraph
For applications requiring multi-turn state with fewer than five external integrations, the Interactions API removes the need for LangGraph entirely. LangGraph keeps its edge for graph-based workflows with complex conditional branching across more than ten distinct agent nodes, where visual debugging and custom state schemas justify the dependency. That's a real use case — I wouldn't tell you to throw it out if that's what you're actually building. Our deeper take lives in this LangGraph orchestration breakdown.
Interactions API vs AutoGen and CrewAI
AutoGen and CrewAI stay relevant for multi-agent role-playing where agents negotiate or critique each other — that pattern isn't natively supported by the current Managed Agents model, and trying to fake it will make you miserable. See our guide to multi-agent systems for when that complexity is actually worth the overhead.
Interactions API vs n8n and Workflow Automation
n8n is complementary, not competitive. It connects business-app triggers to the Interactions API. Read our n8n automation guide for integration patterns.
When to Keep Your RAG and Vector Database Layer
Existing RAG pipelines with Pinecone, Weaviate, or pgvector stay necessary for private knowledge retrieval. The Interactions API is the session layer. It's not a domain-specific vector store and it won't become one. Our RAG architecture guide covers where that boundary sits.
The Interactions API doesn't kill your vector database. It kills the glue code you wrote to stitch your vector database to a stateless model. Know the difference before you delete anything.
Competitor Comparison: Interactions API vs OpenAI, Anthropic, and Others
CapabilityGoogle Interactions APIOpenAI Responses/Assistants APIAnthropic Claude + MCPAmazon Bedrock Agents
Server-side stateNative (session_id)Native (threads)Not native (MCP is tools only)Partial (managed sessions)
Background async executionYes (background=True)Polling on runsExternal tooling requiredYes (async invocation)
Managed hosted agentsYes (Antigravity default)Assistants (no Linux sandbox)No native hosted agentYes (Bedrock Agents)
Multimodal session continuityYes (text/image/audio/video)PartialPartialPartial
Unified model + agent endpointYes (single endpoint)Separate APIsSeparateSeparate
Portability across providersLow (lock-in)LowHigh (MCP open standard)Low
vs OpenAI Responses API and Assistants API
OpenAI's Assistants API offers the closest functional parallel with thread-based state. But the Interactions API's unified model-plus-agent endpoint and hosted Linux-sandbox agents give Google a broader single-endpoint surface. Whether that's better for your team depends entirely on which model family you're already committed to.
vs Anthropic Claude API and MCP
Anthropic's MCP is a tool-connection standard, not a stateful session API — architecturally complementary to this conversation, not equivalent. Anthropic hasn't shipped a native stateful session layer equivalent to the Interactions API. MCP's advantage is portability: it's an open standard. Session_ids are not. That difference compounds over time.
vs Amazon Bedrock Agents
Amazon Bedrock Agents offers managed agents and async invocation, but spreads model inference and agent orchestration across separate surfaces rather than the single endpoint Google ships. For AWS-committed shops the integration with existing IAM and VPC controls is the real draw — but you trade the unified developer experience for it.
The Vendor Lock-In Calculation
Session_ids, managed agent IDs, and server-side state are not portable to other providers. Your migration cost rises proportionally with session complexity. This is the explicit trade in the Orchestration Collapse Layer: less engineering overhead now, more switching cost later. I'm not saying don't do it. I'm saying go in with your eyes open. Our enterprise AI build-vs-buy analysis models this trade-off in dollar terms.
❌
Mistake: Migrating everything to server-side state at once
Moving every conversation into Google-owned state maximises lock-in and concentrates switching cost. If a future repricing or model change hurts you, the exit is painful.
✅
Fix: Keep a thin portability shim. Store a provider-neutral transcript copy in your own datastore so you can rebuild state on another provider if needed.
❌
Mistake: Ignoring observability into server-side state
When Google owns the state, your existing tracing tools may not see what context the model actually loaded — a real debugging gap flagged by community analysts. You'll feel this the first time something goes wrong in production.
✅
Fix: Log every input and output at your application boundary and snapshot session metadata per turn so you retain an audit trail outside Google's infra.
❌
Mistake: Treating Managed Agents as a security-free zone
Persistent cloud-hosted agents expand the prompt-injection threat surface beyond stateless inference. A poisoned input can affect a long-lived agent, not just one response.
✅
Fix: Sanitise tool inputs, scope agent data-source permissions tightly, and treat the sandbox as untrusted when it browses external web content.
❌
Mistake: Deleting LangGraph before checking branching complexity
Teams rip out orchestration, then discover their workflow had 12 conditional agent nodes the Managed Agents model can't express cleanly. I've seen this burn two weeks of re-work.
✅
Fix: Count distinct agent nodes and branch conditions first. Above ~10 nodes with complex branching, keep LangGraph and call the Interactions API from within it.
Industry Impact: What the Interactions API Means for the AI Development Ecosystem
The Death of the Middleware Layer?
LangChain's commercial value depends on developers needing orchestration on top of model APIs. The Interactions API commoditises the stateful session and tool-routing components that represent that core differentiation — exactly the Orchestration Collapse Layer playing out in real time. Our enterprise AI build-vs-buy analysis covers the procurement angle if you're making that case internally.
What It Means for Enterprise Procurement
Build-vs-buy for agent infrastructure now has a Google-managed option that cuts DevOps overhead substantially. The question shifts from 'can we build this' to 'should we own this state layer' — and for most teams, if they're honest, the answer is no. Operating a stateful agent runtime is not a core competency for a company whose actual product isn't infrastructure.
Coined Framework
The Orchestration Collapse Layer at the procurement level
Enterprises now evaluate not just which model is best, but how much of their own infrastructure a provider will absorb. The collapse reframes vendor selection as a bet on how much middleware you're willing to outsource to a single ecosystem.
What This Signals for Builders
For builders shipping agentic products, the immediate win is fewer systems to operate. Background execution alone removes queueing infrastructure that small teams have consistently struggled to run reliably. For our broader take on orchestration economics, see this orchestration explainer and the wider AI agents guide.
The winners of the next agent cycle won't be the teams with the cleverest orchestration graph. They'll be the teams who deleted the most code and shipped the fastest on a provider that owns the boring parts.
Expert and Community Reactions to the Interactions API Launch
Developer Community Response
The recurring theme in developer forums is that the stable schema commitment — not any single feature — is what unlocks production migration. Previous Gemini 1.x breaking changes eroded trust badly, and a GA stable schema is the specific assurance enterprise teams cited as a precondition before they'd put anything real on it. Features get you excited. Schema stability gets you a sign-off.
AI Researcher and Practitioner Perspectives
Authors of the announcement — Ali Çevik (Group Product Manager, Google DeepMind) and Philipp Schmid (Developer Relations Engineer, Google DeepMind) — framed server-side state as the foundation that makes everything else possible: background execution, Managed Agents, all of it sits on top of that one decision. Practitioners following the Google DeepMind research feed have echoed that state ownership is the real platform play here, not the feature list.
Critical Voices: Lock-In and Observability
Community analyses praised the reduced boilerplate while flagging limited observability into server-side state as a genuine debugging concern for production teams. Security researchers separately noted that Managed Agents running persistently in Google Cloud sandboxes create a new threat model — prompt injection can now affect a cloud-hosted persistent agent, not just a single stateless inference call, a class of risk catalogued in the OWASP Top 10 for LLM Applications. That's a different risk profile and it deserves a different security posture.
Several developers estimate a 40-60% reduction in infrastructure code for typical agentic apps once background execution replaces self-managed queues like Celery, RQ, or AWS SQS. That's a real opex line item — for a small team running managed queue workers, that can mean saving $2,000–$4,000/month in cloud and maintenance time.
The central community debate: the Interactions API trades external orchestration overhead for ecosystem lock-in — the defining tension of the Orchestration Collapse Layer.
What Comes Next: Roadmap, Predictions, and Strategic Outlook
Google has explicitly signalled Gemini Omni (soon) and an expanding Managed Agents catalogue beyond the initial Antigravity agent. The stated direction — making the Interactions API the default across third-party SDKs — points to ecosystem-wide standardisation as the next phase. Whether that standardisation happens cleanly or produces a messy transition period is the open question.
2026 H2
**Domain-specific Managed Agents (legal, medical, financial)**
Following enterprise demand patterns visible in Vertex AI usage, vertical agents are the most probable near-term additions to the catalogue beyond Antigravity.
2026 H2
**3P SDK standardisation completes**
Google stated it's working with ecosystem partners to make the Interactions API the default interface across third-party SDKs and libraries.
2027 H1
**Long-term cross-session memory absorbed into the endpoint**
This mirrors OpenAI's Assistants API capability-absorption pattern from 2023–2024; persistent user memory is the natural next layer to pull inside.
2027
**Orchestration frameworks retreat to multi-cloud and complex coordination**
LangGraph, AutoGen, and CrewAI survive by owning cross-provider portability and negotiation-style multi-agent patterns the single-provider managed layer can't express.
What Developers Should Do Right Now
Audit your Gemini integrations. Any app using external state management for Gemini conversations with fewer than three custom orchestration requirements is a migration candidate, with plausible cost reduction of 20–35% from session caching and reduced middleware compute. Keep a provider-neutral transcript copy to hedge lock-in. Don't wait for the ecosystem to force your hand — the documentation already defaults to the Interactions API, and that gap between what the docs show and what your codebase does will widen. To stay current on the broader shift, follow our workflow automation trends coverage.
Migration Decision Flow: Should You Move to the Interactions API?
1
**Do you need multi-turn state?**
No → stay on generateContent for one-shot calls. Yes → continue.
↓
2
**Count your orchestration requirements**
Fewer than 3 custom requirements → strong migration candidate. More → evaluate node complexity.
↓
3
**Branching complexity check**
Under ~10 agent nodes → migrate to Interactions API. Over 10 with complex branching → keep LangGraph, call API from inside it.
↓
4
**Multi-agent negotiation pattern?**
Yes → keep AutoGen/CrewAI. No → Managed Agents cover your case.
↓
5
**Add a portability shim, then migrate**
Store provider-neutral transcripts, then move state server-side and delete the queue + state code.
This flow operationalises the Orchestration Collapse Layer into a concrete migrate-or-keep decision for your specific architecture.
Good Practices and Common Pitfalls
Pin the stable schema version explicitly in production — GA stability is a commitment, but version-pinning protects you from future defaults.
Use background=True for anything over ~10 seconds rather than holding HTTP connections — it's the intended pattern and removes timeout fragility entirely.
Scope Managed Agent data sources to least privilege — persistent agents that browse the web are a live prompt-injection surface. Don't treat them otherwise.
Log at your boundary, not just Google's — server-side state limits observability; keep your own audit trail or you'll regret it during the first production incident.
Pilot on AI Studio free tier, ship on Vertex AI for SLA coverage before betting production traffic on it.
Don't delete vector databases — the session layer is not a knowledge store. Pinecone, Weaviate, pgvector all still earn their place for private retrieval.
Average Expense to Use It: Realistic Cost Breakdown
Honest cost picture for a small-business owner: prototyping is free on Google AI Studio. In production on Vertex AI you pay standard Gemini token pricing plus a session-level fee for stateful sessions. The structural win is that session caching makes high-turn conversations cheaper than repeatedly re-sending full transcripts as stateless calls — the crossover point tends to hit around turn four or five for typical conversation lengths.
Total cost of ownership drops mainly through eliminated infrastructure. No managed queue workers. No self-hosted state store. No agent deployment pipeline to maintain on a Tuesday night. A team previously running queue workers and a state cache could plausibly cut $2,000–$4,000/month in cloud plus engineering maintenance, with an estimated 20–35% overall cost reduction for qualifying migrations. Treat specific session-fee dollar figures as estimates until confirmed on the live pricing page — the announcement text doesn't publish them.
Frequently Asked Questions
What is the Google Interactions API and how is it different from the generateContent API?
The Interactions API is Google's new primary, unified endpoint for Gemini models and agents, in general availability after a December 2025 beta. Unlike the stateless generateContent API — where your app sent the full conversation on every call — the Interactions API keeps conversation history, tool results, and agent context on Google's servers via a session_id. You pass a model ID for inference, an agent ID for autonomous tasks, and set background=True for long-running work. It also adds Managed Agents (hosted Linux sandboxes), tool combination, and multimodal session continuity. In short: generateContent was a single-call interface; the Interactions API is a stateful platform that absorbs the middleware functions developers used to build with LangGraph or AutoGen.
Is the Interactions API available on free tier Google AI Studio or only on Vertex AI?
Both. You can prototype on the Google AI Studio free tier using the same API key infrastructure as existing Gemini integrations, then move to Vertex AI for enterprise-grade GA SLA coverage. The recommended path is to build and validate on AI Studio, then ship production traffic on Vertex AI where you get formal availability guarantees. Pricing inherits standard Gemini token rates with an added session-fee structure for stateful sessions; session caching tends to make high-turn conversations cheaper than equivalent stateless calls. Confirm exact session-fee figures on Google's live pricing page, since the announcement text does not publish specific per-session dollar amounts.
Do I need to use the Agent Development Kit (ADK) to use the Interactions API?
No. A core point of the GA release is that you can invoke Managed Agents by specifying an agent_id within an interaction session rather than standing up separate ADK deployment infrastructure. A single API call provisions a remote Linux sandbox, with the Antigravity agent shipping as the default. You can still define custom agents with instructions, skills, and data sources, and ADK remains useful for advanced agent authoring, but for most teams the Interactions API removes the deployment overhead that previously required separate agent infrastructure. This is exactly the kind of middleware absorption the Orchestration Collapse Layer describes — the provider now hosts the runtime you used to operate yourself.
How does server-side state in the Interactions API compare to OpenAI's Assistants API threads?
Both keep conversation state on the provider's servers — Google uses session_ids, OpenAI uses threads. The functional concept is similar, but the Interactions API unifies model inference and agent execution behind one endpoint and ships hosted Linux-sandbox Managed Agents plus explicit background=True async execution, where OpenAI's Assistants API uses separate APIs and run-polling. Both create the same strategic trade-off: state is not portable across providers, so switching cost rises with session complexity. Anthropic, by contrast, has not shipped a native stateful session layer — MCP is a tool-connection standard, not a session store. If portability matters most, MCP's open standard is the safer bet; if you want the most middleware absorbed natively, the Interactions API leads.
Can I use my existing LangGraph or AutoGen workflows with the Interactions API?
Yes — they coexist. For workflows with complex conditional branching across more than roughly ten agent nodes, keep LangGraph and call the Interactions API as the model/agent layer from inside it; you get LangGraph's visual debugging and custom state schemas plus Google's hosted execution. AutoGen and CrewAI remain valuable for multi-agent role-playing where agents negotiate or critique each other, a pattern the current Managed Agents model does not natively express. But for simpler multi-turn apps with fewer than five integrations, the Interactions API often makes these frameworks unnecessary overhead. Audit node count and branching complexity before deleting anything, and keep a provider-neutral transcript copy to hedge lock-in.
What are Managed Agents in the Gemini API and how do I deploy one?
Managed Agents are cloud-hosted agents that run in isolated Google Cloud Linux sandboxes. Per Google's announcement, a single API call provisions a remote sandbox where an agent can reason, execute code, browse the web, and manage files. The Antigravity agent ships as the default. To deploy, create an interaction session and specify agent_id (for example, 'antigravity') in your call — no separate deployment pipeline required. You can define custom agents with instructions, skills, and data sources. Because these agents are persistent and browse external content, scope their data-source permissions to least privilege and sanitise tool inputs to limit the prompt-injection threat surface that did not exist with stateless inference calls.
What are the data privacy and security implications of server-side state in Google's cloud infrastructure?
When you adopt server-side state, conversation history, tool results, and agent context live on Google's infrastructure rather than your application. That introduces three practical considerations. First, lock-in: session_ids and agent state are not portable, so keep a provider-neutral transcript copy in your own datastore. Second, observability: your existing tracing may not see what context the model loaded server-side, so log every input and output at your application boundary. Third, a new threat model: persistent Managed Agents that browse the web widen the prompt-injection surface beyond stateless calls. Mitigate by sanitising tool inputs, scoping agent permissions tightly, and treating sandbox web access as untrusted. For regulated workloads, use Vertex AI's enterprise controls and confirm data-residency and retention terms before migrating sensitive sessions.
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)