Catching Up Async: From Group Chat to Board Evidence

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, with both research questions answered on the board, actions checked off, and a ready-to-send summary waiting.

The important part to me was not the summary. It was the board.

The chat was complete, but the work was not

A normal catch-up would have produced a concise recap and perhaps a list of things to investigate later.

That is the cheap version of this system.

What the first run actually did:

• The day’s group chat was relayed onto the live board.
• The new idea landed as the front-runner, with tiers and evidence.
• Two research actions were queued.
• Both answers were posted to the board and the actions were checked off.
• A ready-to-send summary was waiting.

Claude handled the two same-day research actions.

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

The diagnostic was a missing edge

The board had advanced six revisions.

By the end of the run, the Google Drive legality answer and the competitive pricing scan were posted to the board. I wanted the board to show which open question each answer settled.

That was the failure mode I was trying to prevent. Without that edge, we get an answer in a chat, a note, or a new tab, then revisit the same question later because nobody can see what it was supposed to settle. The visible symptom is repeated discussion. The actual problem is missing decision state.

The alternatives were simpler: keep a daily summary in chat, queue research separately, or maintain a board with no final message.

Each one breaks at a different point. Chat-only capture has no durable working surface. Standalone research has no anchor to the question. Board-only updates create friction at the handoff. The catch-up flow needs all three surfaces, but it gives each one a narrow job.

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.

That is why I kept the revision numbers. They are not decoration. They let me inspect whether the system is accumulating usable state or merely rewriting the same story in a more polished form.

A catch-up should leave evidence behind

I do not want an agent to tell me what we talked about. I want it to leave the idea, its evidence, the unresolved question, the answer, and the exact point where we need a human decision.

The message is not the source of truth.

By 9:59 PM, the board was at revision 40.

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/2026-07-09_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.