Google’s Elephant–Goldfish Plugin Explained: Uses and Limits

An AI assistant can follow a long conversation and still produce a plan that leaves important decisions unstated. You may both understand what “send a deadline reminder” means—until someone tries to build it and asks which timezone, which delivery channel, and what happens when the deadline changes.

Elephant–Goldfish Model, or EGM, tackles that problem by separating the assistant that develops the plan from the agents that review it. The first keeps the project context. The reviewers examine the written document without the earlier conversation, so the document has to explain itself.

The open-source project lives under Google’s GitHub organization, but its README explicitly states that it is not an officially supported Google product. Despite the name, it is a plugin and workflow for AI assistants, rather than a new foundation model.

This guide is based on the project’s documentation, source files, release notes, and test records checked on November 8, 2026. We have not installed or run EGM; the examples below illustrate how to apply its approach, rather than report measured results.

What is Elephant–Goldfish Model?

EGM helps turn an idea into a specification, review that specification, and resolve findings before implementation. Its built-in design workflow focuses on software, while a configurable review loop can also examine proposals and other documents.

Think of a specification as the written agreement about what you are building: the goal, expected behavior, constraints, failure cases, and decisions that still need an owner. A founder can help write one without being a programmer. The document gives both humans and coding assistants something concrete to work from.

The names describe two roles. The Elephant carries project context while developing the idea. Goldfish reviewers receive the document and its references without the preceding conversation. They are meant to challenge what is written, instead of silently filling gaps from what everyone discussed earlier.

The official artwork’s “remembers everything” and “remembers nothing” slogans are metaphors for those roles. EGM does not promise unlimited memory, recovery of old chats, or reviewers with no instructions or source material.

How the Elephant–Goldfish workflow works

The Elephant develops a plan with context

The drafting assistant can use your goals, constraints, existing documentation, and decisions to build a specification section by section. EGM includes brainstorming and drafting skills for this work.

Useful input would include who the feature serves, which systems already exist, what must remain compatible, and what success means. “Make the site better” leaves too much open. “Let visitors save verified scholarship listings and receive one reminder before a deadline” provides a starting point that can be challenged.

Our reusable AI brief guide explains how to keep goals and decisions available across conversations. EGM addresses a related question: once those decisions become a plan, can a reviewer understand it without the original discussion?

Goldfish reviewers challenge the written document

The standard review pipeline includes an initial zoom-out review, a comprehension test, critic review, another zoom-out review, and an implementation-readiness test. Those stages use different review lenses; “five stages” does not mean a fixed team of five agents working simultaneously.

The comprehension idea is especially useful. If a reviewer cannot explain the intended behavior from the document, the implementation may depend on assumptions that were never recorded. Critique can then focus on missing cases, conflicting requirements, or a design that is more complicated than the problem requires.

EGM requires fresh subagent contexts for Goldfish reviews. Its documented behavior is to stop that review when the host cannot provide them. Asking the same assistant to “take another look” in its existing conversation does not reproduce this setup.

A human resolves the tradeoffs

Review findings are inputs to a decision. The owner still decides which concerns matter, which changes to accept, and when the specification is ready.

For example, one reviewer might favor several reminder channels while another highlights maintenance costs. The product owner must choose the scope. EGM’s resolution workflow helps record that choice; agreement among agents is not a substitute for ownership.

A practical example: reviewing a scholarship website feature

Suppose a team uses an AI coding assistant to plan saved scholarship listings and deadline reminders. The initial requirement says: “Users can save a scholarship and get an email before the deadline.”

That sounds reasonable, but several decisions remain open. A useful review would ask:

• Which official source establishes the deadline, and when was it last checked?
• What happens when the provider extends the deadline or withdraws the listing?
• Is the deadline a calendar date or a precise time in a named timezone?
• How does the system avoid sending the same reminder twice?
• Can a user cancel a reminder or delete the saved item?
• What happens when delivery fails or the job runs late?

The owner could then choose a narrower first version: one reminder per saved listing, tied to the provider’s verified deadline, with duplicate prevention and a cancellation path. If the provider gives only a date, the team must explicitly decide how to represent that uncertainty instead of inventing a cutoff time.

The improved specification should also say how to check the behavior: save a listing twice, change its deadline, cancel a reminder, and simulate a failed delivery. These are proposed acceptance checks for this example, not tests we ran with EGM.

The value would be discovering unresolved decisions before they become implementation work. It remains possible for reviewers to miss a requirement or propose an unnecessary one. Someone familiar with the actual users and source data must assess the findings.

What can the plugin do beyond design reviews?

The repository packages seven skills. Brainstorming and drafting develop the idea and specification. Review and resolution examine the design and work through findings. Bootstrap helps create or update codebase documentation. Drift reporting compares checked-in documentation with the source. A configurable review loop supports a review task with selected reviewers.

That makes EGM relevant across a project’s lifecycle, but its design-review workflow has a different purpose from a pull-request review tool. It asks whether the plan is understandable and ready to build. It does not establish that the eventual code is correct or secure.

For related coverage, see our guide to AI code review tools. Planning review and code review can complement one another; neither removes the need for runtime tests.

Which AI assistants can use EGM?

Compatibility depends on the host application, its version, and the agent capabilities it exposes. Installation alone does not prove that the complete review workflow works.

The distinction matters because the host documentation separates installation, workflow execution, and reviewer isolation. The test record gives the tested versions and limitations. A passing result for one version or candidate should not be generalized to every later release or interface.

Metarix has profiles for Claude Code, Codex CLI, and Antigravity CLI. Our Anthropic and OpenAI hubs collect related coverage. Use EGM’s own documentation for its current installation requirements.

Important limits: fresh context, release status, and cost

Fresh context means separation from the earlier conversation. It does not guarantee independence from every instruction or bias. The project records reported cases in which Codex or Antigravity reviewers received project instruction files despite conversation isolation. Those reports concern instruction-file inheritance, rather than evidence that the earlier conversation itself leaked.

Reviewers can also share the same underlying model’s weaknesses. Multiple reports are therefore not proof of correctness. Ask for findings tied to a specific requirement, source, or failure scenario, and check consequential claims yourself. Our guide to preventing coding agents from leaking secrets explains why access boundaries remain important around agent workflows.

The latest tagged release checked for this article is v0.1.1, published November 6, 2026. It updates the listing, adds a reviewer, improves review handling, and includes experimental adapters. Its notes explicitly say that native end-to-end verification of the exact release ZIPs remains open in issue #60. Earlier workflow tests provide useful evidence, but they do not establish complete verification of every v0.1.1 package on every host.

EGM’s Apache-2.0 license allows use of the open-source software subject to its terms. Running the assistants can still consume subscription allowances or incur model charges, depending on the host and account. More reviewers and repeated review rounds can increase that usage. This research does not establish a typical cost per review or a measured reduction in bugs.

When is EGM worth trying?

The strongest candidates are changes with consequential decisions: account permissions, integrations, payment events, data imports, deadline-sensitive notifications, or migrations. A short specification can expose risks before an assistant starts changing code.

A founder or product manager can contribute by defining the behavior and deciding tradeoffs, even if a developer handles the environment. For someone who mainly uses AI to rewrite emails or answer everyday questions, a software-oriented multi-agent workflow may add more process than value.

Small, obvious edits also need proportionate review. Changing a label usually does not justify the same pipeline as moving a database. Start with one bounded feature whose requirements you can judge, rather than handing over a whole product roadmap.

How to evaluate it on your own project

First, check the installation and host guide for your application. Record the EGM version, host version, and model you use. Follow the host-specific instructions; commands and available agent tools differ between applications.

Then give the drafting assistant a concrete feature brief and the relevant source material. Review the resulting specification yourself before sending it through the Goldfish workflow. Keep a copy of that first draft so you can see what the review changed.

For each finding, record the requirement it concerns, the evidence or failure case, your decision, and the resulting change. Track duplicate or unsupported findings as well as useful ones. If the review consumes substantial time or quota, that belongs in the assessment too.

The question to answer is practical: did the review uncover important decisions before implementation, at an acceptable cost? Counting reviewers or pages of feedback will not answer it. Before building, approve the final scope and write acceptance checks for the behavior you chose.

Our assessment

EGM offers a useful structure for a familiar problem: a plan can feel clear to the people who discussed it while remaining incomplete for anyone else. Separating drafting from fresh-context review gives builders a way to challenge that gap.

It is worth evaluating for meaningful software planning, with explicit attention to host support, usage costs, and the quality of the findings. Treat it as assistance with design decisions. The final specification still needs a responsible owner, and the implementation still needs testing.

Sources and image credit

• Official repository and product disclaimer.
• Workflow and getting-started documentation.
• Host compatibility and verification limits.
• Recorded tests and their limitations.
• v0.1.1 release notes and release-bundle verification issue.
• Cover: official Elephant–Goldfish project artwork, used unmodified under the repository’s Apache-2.0 license.