Design With An Elephant, Review With A Goldfish: Inside Google's EGM Plugin

Design With An Elephant, Review With A Goldfish: Inside Google’s EGM Plugin

SAMI

November 8, 2026 19 mins to read

Ask a coding agent to “add webhook delivery” and it will start writing code within seconds. It will not stop to ask what happens when a delivery fails, how many times it should retry, or what the receiver should do when the same event arrives twice. Those decisions do not disappear. The agent makes them silently, in a file you will read three days later, if you read it at all.

On 22 October 2026, Google open-sourced a plugin built around that exact problem. It is called the Elephant-Goldfish Model (EGM), and its tagline fits on a sticky note: design with an elephant, review with a goldfish. The repository passed 13,000 stars in about two weeks, and Google says thousands of its own engineers use it every day to ship production code.

I have spent the last week reading the repository, the skill files, the reviewer personas, the testing notes and the open issues. I have not yet run EGM on a real project, so this article is an analysis of what the plugin is and how it is built, not a field report. Where I give an opinion, I will say so.

This post has three layers:

The why: what problem EGM is trying to solve, and where the idea comes from.
The what and the how: the roles, the seven skills, the five review stages, the reviewer personas, installation and a walkthrough.
The critique: what the evidence does and does not show, the real limits, how it compares to the spec-driven frameworks I benchmarked in July, and a checklist for running a pilot.

Part 1. The why

AI made code cheap. It did not make decisions cheap.

The Google Open Source announcement frames the problem in three words: slop, bugs and context collapse. Coding agents produce code faster than any team can read it. The bottleneck has moved from typing to understanding, and the cheapest place to catch a misunderstanding is before a single line exists.

Anyone who has worked with Claude Code, Codex or Copilot in agent mode knows the pattern. You chat with the agent for an hour. It “gets” the feature. You ask it to write the plan, and the plan looks complete. It looks complete to the agent, because the agent is reading it with the whole conversation still in memory. Every gap in the document is silently filled by context that only exists in that chat session.

Then the session ends, or the context window compacts, or a colleague picks up the plan. The gaps become bugs.

The essay behind the plugin

EGM is the packaged version of an idea from Dave Rensin, published in 2026 as Elephants, Goldfish and the New Golden Age of Software Engineering. The essay makes three arguments:

Stop using AI as a one-shot toy. Have long back-and-forth conversations, question assumptions, define grading rules. The human keeps the final judgment.
As AI writes more code than humans can read, the design document becomes more important than the code. To keep the document honest, use two kinds of sessions. The Elephant is a long session that holds all the background and drafts the design with you. The Goldfish is a brand-new session with no memory. You hand it the document. If the goldfish cannot understand the plan from the document alone, the document is missing something.
Engineers will increasingly manage several AI workers, so delegation, boundary-setting and deep focus become core skills.

The second point is the one that matters here. The goldfish test is a cheap, brutal way to measure whether a document stands on its own. Rensin did it by hand. The EGM plugin automates it, adds structure, and refuses to cheat.

Why a fresh session matters

The EGM architecture document states the reason directly: when the same model reviews its own work in the same context, it tends to validate its own faulty assumptions instead of finding errors. A model that holds context in memory assumes that context is obvious from the text. A reviewer that never saw the conversation cannot make that assumption.

This is not new to software engineering. It is the old rule that the author should not be the only reviewer, applied to agents. What EGM adds is discipline: the plugin will stop the review if your environment cannot create a truly fresh subagent. A review in the same context, the skill says, is not a goldfish review.

Part 2. The what and the how

What EGM is (and is not)

EGM is an open-source plugin of agent skills, reviewer personas and document standards. It is not a new model. There are no weights. It runs inside the coding agent you already use and drives that agent through a structured workflow using prompts and subagents.

A few facts worth knowing before you install it:

License: Apache 2.0. The README states that it is not an officially supported Google product.
Hosts: Claude Code, Codex CLI, Antigravity (CLI, app and VS Code extension), the ChatGPT and Codex desktop apps, plus setup notes for Claude Cowork and ChatGPT Work.
Traction: around 13,400 stars and nearly 1,000 forks when I checked on 8 November 2026.
Scope: the built-in workflow targets software specifications. The review loop can be configured for other documents.

The three roles

Role	What it knows	What it does
Elephant	Your project, your requirements, every earlier decision in the conversation	Explores the problem with you and drafts the specification
Goldfish	Only the document, the files it links to, the review rubric and any reading list you supply	Finds unstated assumptions, unclear requirements and implementation risks
You	The goals and constraints that actually matter	Resolve trade-offs, approve the design, decide what gets built

Two details are easy to miss. First, “zero context” means no earlier conversation, not zero information: the goldfish still reads the code the document references. Second, the human role is not decorative. The draft skill forbids the agent from ranking architecture options or marking one as the default. You pick.

The seven skills

You do not have to run the whole sequence. Each skill can be used on its own.

Skill	Purpose	Main output
`egm-brainstorm`	Explore an idea, answer open questions one at a time, then let six reviewers with different lenses challenge it in parallel	`concepts_brief.md`
`egm-draft`	Turn the brief (or existing notes) into a design document, section by section, with your approval at each gate	`design_draft.md`, then `docs/designs/<feature>.md`
`egm-review`	Review the design with fresh subagents across five stages	One report per stage
`egm-review-loop`	Run a configured group of reviewers in rounds until the document converges	`goldfish_review_report.md` per round
`egm-resolve`	Work through findings and agree on changes	Annotated report and edits
`egm-bootstrap`	Generate per-directory README “contracts” for an existing codebase	`README.md` files describing invariants, interfaces, side effects
`egm-drift-report`	Compare checked-in design docs with the current code	`{date}_DRIFT_REPORT.md`

Every skill is user-invoked. On Claude Code they are flagged so the model cannot launch them on its own. You start the workflow.

Two rules that shape everything

Design only, no production code. During design, the agent may not touch the implementation. It may write clearly marked example code inside the Markdown, for instance an interface sketch, but the production change waits until the design is approved. The architecture doc explains why: coding agents default to writing code immediately in nearby files.

One question per turn. During brainstorming and drafting, the elephant asks you one question at a time and does not tag any answer as “recommended”. It is slower than a wall of options. It also keeps you deciding instead of rubber-stamping.

The five review stages

This is the heart of the plugin. egm-review first splits the document at the heading ## Detailed Implementation Plan into a feature range (what and why) and a detailed range (how). Then it runs five stages in order. Reviewers inside a stage run in parallel.

#	Stage	Reviewers	Question it asks
1	Zoom Out	`zoom_out`	Is this the right problem? Does something in the codebase already solve it? Is anything here speculative (YAGNI)?
2	Comprehension	`comprehension`	Can a fresh reader paraphrase the proposal and the existing system it describes?
3	Critic	`design_critic`, `structural`, `style`	Faulty assumptions, single points of failure, broken structure, filler and subjective claims
4	Intermediate Zoom Out	`zoom_out`	Did the fixes from stage 3 add complexity nobody needs?
5	Implementation readiness	`implementation_readiness`, `codebase_details`, `style`	Does the plan leave any decision to the implementer? Does it contradict the actual code?

(Inside the skill these are numbered 5 to 9, after four setup steps. I use 1 to 5 here for readability.)

Three design choices in this sequence deserve attention.

Zoom Out runs twice. The first pass checks framing before anyone invests in detail. The second pass exists because review fixes tend to add things: an extra cache here, a config flag there. Stage 4 is there to purge the speculative complexity that the review itself introduced. I have watched human design reviews make exactly this mistake for twenty years.

Comprehension writes a paraphrase first. The comprehension reviewer must restate, in its own words, both the proposal and the document’s account of the current system. The persona file explains why: a list of undefined terms will not catch a document whose terms are all defined but whose parts do not connect. If the paraphrase differs from what you meant, the document is missing a link. And a section the reviewer cannot explain is a blocker.

The standards are strict. The feature-spec standard has an Alternatives Rule: a spec that proposes one path and documents no rejected alternatives fails. The implementation-readiness standard has a Zero-Decision Rule: a plan that leaves the implementer to choose a schema, an API path or a dependency fails. That second rule is, in my view, the single most useful idea in the repository. It is a precise definition of “ready to hand to an agent”.

You can choose among four presets: all stages with a checkpoint after each, one uninterrupted consolidated report, the feature stages only, or implementation readiness only.

The reviewer roster

Seven reviewer personas, plus two helpers. All reviewers share the same preamble: strictly read-only, no conversation history.

Persona	Focus
`zoom_out`	Problem framing, reuse of existing code, YAGNI
`comprehension`	Paraphrase first, then undefined project terms
`design_critic`	Faulty assumptions, single points of failure
`structural`	Headings, hierarchy, links
`style`	Filler, vague and subjective claims
`implementation_readiness`	Decisions still left open in the plan
`codebase_details`	The document against the actual code; a contradiction is a Blocker
`synthesizer` (helper)	Spawns reviewers, removes duplicates, sorts findings by Blocker, Major, Nit
`bootstrap_orchestrator` (helper)	Splits a source tree for per-directory documentation

The synthesizer exists for a practical reason: fanning nine reviewer reports straight into the main session would flood the elephant’s context window. Comprehension is the exception. Its report goes to you directly, because you need to read the paraphrase, not a summary of it.

Resolving findings: four verdicts

When findings come back, egm-resolve makes the elephant answer each one with one of four verdicts:

PROPOSE FIX: change the document.
CONTEST: the reviewer is wrong, and the elephant must cite evidence the reviewer could have read, such as a file and a symbol.
ESCALATE: the answer lives outside any readable file, so it goes to you.
DECLINE: the finding is valid but out of scope.

Two rules here show real thought. The elephant may never contest a comprehension gap: if a fresh reader could not follow the document, the document is missing context, full stop. And the skill warns the elephant against its own bias, noting that a wish to contest is not evidence the reviewer is wrong. It also says not to add context only to satisfy a reviewer: add what a human reader needs, escalate what only a zero-context agent needs.

When does the loop stop?

Reviewers are stochastic. A fresh goldfish samples the document differently every round, so “zero findings” is the wrong target. The review loop stops when one of these happens:

Two consecutive clean rounds (no unsettled Blocker or Major finding). One clean round is not enough, because the next fresh reviewer may find a different gap in the same text.
A cap of five rounds, which is a checkpoint where you decide, not a hard wall.
Churn: a new finding lands exactly where a previous fix was applied, and reverting the fix would resolve it. The document is oscillating.

A reviewer that fails twice is recorded as “not run”, never as “zero findings”. That small rule prevents a quiet failure from looking like a clean bill of health.

Installing it

Install the complete plugin, because the skills read the reviewer prompts and document standards at runtime.

Claude Code

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

Codex CLI

codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm

Antigravity CLI

agy plugin install https://github.com/google/elephant-goldfish-model

Start a new session afterwards. In Claude Code and Antigravity, commands take the /egm: prefix, for example /egm:egm-brainstorm. In Codex, pick the skill from the skill picker. Brainstorm and review require a session that can create fresh subagents.

A walkthrough: adding webhook delivery

The README uses webhook delivery as its first example, and it is a good one: easy to describe, full of hidden decisions. Here is how the flow looks. The findings below are illustrative, written by me to show the kind of output each stage produces, not copied from a real run.

Step 1. Brainstorm.

/egm:egm-brainstorm Add webhook delivery to this project.

The elephant asks one question at a time. Who registers endpoints? Do we sign payloads? What is the retry policy? What happens after the last retry? Once you agree on a working hypothesis, six reviewers with different lenses challenge it in parallel, and the agreed direction lands in concepts_brief.md.

Step 2. Draft.

/egm:egm-draft

The elephant turns the brief into design_draft.md, pausing after each section. When it reaches architecture, it presents options, for example a database-backed outbox versus a message queue, without ranking them. You choose, and the rejected option is recorded with its reason.

Step 3. Review.

/egm:egm-review design_draft.md

The kind of findings you should expect:

Zoom Out: “The project already has a job scheduler in jobs/. Why introduce a new queue?”
Comprehension: “I cannot tell whether a delivery is considered failed on a timeout, on any non-2xx response, or only on 5xx.” (Blocker.)
Design critic: “The design assumes receivers are idempotent but never gives them an idempotency key.”
Intermediate Zoom Out: “The fix for the previous finding added a per-tenant retry configuration that no requirement asks for. Remove it.”
Implementation readiness: “The plan says ‘store delivery attempts’ without specifying the table, its columns or its retention.” (Zero-Decision Rule violation.)
Codebase details: “The document says events are emitted from OrderService.complete(). That method no longer exists; see orders/service.py.”

Step 4. Resolve, approve, peer review, build. You work through findings with egm-resolve. The getting-started guide then asks you to send the approved design to another human as a pull request before implementation. Only then do you tell the agent to build to the plan.

Afterwards: drift. Months later, egm-drift-report compares docs/designs/webhooks.md with the code and tells you where they disagree. You decide whether the doc or the code changes.

Bootstrap for brownfield code

Most of us do not work on greenfield projects. egm-bootstrap addresses that by writing per-directory README.md contracts: local invariants, public interfaces, side effects. The design doc behind it says agents without this context make wrong assumptions about existing code. In a large legacy codebase this could be the most valuable skill in the package, independent of the design workflow. It is also the one subagent that can run shell commands, so review its permissions before you point it at anything sensitive.

Part 3. The critique

I like this plugin. I think it encodes good engineering habits better than most frameworks I have tested. That is exactly why it deserves a hard look.

1. The evidence is adoption, not outcomes

“Thousands of Googlers use it daily” is a claim about usage. It says nothing about defect rates, review time or delivery speed, and the repository does not claim otherwise. The project’s own FAQ is honest about it: completing the EGM workflow does not by itself demonstrate a productivity gain. There is no published benchmark of design quality, and the test scenarios that one design doc calls a precision and recall benchmark are, at the time of writing, file-format checks that nothing actually executes.

That is not a reason to dismiss EGM. It is a reason to measure it yourself before you mandate it.

2. A fresh context is not a fresh mind

On Claude Code, the reviewer adapters inherit the same model as the elephant. The independence comes from the context reset, the rubric and read access to code. That removes conversational bias, which is the main problem Rensin described. It does not remove training bias. If the model has a wrong belief about how a library behaves, the elephant and every goldfish can share it. The launch post says the goldfish share no blind spots with the designer. That is true for conversation history. It is not proven for the model’s own knowledge.

My suggestion, and it is my opinion rather than anything EGM documents: for high-stakes designs, run at least one review round with a different model family. Context reset plus model diversity is a stronger form of independence than either alone.

3. Isolation is softer than it looks on some hosts

The authors are clear that this is context and tool isolation, not filesystem isolation. On Claude Code, reviewers get a read-only tool list and can skip CLAUDE.md, which the host enforces. On other hosts, read-only depends on the prompt asking nicely. An open issue (#237) reports that on Codex and Antigravity, project instruction files such as AGENTS.md still reach the reviewers. Another (#262) asks for a per-host statement of what is host-enforced and what is prompt-only. If your threat model includes a reviewer modifying files, check your host.

4. The cost is real and unmeasured

A full review pass launches nine reviewer subagents. Recorded test runs that include brainstorming launched fifteen or sixteen. Review loops and retries add more. Nobody has published the token cost of a typical review, and the project says so. The getting-started guide also warns that EGM produces a lot of feedback by design. Someone has to triage it. That someone is you.

The FAQ adds that excessive documentation can become a bottleneck, and the README says to skip EGM for a small, clear bug fix. Take that advice seriously. Running five review stages on a one-line change is review theater.

5. Prompts are not controllers

Everything that keeps the workflow honest, the design-only rule, the one-question rule, the stage order, lives in prompt text. There is no separate controller that enforces it. In practice this works because the models follow instructions well. It also means a determined or confused agent can drift, and you will only notice if you are watching. One open issue (#271) even reports that the project’s own design docs have drifted from its shipped skills, which is a nice irony for a plugin that ships a drift report.

Where EGM sits next to spec-driven frameworks

In July I benchmarked the main AI coding frameworks: Spec Kit, OpenSpec, Superpowers, BMAD Method and others (read it here). Most of them answer the question how do I get the agent to write a spec before it writes code? EGM answers a different question: how do I know the spec is good enough?

That makes it less a competitor than a missing layer. You can imagine a Spec Kit specification going through egm-review. What EGM brings that I have not seen packaged this cleanly elsewhere:

reviewer independence as a hard requirement, not a suggestion;
a falsifiable definition of readiness (the Zero-Decision Rule);
a convergence rule for stochastic reviewers (two clean rounds, churn detection);
a protocol that stops the author from arguing its way out of findings.

What it costs, compared with lighter frameworks, is time, tokens and attention. It is a heavyweight tool for heavyweight decisions.

When to use it, when to skip it

Use it when a feature contains decisions an agent would otherwise make for you: data models, failure handling, security boundaries, public APIs, anything another team will depend on. Also use egm-bootstrap and egm-drift-report on legacy code, even if you never adopt the full workflow.

Skip it for small, well-understood changes, prototypes you will throw away, and teams that do not yet write any design docs at all. Start with the goldfish test by hand first.

A pilot checklist

If you want to try EGM in your team, here is how I would run it:

Pick three to five real features that contain genuine design decisions. No bug fixes.
Check your host. Confirm fresh subagents work, and whether reviewer read-only is host-enforced or prompt-only.
Run bootstrap first on the affected directories, so the goldfish have something accurate to read.
Use the checkpointed preset for the first runs. You will learn more from stopping at each stage.
Log every finding with its severity and your verdict. Count how many led to a real change in the design.
Track the cost: tokens, wall-clock time, and human triage time per design.
Keep the human peer review. EGM is upstream of it, not a replacement.
After implementation, look at the bugs. Were any of them caught, or catchable, in review? That is your real metric.
Add one cross-model review round on at least one design and compare what it finds.
Decide with numbers. Keep it for the feature types where it paid off. Drop it where it did not.

The takeaway

EGM is not magic, and Google does not claim it is. It is a carefully engineered version of a simple idea: the person who wrote the plan is the worst person to judge whether the plan is clear. The plugin turns that idea into skills, personas, standards and stopping rules, and it refuses to pretend a review happened when it did not.

The bigger message is the one from Rensin’s essay. When agents write the code, the design document becomes the real product of engineering work, and our value moves toward the decisions inside it. A goldfish cannot make those decisions. It can only tell you, very precisely, which ones you forgot to write down.

That alone is worth an afternoon of testing.

Sources