Why We Don't Use Native /plan: Eliminating the "Solutioneering Trap" with an MCP Planning Gate

Google Antigravity
1

When Antigravity introduced /plan (“Plan Before You Build”), it was supposed to bring architectural discipline to agentic pair programming.

Instead, many developers encounter what software architects call the “Solutioneering Trap”:

  1. You invoke /plan to explore a feature,
  2. The agent immediately assumes a library and architectural pattern without asking,
  3. It dumps 300 lines of premature code diffs into your chat, and
  4. When you disagree with its initial assumption, you burn 5,000 output tokens and 15 minutes fighting the model’s momentum as it regenerates everything from scratch.

In our enterprise software repositories, we never adopted /plan for this exact reason.

Before /plan was even released, we had engineered our own Two-Stage Discussion Protocol, which we have now supercharged with a physical Model Context Protocol (MCP) Execution Gate.

We are sharing our empirical production benchmarks and working open-source reference implementation to show the Antigravity product team how native /plan can be evolved into a true enterprise-grade planning engine.

The Architecture: Decoupling Dialogue from Code Mutation

CURRENT NATIVE /plan WORKFLOW (The Solutioneering Trap):
[Developer: /plan Feature] ---> [Agent guesses architecture] ---> [Dumps 300 lines of code] ---> [Developer rejects & wastes tokens]

PROPOSED TWO-STAGE MCP WORKFLOW:
[Developer: "discussion"]
           │
           ▼
[PHASE 1: Advisory Exploration (Discussion Mode)]
   • Zero files created on disk. Physical MCP write lock active.
   • Agent proactively warns of anti-patterns & architectural conflicts.
   • Automatically formats structured Pros & Cons trade-off matrix.
           │
           ▼ (Consensus reached)
[Developer: "cplan"]
           │
           ▼
[PHASE 2: Staged Blueprinting (Plan MD)]
   • Dedicated file: docs/Plan_[Feature].md
   • Steps with badges: [WAITING APPROVAL], [IN PROGRESS], [EXECUTED].
   • Architectural Decision Matrix + Blast Radius per step.
   • Still in Discussion Mode awaiting developer review.
           │
           ▼
[EXPLICIT MCP EXECUTION GATE: [ 🚀 Approve Plan & Proceed ]]
   • Native protocol boundary: Mutation locked until human authorises.
           │
           ▼
[PHASE 3: Deterministic Execution]
   • High-fidelity code diffs generated with 100% mutual alignment.
   • Zero wasted tokens, zero discarded diffs.

Why MCP Is the Key Breakthrough

Prompting alone (“please don’t write code yet”) is probabilistic. Under context saturation at Turn 40+, models drift in attention and bypass prompt instructions.

With an MCP Execution Gate:

  • The gate lives in a lightweight MCP server (planning-guard).
  • In Phase 1, if the agent attempts to mutate files prematurely, the MCP server returns a hard protocol rejection:
    ❌ BLOCKED_BY_DISCUSSION_MODE: File modification locked until developer approves plan.
  • For Google: This requires zero model retraining and can be shipped out-of-the-box as a pre-bundled native core MCP server inside Antigravity!

Quantitative Impact: Standard /plan vs Two-Stage MCP Planning

Metric Google Antigravity’s Standard /plan Our Two-Stage MCP Architecture (discussion → cplan) Superiority / Benefit
Workflow Conception Monolithic: Jumps straight into 300 lines of code diffs Decoupled: Stage 1 explores architecture; Stage 2 (cplan) drafts blueprint Zero Solutioneering Trap: Aligns on concepts before touching files
Output Token Waste 3,000–8,000 tokens burned on rejected premature plans Zero tokens wasted on rejected code diffs ~40% token savings across multi-turn sprints
Alignment Velocity 2.8 average cycles fighting agent momentum 1.1 average cycles to reach locked consensus 61% faster architectural alignment
Safety Enforcement Soft Prompting: Relies on model compliance (drifts at Turn 40+) Physical Protocol Barrier: MCP server intercepts and blocks file writes 100% deterministic safety: Physically cannot mutate code during discussion
Workspace Hygiene Frequently dumps unvetted scratch files and premature diffs Zero premature files: Plan MD authored only upon explicit cplan command Keeps repository and context window pristine
Prompt Headroom Burns prompt budget on negative instructions Reclaimed: State machine lives out-of-band in MCP server Reclaims 500+ bytes prompt headroom per turn

Full RFC & Working Reference Implementation

The complete architectural whitepaper, state transition schemas, and working Node.js MCP server reference implementation are published on GitHub:
:backhand_index_pointing_right: Full Architectural RFC: RFC-AGY-2026-TWO-STAGE-PLANNING (GitHub Gist)

Questions for the Community & DeepMind Team:

  1. When invoking /plandoes your agent frequently rush into generating code diffs before you have agreed on the architectural approach?
  2. Would you prefer Antigravity to render a native [Approve Plan & Proceed] execution gate in the UI before modifying files?
  3. To the Antigravity product team: Could pre-bundled MCP servers be used to deliver protocol-level execution gates in upcoming releases?
2

Or you just create a rule in your agents directory that says to not start implementation on a plan until it is approved, and give some guidelines as to what sort of solutions you find acceptable, and what your environment is.

3

Thanks @Lucien_Van_Elsen — that is invariably everyone’s first instinct (and exactly how we started, too).

In short, 3-to-5-turn sessions, a markdown rule in `AGENTS.md` such as “Do not start implementation until the plan is approved” generally works. However, once you push agents into long-horizon enterprise development (30 to 70+ turns), relying solely on prompt instructions breaks down for three reasons:

1. The Stochastic Drift Problem (“Solutioneering Momentum”)

Negative prompt constraints (“Do not do X until Y”) are notoriously fragile under heavy context load. As the context window expands, agents develop solutioneering momentum: they formulate a plan and immediately dispatch file-editing tools in the same turn, before the human can even respond. A prompt rule is a polite request; an MCP gate is a deterministic physical barrier. In Stage 1, file-write tools are intercepted at the protocol level—the agent cannot mutate the workspace, regardless of model drift or hallucination.

2. The Plan Authoring Trap (Premature Specification)

Your rule prevents the agent from implementing code, but it doesn’t stop the agent from authoring a 300-line speculative plan* for an architecture you never agreed to in the first place.

If you ask: “How should we handle caching here?”, native `/plan` will immediately generate a rigid 5-step plan that specifies Redis schemas and dependency injection, before even discussing whether Redis is appropriate. Stage 1 decouples the conceptual debate (trade-offs, alternatives) from the plan authoring itself (`cplan`).

3. Prompt Headroom & Token Tax

Placing increasingly elaborate defensive guardrails and environmental caveats in `AGENTS.md` consumes hundreds of tokens on every turn. Offloading the gating logic to an out-of-band MCP state machine preserves precious context window headroom for actual code and reasoning.

In mission-critical or regulated environments, we believe developer platforms should provide structural guarantees rather than relying solely on prompt compliance.

4

Update: RFC-003 v1.2.0 Released (Anti-Synthetic Tripwire & Sub-0.12ms Engine)

Following our discussion on prompt drift and synthetic approval hooks, we have released v1.2.0 of the planning-guard reference implementation on GitHub Gist:

What’s New in v1.2.0:

  1. Dual-Layer Anti-Synthetic Approval Tripwire:
    • Completely neutralises synthetic approval hooks (such as IDE review policies claiming simulated consensus). Execution strictly requires explicit, conversational human commands (go, proceed, or execute).
  2. Dedicated Blueprint Gating (planning_cplan):
    • Separates Phase 2 plan authoring from execution initiation. Setting "RequestFeedback": false during plan generation prevents premature execution hooks from firing.
  3. Sub-0.12ms High-Performance Engine:
    • Re-architected with in-memory hot-state caching and asynchronous atomic journal debouncing, cutting round-trip tool latency from ~0.21ms down to 0.08ms – 0.12ms (zero overhead in agent toolchains).
  4. Exhaustive Stress Test Suite:
    • Shipped with an automated 37-assertion adversarial stress harness covering race conditions, rapid step transitions, and invalid state recovery (100% passing).

The updated specification, server source, and test suite are live on the canonical Gist:
:link: Antigravity_RFC_Two_Stage_Planning_and_Alignment (v1.2.0)