PMs Using Antigravity with Google Drive

The Spec Your Agent Can't Read

A product manager finishes a PRD in Notion. It's thorough — user stories with acceptance criteria, edge cases called out in callout blocks, a data model table, API contract sketches, and a priorities matrix. The PM tags the engineering lead, who dispatches an Antigravity agent to scaffold the feature.

The agent starts planning. It reads the codebase, identifies the relevant modules, proposes a file structure. But it doesn't know that the PM explicitly called out a specific error-handling pattern in the PRD. It doesn't know the data model has a soft-delete column. It doesn't know the API contract specifies pagination with cursor-based tokens, not offset. The PRD answers all of these questions — but it's in Notion, and Antigravity agents pull context from Google Drive.

So the engineer pastes requirements into the chat. Or writes a summary from memory. Or the agent guesses and gets it mostly right, except for the three things that'll surface as bugs during QA.

Why This Keeps Happening

Product and engineering teams split across tools for understandable reasons. PMs like Notion for its databases (roadmap views, feature trackers, linked specs), templates, and collaborative editing. Engineers adopted Antigravity because it's the most capable AI coding environment available, and its Google Drive integration means it can reference documentation while working autonomously.

The split works fine for humans. Engineers read the Notion link, internalize the requirements, and code. But AI agents don't have Notion access. They work with what's in their context window and what they can pull from Drive. When the source of truth for what to build lives in a tool the agent can't reach, every implementation starts with incomplete context.

The workarounds are the same ones engineering teams hit with their own docs:

• Pasting requirements into Antigravity's workspace — works for the first task, but the next agent on the next ticket doesn't have it
• Manually copying the PRD into Google Docs — tables break, acceptance criteria formatting collapses, the priorities matrix turns into a wall of text
• Writing a separate "agent-friendly" spec — nobody maintains two versions of the same document

Closing the Loop

When a PM's Notion PRD is converted to a Google Doc via Kami, it becomes part of the context surface that Antigravity agents can reach through the Workspace Extension. The agent can look up acceptance criteria before generating test cases. It can reference the data model table while writing migrations. It can check the API contract before choosing parameter names.

What matters for PM documents specifically:

• Tables hold up well — data models, feature comparison matrices, and priority grids arrive as structured tables, not collapsed text. An agent can parse a table far more reliably than a paragraph that used to be a table.
• Heading hierarchy preserves the document's navigation structure. A PRD with clear H2 sections (Overview, User Stories, Data Model, API Contract, Edge Cases) lets the agent jump to the relevant section instead of scanning the entire document.
• Callout blocks — the ones PMs use for "Important: this must handle the case where..." — convert with their content intact. The visual formatting changes, but the text survives.
• Nested checklists (acceptance criteria, launch requirements) maintain their structure and checked/unchecked state.

What doesn't carry over: Notion database views embedded in the PRD (those are dynamic queries — export them as filtered lists first), relation properties linking to other Notion pages (the linked page title appears but the link won't resolve), and embedded Figma or Loom blocks.

The Cross-Functional Payoff

This matters most at the handoff boundary — the moment product intent becomes engineering implementation. Three scenarios where it's especially visible:

Large features with multiple agents. A PM writes a 15-page PRD covering a multi-phase feature. The engineering lead dispatches three Antigravity agents for three work streams. Each agent needs different sections of the same PRD. If the full document is in Drive, each agent can reference the parts relevant to its scope without the engineer manually extracting and pasting requirements per agent.

Bug triage with product context. A bug report comes in. The engineer dispatches an agent to investigate. The agent finds the problematic code but doesn't know why it was written that way. The original PRD's edge case section explains the trade-off. With the PRD in Drive, the agent can check whether the current behavior was intentional before "fixing" something that was a deliberate product decision.

Sprint-to-sprint continuity. Requirements evolve. The PM updates the PRD in Notion, re-exports, and the updated Google Doc replaces the old one. The next agent that references the spec gets the current version, not the one from three sprints ago that's been sitting in someone's workspace files.

Setting It Up

The workflow mirrors the engineering docs setup: export from Notion, upload to Kami, and the converted Google Doc lands in Drive. For product documentation, organize the Drive folder to match how engineers will reference it — Product/PRDs, Product/Design-Specs, Product/Research — so agents can find the right document by folder context.

Re-export when the PRD changes materially. Minor wording tweaks probably don't warrant a re-conversion, but if acceptance criteria change or the data model evolves, the Drive copy should stay current.

Try converting a PRD with the demo to see how your tables and structured content come through. The API can automate the conversion step if your team wants to script it into a release workflow. See pricing for plan details.