Elephant-Goldfish Model: from idea to code with AI agents

A long conversation with a coding agent can make a plan feel settled. The agent knows what you meant. A fresh reviewer still has to understand what you actually wrote.

That’s the idea behind Elephant-Goldfish Model, an open-source workflow I’ve been working on with a small group at Google. Thousands of Googlers already use it.

It covers the work around implementation: exploring an idea, writing a design, challenging the plan, resolving findings, and checking whether the code still follows it.

Start with a feature, not a document

Suppose you want to add CSV exports to an app.

“Export the current results” sounds straightforward. But which results? The ones visible when you clicked the button, or the ones available when the export job runs? What happens if your permissions change while it’s running? How large can an export get?

These are example questions, not results from an EGM benchmark. They’re the sort of decisions you want to make explicit before implementation.

You can begin with a plain-language idea:

/egm:egm-brainstorm

I want to add CSV exports to this app.
Help me work through the behavior and constraints before we implement it.

Install it

For Claude Code:

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

It also works with Codex and Antigravity. The setup guides cover each tool.

Work through the plan

Brainstorm. Run the prompt above to explore the feature and its constraints. You don’t need an existing spec.

Draft. Use /egm:egm-draft to turn the discussion into a design. Check the behavior and tradeoffs before moving on.

Review. Once you have a document, run:

/egm:egm-review docs/designs/csv-export.md

The Elephant agent keeps your project context. The Goldfish reviewers get the design and relevant code without the conversation that produced them. They have to work from what’s on the page.

Resolve. Read the findings and use /egm:egm-resolve to work through them. A reviewer may flag a real gap, misunderstand a decision, or simply be wrong. You choose what needs changing.

Check for drift. As you implement, /egm:egm-drift-report checks for differences between the design and code. Sometimes the code needs fixing. Sometimes the design needs updating.

When I’d use it

I’d try it on a feature with a few meaningful decisions to make: background jobs, permissions, data changes, or a new service boundary.

The reviews take extra time and model usage. A small, obvious change may not need the whole process. A detailed report also isn’t proof that a design is correct. You still need to check the findings and test the implementation.

The plugin is Apache-2.0 licensed. Your usual coding-agent usage costs apply.

Try it on a feature you’re planning and let me know what the reviewers catch or miss in the comments.

Source on GitHub

(Built at Google, not officially supported by Google.)