Revision 13 to revision 40 in one evening of group chat

At 5:13 PM, the live board went from revision 13 to revision 19. A new idea landed with its own tiers and evidence. A recurring-pricing blank was added to the first idea. Two research actions were queued.

That was the first real run of the catch-up flow. It started at 4:52 PM and finished at 7:03 PM. Both research questions ended up answered on the board with their actions checked off, and a ready-to-send summary was waiting. The summary was the smaller part of the output. The board was the real one.

The chat was complete, but the work was not

A normal catch-up produces a concise recap and maybe a list of things to investigate later. That is the cheap version of this system.

This run relayed the day’s group chat onto the board. The new idea, Compliance Coordinator, landed as the front-runner with tiers and evidence. Claude handled the two same-day research actions: the Google Drive legality question and the competitive pricing scan. Both answers were posted to the board, and the actions were checked off.

A chat summary is a document. A live board is a working surface.

The failure mode was a missing edge

The board had advanced six revisions by the time the run ended. We wanted each posted answer to show which open question it settled.

Without that link, an answer lands in a chat, a note, or a new tab. Later we revisit the same question because nobody can see what the answer was supposed to settle. The visible symptom is repeated discussion. The cause is missing decision state.

So each surface got a narrow job. The chat is the input. The research actions are anchored to the board’s open questions. The final message is a handoff, and the board holds the state.

The second and third runs made the shape clear

Two more syncs came later that evening.

At 8:49 PM, a second sync added the fractional-COO ceiling and trademark willingness-to-pay evidence, moving the board from revision 26 to 29. At 9:23 PM, a strategy thread moved it from revision 30 to 36. That pass posted two blanks, two evidence items, a comment, and a chat summary.

The 9:59 PM sync took the board from revision 36 to 40. Its input was a LinkedIn and delivery-model thread. Its output was a distribution blank, pricing-trap evidence, a comment, a summary, and an attribution correction.

We keep the revision numbers on purpose. They let us check whether the system is accumulating usable state or just rewriting the same story in a more polished form.

What a catch-up should leave behind

We don’t want an agent to tell us what we talked about. We want it to leave the idea, its evidence, the unresolved question, the answer, and the exact point where a human has to decide. The message is a convenience. By 9:59 PM the board was at revision 40, and that was the record.

When an AI agent catches you up on a day of discussion, check where the result lives. Here the useful output was a board showing each idea, its evidence, and which open question each answer settled, with revision numbers to confirm the state was building up.

dxdev LESSON · paste into your AI coding agent
LESSON: A Chat Summary Is a Document; a Live Record Is a System
SOURCE: dxdev.com/blog/async-chat-to-research-loop
WHAT HAPPENED: A day of group-chat discussion covering a new idea, its pricing shape, and two open research questions was relayed into a structured, versioned record instead of a one-off recap. Every durable claim became its own field, every open question got queued as a research action while the conversation was still fresh, and every answer was posted back next to the specific question it resolved rather than written up as detached prose. A short human-readable summary was generated at the end, but it pointed into the structured record rather than replacing it. Two more passes the same day, on unrelated threads, added new fields and evidence the same way, plus one attribution correction, without losing track of which answer belonged to which question.
THE RULE: A chat thread and a plain recap both lose the same thing: the link between a question and the evidence that answered it. Anything worth deciding on needs a record that can hold an open question as its own addressable unit, so the research it triggers can be posted back to that exact unit instead of into a fresh document nobody re-reads against the original question.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any workflow that turns a conversation or meeting into a written recap with no structured, addressable field per open question.
  2. Any research, spike, or investigation step whose result gets written up as its own document instead of being attached back to the specific question that triggered it.
  3. Any place a claim's source or owner is stored as memory or prose ("someone mentioned") rather than as an attributed field that could be wrong and gets corrected in place.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.