What happened
Google’s public EGM repository describes an open-source plugin for “designing and reviewing software with AI agents.” The project is licensed under Apache-2.0 and is intended for features that require design decisions before implementation, rather than small and clear bug fixes. Its central workflow is deliberately split between two roles: Elephant, which holds project context and develops the proposed design, and Goldfish, which reviews without the preceding conversation.
Elephant works with the project, stated requirements, and earlier decisions. A builder can use the brainstorming skill to explore an idea and produce concepts_brief.md; the draft skill then turns that brief into design_draft.md, pausing after sections for feedback in chat. The repository’s example is webhook delivery, where a team must decide what happens after a failed delivery or when an event arrives twice. The point is not that the agent autonomously makes those choices: the human resolves architectural trade-offs and approves the specification.
Goldfish reviewers receive the draft and source material referenced by it, but not the history that produced it. According to the README, they are meant to identify missing assumptions, unclear requirements, and implementation risks. The review command uses fresh reviewers to check the draft, its clarity, its relationship to the codebase, and its implementation plan. A configured review loop is also available for a specific review task. EGM additionally includes skills to resolve review findings, bootstrap or update documentation for an existing codebase, and produce a drift report that compares checked-in documents with current source code.
The plugin provides installation paths for Antigravity, Claude Code, and Codex. For Claude Code, the documented flow adds Google’s marketplace and installs egm@egm; for Codex, users add the plugin and select the relevant EGM skill from the skill picker. The README also points Claude Cowork and ChatGPT Work users to a setup guide. Brainstorming and review require a session capable of creating fresh subagents. If that capability is absent, EGM stops the review rather than silently simulating it.
The repository says thousands of Google engineers use EGM. Its claimed boundary is also clear: a Goldfish review does not replace tests or human judgement. EGM packages a process for making design review more structured, not a guarantee that a design is correct.
What the archive adds
This is a new event on a related Google theme, not a restatement. Google Harness² for Recursive Self Improvement treated the harness as the object of improvement; EGM applies a more bounded harness pattern to design work, separating context accumulation from adversarial review before code generation.
Trend signal
EGM supports the pattern that skills become a portable capability layer. Its functions are packaged as selectable skills across more than one coding-agent environment, but the repository also shows the important constraint: portability is not enough. The review depends on a runtime capability—fresh subagent contexts—and declines to run when that capability is unavailable.
Why it matters
Coding agents lower the cost of implementation, which can make an ambiguous decision expensive faster rather than make it less ambiguous. EGM offers a concrete process boundary for teams facing that problem: use one agent context to assemble requirements and a draft, then use agents that lack the conversational momentum to challenge what the draft assumes. That is useful because a long-running assistant can inherit a team’s framing errors along with its useful project knowledge.
The approach also keeps authority in an appropriate place. The agent records alternatives and review findings, while a person approves the specification and decides which findings matter. Teams do not need to adopt every command in the repository to benefit from the model. The transferable operational idea is to make an approved design artifact the handoff between exploratory agent work and implementation, and to make independent review a required stage for consequential changes.
What happens next
- Coding-agent environments will expose more explicit support for fresh, isolated reviewer contexts. (6 months, 65%). Watch for: subagent APIs or review modes that guarantee separate histories.
- Teams using EGM-like workflows will add project-specific review rubrics and document checks. (3 months, 70%). Watch for: customized review-loop configurations and repository standards.
Limits and uncertainty
The repository describes the workflow and installation paths, but it does not provide comparative measurements showing that EGM catches more defects, reduces rework, or improves delivery speed against an ordinary design review. “Thousands of Google engineers use EGM” is the repository’s statement, not an independently verifiable adoption analysis. The source also does not establish which supported environment produces the best review quality, how much token or execution cost a full review incurs, or whether fresh-context reviewers consistently avoid the same blind spots in large and unfamiliar codebases. Its safeguards are procedural: the user must still judge findings, approve trade-offs, and run tests.
Skill to build now
Pick one upcoming feature with a genuine design choice, such as retries, idempotency, permissions, or a data-retention rule. Before asking a coding agent to implement it, write a one-page design brief with the decision, alternatives, constraints, and open risks. Then have a separate agent session review only that brief and the cited repository material, with an instruction to list unstated assumptions and implementation blockers. Compare its findings with the original session’s plan and record which issues changed the specification.
Reader takeaway
EGM makes a useful distinction operational: the agent that understands a project deeply is not necessarily the best agent to challenge its proposal. For work with meaningful architectural choices, preserve the design artifact, review it from a fresh context, and require a human decision before implementation begins.
Open question
Will fresh-context review prove materially better than a carefully prompted review in the original agent session once teams measure defects, rework, and review cost?