What nobody tells you about exporting your multi-agent prototype to a local workspace.
Every architect who's prototyped a multi-agent app in Google AI Studio eventually hits the same wall: the prototype works, but it lives in a browser tab. At I/O 2026, Google shipped a fix — Export to Antigravity, a one-click handoff to a local production workspace, carrying "all the context" with it.
I ran a real two-agent prototype through it. Here's exactly what survived the trip, what didn't, and what I had to fix by hand — including a bug that had nothing to do with the export itself.
1. The Pilot Project + The Click
The project: Research Digest — a sequential two-agent app. Agent 1 (Researcher) takes a topic, uses grounded web search to gather sources. Agent 2 (Editor) synthesizes those findings into a polished digest. Persistence via Firestore, with a history archive of past digests.
Built entirely from a single prompt in AI Studio's Build mode. Along the way, provisioning Firestore surfaced my first real gotcha before I even got to the export step — more on that below.
Triggering the export: Code tab → Export → Export to Antigravity. The dialog is genuinely informative — it tells you upfront what's coming: all project files, conversation history, and explicitly "1 secret will be included."
2. What Actually Survives the Trip
The export dialog's claims, checked one by one:
| Claimed to transfer | What I found |
|---|---|
| All project files | ✅ Confirmed — full structure landed intact: .agents, .antigravity, src, config files, README.md with setup instructions |
| Secrets (1 secret) | ✅ Confirmed — GEMINI_API_KEY arrived populated in .env, worked immediately, no manual re-entry |
| Conversation history | history❌ Did not transfer. The imported "Research Digest" project showed "No conversations yet" in Antigravity's Agent Manager, despite the dialog's explicit promise. Checked twice, on two separate screens — consistent result. |
3. The Gotchas
Gotcha 1 — "Conversation history will carry over" is currently not accurate, at least not visibly. Whatever context existed in the AI Studio thread did not surface as a conversation in Antigravity.
Gotcha 2 — The export doesn't tell you where it went.
After exporting, nothing appeared in Downloads. The Agent Manager app knew a project called "Research Digest" existed, but gave no visible file path. I had to search my whole computer by name to find it — it turned out to be nested inside an internal ~/antigravity/ folder. Only then could I "Open Folder" in the separate Antigravity IDE app and actually see the code. The Agent Manager (chat/orchestration surface) and the IDE (VS Code-based editor) are two different apps that don't automatically hand off to each other — that disconnect cost real time.
Gotcha 3 — First local run surfaced a real bug, not an export problem.
Once running (npm install → npm run dev, clean install, 0 vulnerabilities), the app loaded fine and confirmed "Connected to Cloud Firestore." But clicking Generate Digest failed:
"Tool use with a response mime type: 'application/json' is unsupported"
This is a genuine Gemini API constraint — you can't combine tool use (web search) with forced JSON-mode output in the same call. Agent 1 was built by AI Studio doing exactly that. This bug was baked into the generated code, not caused by the export.
The fix — via Antigravity's own agent, not manual coding:
I described the error directly to Antigravity's agent panel. It analyzed gemini.ts, server.ts, App.tsx, and DigestViewer.tsx, then proposed a concrete plan: have Agent 1 return plain text instead of forced JSON, and have Agent 2 parse it into the structured digest. I reviewed the diff (2 files changed, +59/−53 lines combined) and accepted it.
Re-ran Generate Digest — it worked end to end: Agent 1 gathered 5 grounded sources, Agent 2 synthesized them into a readable digest with proper citations, and the result persisted to Firestore with a real document ID.
4. Checklist
Before you export:
- Confirm which secrets are attached to your AI Studio project — the export UI will name them explicitly, verify that list matches what you expect
- Don't assume conversation history will transfer — copy anything important manually first
After you export, before you keep building:
- Locate the actual project folder yourself — check
~/antigravity/or search by project name, don't wait for the UI to point you there - Open the Antigravity IDE separately (not just the Agent Manager) to see and run code
- Run the app once, end to end, before assuming it works — the export can succeed while the underlying generated code still has bugs
- If something fails at runtime, try describing the error directly to Antigravity's agent before debugging manually — it can diagnose and patch across multiple files in one pass
The one-click export itself did what it promised on the parts that mattered most: files and secrets moved cleanly, and Firestore access — which had been broken back in AI Studio — worked correctly locally with zero extra configuration. What didn't survive was conversation context, and what slowed me down most wasn't the export at all — it was not knowing where my project physically landed, and hitting a pre-existing bug in the generated code. Antigravity's agent fixed that bug faster than I could have by hand. Net verdict: one click, then about fifteen minutes of real troubleshooting — mostly locating files and one legitimate bug, not fighting the migration itself.
If this was useful:
I write about actually using new AI dev tools — not just what the announcement says, but what happens when you run them against a real project. If you want more of this kind of hands-on testing, follow me on LinkedIn/ Twitter/X.
Also found out this project, in this repo in my github!
Got your own gotchas from the AI Studio → Antigravity export? Reply or comment — I'll fold the best ones into a follow-up.
Top comments (5)
The useful part here is that you separated “export succeeded” from “the workflow is actually production-ready afterward.” The missing conversation-history transfer and the silent handoff between Agent Manager and the IDE are exactly the kind of boundary bugs that make agent tooling feel reliable in demos and slippery in day-two debugging. The Gemini JSON-mode constraint is another good example, because it shows how often generated multi-agent code fails at the interface between tool use and output contracts rather than inside the model logic itself. This is also where local inspection tools like agent-inspect become valuable for me: once a workflow crosses browser builders, local workspaces, and agent retries, the hard part is reconstructing what actually survived the handoff. Curious whether you think the bigger product gap is export fidelity, or post-export observability once the prototype leaves the hosted surface.
The "checked twice, on two separate screens" detail for the conversation-history claim is exactly the right instinct, you're treating the export dialog's own promises as claims to verify rather than facts to report, which is rarer than it should be in this kind of hands-on writeup. The bug you hit (tool use plus forced JSON mode in one call) being baked into AI Studio's generated code rather than caused by the export is a useful distinction to draw explicitly, most people would have blamed the migration. The part worth flagging for anyone following your checklist: "don't assume conversation history will transfer, copy anything important manually first" is good advice specifically because the dialog claims otherwise, so the checklist is actively correcting the vendor's own documentation, not just being cautious. Nice that you closed the loop by having Antigravity's own agent diagnose and fix the bug it inherited, that's a decent small proof that agent-assisted debugging works when the agent has the actual running code in front of it rather than a description of the symptom.
I like that you separated export issues from generated code issues. Those are easy to mix up, but they need different fixes if you're building real apps.
solid work on observability.
The export boundary is where many agent demos become real or fall apart. A prototype can look impressive inside its native environment, but local export asks harder questions: what files exist, what assumptions moved with it, what secrets/config stayed behind, and can another developer actually run it?