A team's AI notes got one thing wrong. Maya said "Friday is possible if the copy review is finished," and the notes recorded "Launch Friday" as a done deal. Then the AI built three tasks on top of that mistake: launch Friday, send the announcement, and close the checklist.

Pre Share lets Maya fix the decision once and see, before anything changes, which three tasks will change with it and which work stays untouched. She applies it all together, and one Undo puts it all back. If you use Figma, it's like editing a main component, except you see which instances will change before you commit.

Self-initiated. The notes tool (Meeting workspace in the prototype), the meeting and people are fictional, the mistake was planted on purpose, and no live AI runs inside it.

How it works

1. Say what was actually decided. Maya doesn't rewrite anything. She picks Confirmed, Conditional on the copy review, or Not decided.

2. See the reach first. A preview shows the decision and all three tasks, before and after. The research task is listed as staying the same.

3. Apply or undo, all at once. If a change ever reaches past what it's linked to, the product refuses the whole thing.

The tasks change in meaning, not just wording. "Launch Friday" becomes "Coordinate the launch once the date is confirmed," and the announcement waits until the launch is confirmed.

One honest note: we wrote the repairs and the links between items in advance, and no AI model runs inside the prototype. The checking, preview, undo and refusal are real, working code.

What the research changed

Other tools already do part of this. Granola lets you edit AI notes and check the transcript behind them. Otter can rebuild the summary and task list together after you fix the transcript, but its help center says you can't go back to the earlier version. So I narrowed the experiment: show the reach of a fix before it happens, protect everything else, and make the whole change reversible. How we researched it →

What went wrong

I keep the mistakes in these write-ups, because they're where the learning is.

• The first build passed 18 automated tests, and I once again found it way too confusing, exactly like the first build of project one.

• Early versions made the person do the note-taker's job, checking the notes by hand as a routine chore. Good notes shouldn't come with homework.

• We branded a feature as if it were a whole product. It belongs inside a larger tool.

• Both AI agents kept live AI in the plan. I approved it before I understood it meant real costs and upkeep, and when I did understand, I cut it.

• Our first research leaned on job posts and one help article, and it made the idea look more original than it was. Better research found Otter already rebuilds the summary and task list together.

• For nine build passes I was the one catching problems, and writing lessons down didn't stop them coming back. See the build history →

How this was made

I made this with two AI agents. I directed and made the final calls, GPT Astra led the research, design and build across eleven versions, and Claude reviewed the work at each checkpoint. Claude's reviews changed the most: it narrowed the scope so the person picks one of three answers and a fix can only change linked items, and it found three problems on a phone that I had been hunting for myself. Astra pushed back on four of Claude's points, and Claude accepted all four. Read the reviews → · See the key decisions →

The new rule from this project is that the agent who didn't build a version checks it on a phone, using a short checklist, before I see it. Its first run cleared the repeat problems and caught incomplete sources, which we fixed. Project three is the real test. See the checklist →

I also broke a promise. Project one said I'd report what this way of working costs, starting with this project, and I don't have reliable numbers. Project three tracks cost from day one.

What remains unproved

We haven't tested it with anyone outside the project, no real AI model was tested, and nothing here measures time saved. It shows one way to design the fix, working in code.

Next

Put it in front of people who have never seen it, connect a real model to see if its fixes stay inside their links, and run the checklist on project three from the very first build.