Big Idea

The argument in one line.

Plans get better when the agents that review them have zero memory of how the plan was made, because an agent that sat through your chat just agrees with itself.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You build apps with Claude Code or Codex and keep finding gaps in the plan only after the agent has already built the feature.
You're about to add a large feature to an existing codebase where a wrong call would be expensive to undo.
You already use plan mode and want to know what a heavier, spec-driven alternative adds on top of it.

SKIP IF…

You mostly ship small fixes an agent can do in one pass, since Google itself says the planning overhead slows those down.
You want a quick tool-install walkthrough only and have no appetite for approving a plan section by section.

TL;DR

The full version, fast.

The Elephant-Goldfish Model is Google's open-source, spec-driven planning workflow for coding agents. The elephant is the part with full project memory that brainstorms with you and writes the design. The goldfish are zero-context subagents that only see the plan and the code, so they can't be talked out of finding problems. The flow runs bootstrap, brainstorm, draft, a five-round review and later a drift report. It's worth it for large, risky features and overkill for small fixes.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:47

01 · Intro

The promise: a workflow that catches problems before the agent builds, and a real bug it caught.

00:47 – 01:43

02 · What it is

Google's spec-driven planning method, based on Dave Rensin's article and free on GitHub.

01:43 – 03:02

03 · Elephant vs goldfish

The memory-rich planner versus the zero-context reviewers, plus the human as the third role.

03:02 – 04:54

04 · Why not plan mode

Plan mode lets the agent agree with itself; goldfish can't see the chat and the review runs through one orchestrator.

04:54 – 06:07

05 · Install

One install prompt per agent; it adds agents, egm and skills folders under .claude.

06:07 – 07:08

06 · Fixing CLAUDE.md

The generated CLAUDE.md wrongly says subagents can't spawn subagents; Claude tested it and corrected the line.

07:08 – 09:29

07 · Bootstrap

The bootstrap command writes a README per code folder, then CLAUDE.md files so agents actually read them.

09:29 – 10:18

08 · Sponsor: Hedra

Sponsor segment for Hedra's app-promo video tool.

10:18 – 11:32

09 · Brainstorm

Interview-style questions, a proposed approach, then six goldfish review it into a concept brief.

11:32 – 12:42

10 · Draft

The design draft is written and approved one section at a time, ending with alternatives and a build plan.

12:42 – 13:50

11 · Review

Five rounds of goldfish review, each with a report, ending with status moved from In Review to Proposed.

13:50 – 14:35

12 · Drift report

Compares the app to its READMEs and found sold products could be deleted against the written rule.

14:35 – 15:54

13 · When to use it

Worth it for large, costly features; skip it for small fixes. Verdict versus other planning workflows.

Atomic Insights

Lines worth screenshotting.

An agent that watched you plan will mostly agree with its own plan, so a reviewer with no memory of the conversation catches more.
Zero-context subagents can't be influenced by anything you said earlier, which is the whole point of the goldfish half of the workflow.
Plan mode usually ends with a plan that misses details, and you only discover the gaps when they surface mid-build.
The review produces a lot of notes on purpose, and the human's job is to keep what's useful and ignore the rest.
One orchestrating subagent that launches the reviewers keeps the main agent's context from bloating with reports.
Bootstrap writes a README for every code folder, but agents won't read those files unless a CLAUDE.md or AGENTS.md tells them to.
An install can write a wrong instruction into CLAUDE.md from stale memory, such as the claim that subagents can't spawn subagents.
Writing the design one section at a time with approval after each stops later sections from building on an unreviewed foundation.
A design doc that lists alternatives considered, with the pros and cons of each, records why the chosen path won.
A drift report compares the written plan against the live app and flagged a real bug: sold products could be deleted when the rule says hide only.
Most planning workflows check one feature right after you build it, while a drift check can audit the whole app against its contracts later.
Google says the heavy process isn't worth it for a small change an agent can do in one go.

Takeaway

Plan with memory, review with none

WHAT TO LEARN

A plan is only trustworthy once it has been attacked by reviewers who never saw how you arrived at it, and the heavy process only pays off on large features.

03Elephant vs goldfish

Split planning from criticism: one agent holds the project memory and writes the plan, while separate zero-context subagents review it so no earlier conversation can sway them.
Give the human the final say on a deliberately noisy review, keeping the useful notes and discarding the rest instead of auto-applying everything.

04Why not plan mode

Plan mode tends to end with the agent agreeing with its own plan, so gaps and edge cases show up mid-build and force a re-plan.
Use one orchestrating subagent to launch reviewers and merge their reports, which keeps the main agent's context small and hands you a single report.

06Fixing CLAUDE.md

Check what an installer writes into CLAUDE.md, because it can encode stale assumptions, such as the idea that subagents can't launch subagents.
Verify a doubtful instruction by testing it with the agent instead of trusting the line, then correct the file so the method runs as intended.

07Bootstrap

Per-folder READMEs only help if agents are pointed at them, so add a CLAUDE.md or AGENTS.md next to each or a line in the root file.
Run a bootstrap pass first so the planner knows how the existing app is structured and what rules must always hold before it plans anything new.

09Brainstorm and draft

Answer the brainstorm questions until the problem is clear, then let six fresh reviewers critique the approach and produce a written concept brief.
Approve the design section by section, from goals through technical plan and alternatives considered, so later sections never build on unreviewed ones.

11Review

Run review in rounds, reading each round's report and applying fixes before moving on, then close the review so the plan flips from In Review to Proposed.
Build the feature in a fresh chat from the single design file, so the agent works from clear rules rather than leftover conversation.

12Drift report and when to use it

Run a drift report later to audit the whole app against its written contracts, which surfaced a real bug where sold products could be deleted instead of hidden.
Reserve this heavy workflow for large features where a mistake is expensive, and skip it for small fixes where the planning only slows you down.

Glossary

Terms worth knowing.

Elephant-Goldfish Model (EGM): Google's open-source workflow that pairs a memory-rich planning agent with zero-context reviewer agents to stress-test a plan before code is written.
Goldfish: A subagent with no memory of your conversation. It sees only the plan and the code, so it reviews without being swayed by what was discussed.
Spec-driven development: Writing a complete plan for the app first, then having the agent build by following that plan.
Concept brief: The file produced after the brainstorm and the first goldfish review, covering the feature, findings, blockers and what must be done.
Design draft: The first version of the plan, built section by section: overview and goals, user journeys, technical plan, alternatives considered and a step-by-step build plan.
Critical user journeys: The main paths a person takes through a feature, listed in the design so tests can be written against them.
Drift report: A check that compares the written plan or README contracts with the current code and lists where they no longer match.

Resources

Things they pointed at.

00:58linkElephant-Goldfish Model on GitHub ↗

00:58bookElephants, Goldfish, and the New Golden Age of Software Engineering (Dave Rensin)

09:30productHedra ↗

00:00linkAI LABS community ↗

Quotables

Lines you could clip.

03:35

“When it checks the plan, it basically just agrees with itself.”

Short, memorable diagnosis of why same-chat review fails.→ TikTok hook↗ Tweet quote

03:53

“That's why the goldfish is not allowed to see your chat.”

States the core design rule in one line.→ IG reel cold open↗ Tweet quote

14:35

“Google says it isn't worth it for a small fix your agent can do in one go.”

An honest limit that makes the rest of the pitch more credible.→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

There's a new way to vibe code by Google called the elephant goldfish model and it's built to catch problems before your agent builds anything. Usually when you ask your agent to build something, it just builds it and you only find the problems after. But with this one, your agent's work gets torn apart first.

The elephant and the goldfish in the name are two different kinds of agents and the names tell you exactly how each one works. And the way Google keeps those two apart is what makes it different. Out of all the other workflows we looked at, only one does anything.

like it we tried it on our own app with a new feature and it caught a real bug that the usual review missed if this is your first time we're a software company and this is our channel ai labs and in this video we're going to show you what the elephant goldfish model is how it works and how to use it on your own app now the elephant goldfish model is google's way of thoroughly planning what you want to build before you actually build it it's google's take on spec driven development where you write down the complete plan for your app first and then the agent builds the app by following that plan.

It was developed by engineers at Google, and it's based on an article written by Dave Renson called Elephants, Goldfish, and the New Golden Age of Software Engineering. And it's free for anyone to use on Google's GitHub. It uses multiple agents and skills to basically plan your app in a way that leaves no angle untouched and leaves your plan complete without any gaps in it.

So that when your agent is implementing the plan, it doesn't have anything to guess while building because everything is documented, which makes it easier to build on top of. And you don't just get a plan, you also get a checklist of what needs to be built and how to test it to make sure everything works the way you want it.

That way, you know the feature is complete. But before we go install the tool, let's understand the core philosophy of this model. This model works around two roles, the elephant and the goldfish, just like their names suggest.

The elephant represents the part of the workflow that remembers everything about the project. It knows the whole history of your project, how your app is actually put together, and people use it for.

This is the part of the workflow that's responsible for actually talking through the idea with you in depth, thinking about it from different angles, seeing where it might fail, and writing the detailed planning files that form the base of the plan. The second part is the goldfish, which is the part of the workflow that doesn't remember anything.

These are sub -agents that have zero context. They only see the plan and your app's code, and they never see what you and the main agent talked about, so nothing you said earlier can influence them in any way. Goldfish look at the plan differently from the other agents.

There are multiple angles they look at the plan through. One checks if there's an easier way to do it than the plan says or if your app already has something that does the job. Another reads it like someone who knows nothing about your app and checks if it still makes sense.

One looks for issues that come up when the app reaches a lot of people and they all use it at once. And another checks if the plan is clear enough that a model could build it without having to guess anything. A couple more check how the plan itself is written and set up.

The elephant and the goldfish work together to create a final plan they both agree on and the other agents use that plan as their starting point. Now you might think that most agents already have a plan mode, so why would you need to go through this whole process at all? When you plan something with your model, it usually goes like this.

You explain your idea, it asks you a few questions about the major details it can't decide without your input and then it writes the plan. That plan misses details and issues that come up later on and you then have to revise it again to deal with those issues.

This model lets you have a complete plan that's been analyzed from every angle and doesn't leave any gaps so that when you're working, those issues don't come up, no matter how many people are using the app. The other benefit comes from the goldfish. When you use the plan mode, most of the work happens in the same chat.

This matters because the agent already knows what you discussed about the plan. So when it checks the plan, it basically just agrees with itself. Google says the main problem with models is that they stick to their own wrong ideas.

and agree with what you want instead of catching mistakes. That's why the goldfish is not allowed to see your chat. But all of these sub -agents give you a lot of notes, and that's where the third role comes in, which is you.

The model comes up with ideas and checks the plan, but you're the one who makes the final calls. Google says the review gives you a lot of notes on purpose, so you keep what's useful and ignore the rest. The sub -agents grade the plan using a set of written rules that act as checklists of what a good plan should have, and this review uses one sub -agent that starts a set of other sub -agents.

This keeps the main agent's context from getting bloated by all the reports the other agents write, and that one agent then combines them into a single report, which is the only one you review. And even after the feature is built, the plan helps a lot. Later on, a check called drift compares the plan with your app and points out every place where they no longer match.

Then you decide which one to fix. But before we install it, it would be great if you subscribe to the channel and hit the hype button. This small gesture of goes a long way for us.

Now this tool is available for whichever agent you use whether that's Claude Code, Codex or any other. The repo has a separate install command for each one and you can copy whichever one you need or you can just copy the install prompt from their website which is just the word install followed by the link to the repo and paste it into your agent.

When you send that prompt it runs all the steps to download the repo and set it up in your project. Since we were using Claude Code it also wrote a claude .md file so it could put the instructions for this tool in there and there's one line in that file you'll want to check which we'll get to in a second.

When it's installed you'll find three new folders inside your .cloud folder. One of them is called agents and it holds all the agents that the method uses. These are the goldfish in the method that we talked about earlier.

The second folder is egm which is just a full copy of the repo and there's a skills folder too which holds all the skills that run each step of the method. These are the elephant part of the workflow. The main one is the brainstorm skill which basically takes your idea and turns it into a clear plan of attack.

It asks you lots of questions and keeps going until the problem is clear. There's also a review skill that starts the goldfish review. It has all the steps for reviewing your plan and calling in the sub -agents.

But like we said, the install also writes some instructions into the clod .md file. So the line you'll need to check is near the end of this file and it says that clod codes sub -agents can't start sub -agents of their own. That's because older versions of Claude Code couldn't do that, so it wrote that from memory.

But the new version of Claude Code actually lets a subagent start other subagents, unlike what the line says. So when we asked about this, Claude said it had written the claude .md file on its own, and that no step in the repo had told it to write it. We told it that line was wrong, and that the review subagents can start their own subagents.

So it tested it, and when it saw that it does work in Claude Code, it changed that line so the method could run the way Google meant it to. You might not run into this because they're updating the repo pretty often but that's what happened when we were recording so it's worth checking that file.

If you see a line like this in your claude .md ask claude to fix it too or you can just copy the install command for the specific agent you're using and it will install it directly for that agent without any conflicts like this. Now we tried this on a demo fashion app that we had already built. Most of the app was done and we were just adding new features to it.

The one we wanted to add was a page that shows each seller which sizes are selling which ones have sold out and when they should restock the workflow actually starts with brainstorm but before we move on to that we need to run another command we need to run the egm bootstrap command this command tells the elephant everything it needs to know about the app and how it works before it can plan anything new on top of it this command goes through your app one folder at a time and writes a readme file for each folder that explains what the code in that folder does and all the rules it has to follow but before it starts if your app has more than 15 folders it will check whether you still want to write the full mapping or not it does that because writing readme files for that many folders takes a lot of sub -agents so it checks with you first whether you want to do it or not so we told it to keep going and it got to work it started sub -agents and each one worked on a different part of the app when they were done they wrote the readme files in our case it wrote 28 new readme files and also updated the main readme file we already had so in your main readme file there will be

new section that wasn't there before it lists what each part of the app does the rules that always have to stay true and what changes when it runs every folder that has code in it gets its own readme file it tells you what the folder is for what's inside it what each part does and how the parts connect the folders with no code in them don't get a readme file for example we had a specs folder with the plans we used to build the app so it didn't get one but there's a problem with it writing the files as readmes these files are written for people to read not for other agents.

So agents don't normally read them unless you tell them to. That means if this command only writes readme files, Claude Code won't read them on its own. There are three ways to fix this.

First, you can add a claude .md file next to each readme file and tell it to check the readme file too. If you're using Codex, you can use an agents .md file instead. Second, you can run the bootstrap command again and add a setting that tells it to create claude .md files from the start.

Or third, you can add a line to your main claude .md md file telling it to read the readme file in every folder it works in we added a claude .md file next to each readme to make sure claude follows them correctly now once the readme files are done you can move on to the next step but first let's have a word by our sponsor hydra now if you want to make a video for your app but don't know what to say or show in it you can ask hydra to help you figure that out we gave it our app's details and asked it to research who the promo should be for it found sources and suggested what to focus on then ask questions about video.

The agent updated our brief and storyboard, which lay out the message and what happens in each shot. They're on the canvas next to our chat, inside a space, which keeps the project's work together. We read the brief, then asked Hydra to make the promo.

It asked for approval before generating a logo and a reference image of an office worker to guide how the video looks. Then it used those images to make the video. We played the promo inside Hydra, ending with our logo.

So, if you need help figuring out what your app's promo should say, try Hydra free through the link in the description and use this code for 50 % off your first month. And once Bootstrap is done, the next step is to actually start building.

All the steps are listed in the GitHub repo and you can run them one at a time. The first step is to run the EGM brainstorm command and tell it the feature you want to add. When we did this, it found that we already had a written plan for this feature.

It pointed out everything wrong with that plan and then asked us a bunch of questions. If you don't already have a plan like we did, it'll ask you even more questions. You just need to keep answering them, and when they're all answered, it gives you its best guess for how to build your feature.

Then it gives you two choices. The first is to review it with the goldfish, which runs six goldfish that each look at it in a different way and then writes up the idea in a file called the concept brief. Or if you don't think its approach is right, you can explain more in the chat.

We thought it was good enough, so we chose to review it with the goldfish. It starts one sub -agent, which starts six more in the background. Each one starts fresh and no - nothing about your chat when they're done it writes the concept brief file this file is in the main folder of your project it explains the feature what it found when it looked into it what's standing in the way and everything that needs to be done you can read it to see if it matches what you want you can ask for as many changes as you like but if you're happy with it the next step is to run the egm draft command this command takes the concept brief file and writes the first version of the plan called the design draft it explains the feature the problem it solves and what it will and won't do so nothing gets lost.

It also lists the main paths a person takes through the feature which are called critical user journeys so we can write tests against them. So you'll need to approve this file and when you do it makes changes to it. It writes the plan one part at a time and waits for your approval after each one so you can steer it before the next part gets built on top of it.

Next it adds the technical plan which is how the feature will actually be built. When you approve it, it adds a section called alternatives considered. That lists the other ways the feature could have been built, with the good and bad sides of each, and why they weren't picked.

When you've read the alternatives, it moves on to the step -by -step building plan. It keeps updating all these sections in the design draft file, and when it's done, it saves a file named after the feature in the designs folder inside the docs folder. That designs folder is where every feature you build this way gets saved, and it's what you'll be asking your agent to build from.

But this whole plan was written by the same agent that's been agreeing - with you this entire time. So before anything gets built, it goes to the goldfish.

To do that, you need to run the egm review command and it starts with a subagent called zoom out. It checks if there's an easier way to build the feature or if the app already has something that does the job and it knows nothing about your chat. When this subagent is done, it writes a report with a list of all the big problems.

The review happens in rounds and in each round, the plan gets checked in one way and the subagent reports what it found. After each round, you can move to the next one or ask for changes there are five rounds of review in total and the tool numbers them from five to nine after each one it writes a report for that round and updates the plan in the designs folder based on what it found you can ask for fixes wherever you need them and when all the rounds are done you end the review it then changes the plan status from in review to proposed and marks the review as finished so basically what you end up with is one file in your docs designs folder that you use when you ask for the feature to be You can open a new chat and ask your agent to build the feature in this file and it gets to work.

This way, the tricky cases get worked out before anything is built and the result is much better because Claude has clear rules to follow. But once the feature is built, your app keeps changing and the files don't. So it also has a command that checks if any part of your app goes against the readme files.

To use it, you just run the egm drift report command and it asks you how much of the app you want it to check. We asked it to check against all the readme files files and it started two sub -agents to look at different parts of the app.

When both of them came back, it made a full report showing what had changed and where the app and the readme files no longer matched. It even caught real bugs in the code. For example, in our app, shop owners could delete products that had already been sold, even though the rule says a product that has sold can only be hidden, not deleted.

It listed everything it found and you can ask it to fix the problems in each part of the app, which makes your app much better. Now, this workflow is actually good if you're planning a large feature that's going to cost you a lot if it goes wrong.

That's because it went through the edge cases and possibilities more deeply than the other ways we've tried. But even though it's good, that doesn't mean you should use it for everything. Google says it isn't worth it for a small fix your agent can do in one go, because on small changes, all this planning and reviewing just slows you down.

And this isn't the only way to plan with agents. There are a lot of others. With most of them, you do get a written plan, but finding out what's wrong with them is a hard part with this one the goldfish finds it for you and since they never see your chat nothing you said can talk them out of it out of the ones we looked at only few others do something like that and after you've built this one can go back over your whole app and tell you where it no longer matches the plan while the others mostly check one feature at a time right after you build it so even though it takes longer on the features that matter it's worth using now we've made a simpler version that does the same thing but without going as in -depth as the original does by default So if you've found value in what we do and want to support the channel, this is the best way to do it.

The link's in the description. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below.

As always, thank you for watching and I'll see you in the next one.

The Hook

The bait, then the rug-pull.

Most agents build first and show you the problems afterward. Google's Elephant-Goldfish Model flips that: your agent's plan gets torn apart by reviewers with no memory of your chat before a line of code is written.

Frameworks

Named ideas worth stealing.

01:43model

Elephant, Goldfish and Human

Elephant: remembers everything, brainstorms and writes the plan
Goldfish: zero-context subagents that review the plan
Human: makes the final calls on the notes

Three roles keep planning and criticism separate so reviewers can't be influenced by the conversation.

Steal forany plan an AI agent writes before building

07:08list

The EGM command flow

Bootstrap
Brainstorm
Draft
Review
Drift report

Map the codebase, turn an idea into a concept brief, write the design section by section, run five review rounds, then audit the app against the plan later.

Steal foradding a large feature to an existing app

02:26list