Google splits AI specification work into two roles in its EGM plugin

You spend half an hour discussing a new feature with AI. It asks questions, agrees with decisions and writes a detailed specification. You ask it to review the document—everything looks convincing. After launch, however, you discover that a duplicate event from the payment service extends a subscription twice. Everyone in the conversation assumed there would be duplicate protection, but it never made it into the document.

Elephant-Goldfish Model, or EGM, targets this problem. It is an open-source plugin for drafting and reviewing technical documents with AI. One agent gathers the decisions; others review the result without the discussion history. The practical aim is to catch omissions before implementation, while fixing them still takes only a few lines in the specification.

Why reviewers need to forget the conversation

EGM has two roles. The "Elephant" retains the project context and prepares the document. The "Goldfish" receive the document and related source code, but not the preceding conversation. The developer chooses which feedback to accept, resolves contradictions and approves the design before coding begins. This is how the process is described in Google's repository.

The absence of chat history is a condition of the review. If a decision makes sense only to the participants in a long conversation, whoever implements it later may lack essential information. A fresh reviewer must assess what is actually written, without mentally filling in the document using earlier agreements.

Still, the phrase "zero context" is easy to take too literally. Reviewers receive materials to work with. It is the discussion history that is isolated, not all information about the system. The quality of the specification and the choice of source code therefore still matter.

How this works in a payments example

Imagine a team adding support for payment notifications. The first version of the document says: receive the event, find the user, extend the subscription. That is enough to demonstrate the feature. For a production service, questions remain.

What happens if the same event arrives twice? What if the database saves the extension, but the server fails to acknowledge receipt in time? What if a payment cancellation notification arrives before the successful payment notification? These are examples of possible review questions, not a report of EGM's results.

The document's author may have discussed retries in the chat and considered the matter settled. A reviewer without that history sees a gap: the specification contains no rules for handling duplicate events. An engineer will need to define how to identify duplicates, where to store the processing result and what behavior is correct after a failure.

There is work for the product manager here, too. Refunds, subscription cancellations and notification redelivery affect promises made to users. These decisions cannot be left entirely to the agent writing the code. First, the team agrees on the product's behavior, then documents it so another person or agent can review it.

What to try and where the limits lie

The EGM website describes the stages of discussing an idea, preparing a document and reviewing it. It also presents tools for documenting an existing project and finding discrepancies between the specification and the code. A sensible starting point is a single feature with contentious decisions: payments, access permissions or background jobs.

Before the review, it helps to record constraints and acceptance criteria. Afterward, assess the feedback, revise the document and only then move on to implementation. To evaluate the benefit, you could count confirmed gaps found before coding and track the time spent reviewing. This is a proposed evaluation method, not published performance metrics for the plugin.

EGM provides no basis for promising to eliminate architectural errors. Separate agents can share the same misconceptions, and convincing feedback can turn out to be wrong. Additional rounds also take time and consume tokens. The cost of review should be proportionate to the cost of a potential error.

The project is distributed under Apache 2.0; its authors explicitly state that it is not an officially supported Google product. Reviews require fresh subagent contexts, and the process does not replace tests or engineering judgment—these limitations are explicitly listed in the README.

EGM suggests a useful habit: before implementation, give the specification to someone who did not take part in discussing it. If it cannot be implemented without verbal explanations, the document still needs work.