The Elephant-Goldfish Model (EGM): How a Google Engineer Uses Context Isolation to Block AI Sycophancy and Hallucinations

As AI writes code faster, the cost of skipping architectural guardrails grows with it. In April 2026, Google Distinguished Engineer Dave Rensin published “Elephants, Goldfish and the New Golden Age of Software Engineering” (later featured on the Google Research publications page).

In it, he argued that without guardrails, AI simply helps engineers “mass-produce our mistakes.” While it produces plausible-looking code and shares engineers’ “love to write code,” it lacks big-picture judgment. The urge to jump straight into code must be actively reined in.

To inject human engineering judgment into AI workflows, Rensin introduced the Elephant-Goldfish Model (EGM), which Google open-sourced six months later as google/elephant-goldfish-model. The premise: hone a design document using a context-saturated, long-running conversation (the “Elephant”), then hand it to a fresh, zero-memory session (the “Goldfish”) for blind testing and implementation.

Why Elephants and Goldfish? From a Three-Step Framework to Three Epiphanies

Before diving into the software-specific EGM, Rensin introduced a universal three-step method for general knowledge work. This workflow captures the core ethos of EGM: transforming AI’s eager-to-please bias into adversarial scrutiny through isolated session contexts:

1. Victory Loves Preparation: Before touching any deliverable, instruct the AI to act as an interrogator to extract every requirement, context, and constraint until a formal work description emerges. The prompt tells the AI to keep asking clarifying questions and challenging assumptions until you explicitly call a stop—cutting off the model’s natural urge to wrap up early.
2. Trust But Verify: Switch personas in the same session, directing the AI to become an expert skeptical fact-checker that discusses what links, citations, and evidence a finished report must contain, turning “done” into acceptance criteria it can be graded against later.
3. Profit: Spin up a brand-new session to conduct in-depth research and produce the work, then return to the evaluator to grade it against the criteria. Across the entire process, only three durable artifacts are retained: the work description, the acceptance criteria, and the final deliverable. The rest, Rensin writes, “turns out to be mostly token noise.”

The company decides our value by the quality and impact of the judgment we consistently demonstrate.

—Dave Rensin

Starting in the summer of 2025, engineers inside Google turned this mental model into tooling built on Google Antigravity—Google’s agentic development environment—and Gemini. Turning this universal framework into a software-engineering-specific EGM grew out of three real-world epiphanies (“aha moments”):

• Sessions die; only design docs save you: When an AI session crashes, all context evaporates. Only a design document serves as a durable persistence layer—“read this doc and the code it references, tell me where we are”—turning re-bootstrapping into a 30-second operation.
• AI is born eager to please: Without strict guardrails, models readily pander to user biases. Every step must deliberately guard against sycophancy.
• sizeof(docs) is far smaller than sizeof(code): Shifting human architectural and design judgment upstream into documentation yields vastly higher leverage than reviewing line-by-line through a massive “code blizzard.” Rensin boiled this down to an aphorism: “Design is the new code.”

Drawing on these three insights and playing on the old adage that “an elephant never forgets, while a goldfish has a three-second memory,” EGM lays out two core roles and a guiding mantra: “Feed the Elephant; test it against the Goldfish.”

The Four Stages and Nine Steps of EGM: How It Works

EGM breaks software development into four stages and nine distinct steps. The prompts and rules at each stage are engineered to counter specific AI failure modes:

 +-- Stage 1: Growing the Elephant
 |   - Step 1: Context Loading
 |   - Step 2: The "No Code" Rule
 |   - Step 3: The Sycophant Challenge
 |   - Step 4: The First-Draft Technical Proposal
 v
 +-- Stage 2: Teaching the Elephant
 |   - Draft a 4-part self-contained design doc
 v
 +-- Stage 3: Goldfish Protocol
 |   - Step 5: The Comprehension Test (Playback)
 |   - Step 6: Critic Review
 |   - Step 7: Implementation Readiness & Human Approval
 v
 +-- Stage 4: Implementation
     - Step 8: Coding with Guardrails (Fresh Session)
     - Step 9: The "Mean" Code Review

Stage 1: Growing the Elephant (No Code Allowed)

The goal of Stage 1 is to steep a long-running session in the existing system context and thoroughly explore the design space before touching any code. Rensin’s design sessions with Gemini often span two to three days, organized around four critical moves:

1. Step 1: Context Loading: Feed all relevant codebase files, architectural context, and requirements into the session.
2. Step 2: The “No Code” Rule: Explicitly forbid writing any code. This prevents the AI from skipping the design phase and jumping straight into implementation.
3. Step 3: The Sycophant Challenge (“Why do you think that?”): Whenever the AI agrees with your proposal or offers a plausible conclusion, counter with: “Why do you think that?” Forcing the model to surface its underlying reasoning exposes the sycophantic urge to simply agree with the user.
4. Step 4: The First-Draft Technical Proposal: If you reveal your preferred solution first, the AI will naturally anchor on your framing, causing you to miss your own blind spots. Demanding that the AI propose the first draft forces unconventional ideas and latent pitfalls to the surface.

Stage 2: Teaching the Elephant

Once discussions converge, direct the Elephant to synthesize the consensus into a structured design document. To ensure the document can stand alone and carry all architectural decisions, EGM mandates a strict four-part structure:

1. Problem: Limited to three to five sentences that pinpoint exactly what problem is being solved.
2. Technical Plan: Written in plain language with minimal jargon, accompanied by a block diagram illustrating system interactions.
3. Alternatives: Explicitly records which paths were rejected and why. This section serves as an essential anti-hallucination guardrail for downstream sessions, not merely a post-mortem note. Without it, a fresh session will often regress to an approach that was already considered and discarded.
4. Detailed Implementation: An exhaustive list of every file to be touched and the exact rationale for each change. Rensin stresses that this section is critical: it removes all guesswork for future coding sessions, allowing the AI to execute strictly against an itemized punch list.

Stage 3: The Goldfish Protocol

Once the design document is written, the Elephant’s job is temporarily done. Next comes EGM’s signature mechanism: context-deprived review. Having spent two to three days in conversation, the Elephant fills in gaps with unspoken assumptions. Only a zero-memory Goldfish can verify whether the document is truly self-contained.

Each test requires a brand-new, isolated session supplied with nothing but the design document:

1. Step 5: The Comprehension Test (Playback): Instruct the Goldfish to explain the system and proposed changes based solely on the design doc. If the Goldfish misinterprets details, misses requirements, or has to guess, the document is not clear enough—revise it and test again with a new Goldfish.
2. Step 6: Critic Review: Spawn a new session and prompt the Goldfish to hunt down edge cases, inconsistencies, and holes in the design doc. Rensin estimates that roughly 30% of the criticisms raised by the Goldfish are genuinely high-value, exposing blind spots shared by both the Elephant and the human engineer.
3. Step 7: Implementation Readiness Check and Human Approval: In another clean session, ask the Goldfish whether the doc provides enough detail to start writing code immediately, or whether unmapped interfaces or ambiguous boundaries remain. Even after a design doc passes all three Goldfish tests, the final gate is an in-person review and sign-off by human engineers and peers. Only then is the design document frozen.

Stage 4: Implementation

With a design doc validated by three Goldfish tests and signed off by peers, coding becomes the most mechanical phase of the workflow:

1. Step 8: Coding with Guardrails: Launch a completely clean coding session with the directive: “Read this design doc... Follow the plan exactly.” Because the design doc explicitly enumerates every touched file and planned modification, if the coding session crashes midway, you just open a new session, hand it the design doc, and have it read the doc plus every file it references to get immediately back in business.
2. Step 9: The “Mean” Code Review: Once code is written, open another fresh session for code review using what Rensin dubs an adversarial, “mean” prompt, paired with an enforced comment-density check (any block of ten consecutive lines without comments must be flagged):

I have a strong intuition that this code is of poor quality. Please tear it to shreds and tell me all the ways it sucks.

—Dave Rensin’s “Mean” Code Review Prompt

From Methodology to Tooling: The google/elephant-goldfish-model Open-Source Plugin

In October 2026, following an announcement by Dave Rensin, Google officially open-sourced google/elephant-goldfish-model (with documentation at egm.dev). Despite having “Model” in the name, it is actually a tooling plugin that packages the four stages and nine steps into a set of Markdown rules, nine reviewer personas, and seven /egm-* skills.

Beyond Google’s internal Antigravity environment, the plugin natively supports subagent-capable runtimes such as Claude Code and Codex:

Evaluation and Adoption: Which Parts Are Worth Adopting Today?

Scrutinizing Rensin’s claims reveals actionable engineering insights alongside assumptions that warrant skepticism:

• Empirical limitations: The post cites no quantitative benchmarks or controlled trials. Metrics like the “30% of suggestions are highly valuable” estimate from critic reviews or “one week” for codebase bootstrapping are personal estimates. External analyses also flag the likeliest real-world failure: treating a stack of green reviews as a quorum and dropping the human pull-request step—a misuse the official docs warn against twice.
• Known blind spots: Outside reviews such as Digital Applied flag a vulnerability left unaddressed in the original essay: if the Elephant and the Goldfish share the same underlying foundation model, they share the same systemic blind spots and training gaps. Running Goldfish reviews through a different model family is more reliable than asking the same model to critique itself.
• Boundaries of applicability: Full-blown EGM requires heavy upfront investment (design sessions span days, with three Goldfish tests before human approval). The official repository explicitly notes that EGM targets feature changes that need design decisions and says not to force the design-first process on a simple bug fix you can one-shot. This article’s inference: work that is cross-service, carries a large blast radius, and can be itemized file-by-file (e.g., infrastructure migrations, network topology changes, IAM refactorings) fits best, while open-ended exploratory debugging does not.

Even if daily tasks don’t warrant running all four stages and nine steps, EGM offers three low-friction components worth lifting directly into existing agent workflows:

1. The Goldfish Comprehension Test (Lowest cost, highest leverage): After drafting any critical artifact—a migration plan, runbook, architecture RFC, or complex prompt—open a fresh AI session, supply only the document, and ask the model to explain the plan back to you. Every point where the Goldfish stumbles or makes a wrong assumption marks a hole in your documentation.
2. The no-code design session + First-draft AI proposal: When tackling complex changes, strictly prohibit coding upfront and resist the urge to share your own solution first. Let the AI propose draft one, then challenge it with “Why do you think that?” to smoke out hidden assumptions and blind spots.
3. Mandate “Alternatives” and an “Itemized File Punch List” in design docs: Treat design docs as a crash-recovery asset. Documenting rejected alternatives prevents future sessions from retreading discarded dead ends; itemizing modified files establishes strict scope boundaries for downstream coding agents.

Rensin closes with a straightforward yardstick for managers: can you successfully look away? If you can step away for a while and find things still in good order when you check back, you are doing your job—in his framing, the employee is the AI agent.

The same logic applies to changes: if a change carries enough consequence that you wouldn’t dare walk away while an agent runs unattended, it is worth feeding the Elephant and testing it against the Goldfish before writing a single line of code.