TaskOnward · Free public beta
Why Chat Summaries Lose Decisions When You Switch Chats
A summary gives you a smooth paragraph. A new chat needs structure. Here's why the two are different — and what actually survives a chat switch.
Three familiar failures
Ask a long chat for a summary and you'll get a smooth paragraph. Open a new chat with it and watch three familiar failures:
- Decided things get reopened — “We already chose Postgres” becomes a fresh debate.
- Ruled-out ideas resurface — the approach you rejected on Tuesday is suggested again on Friday.
- Done work gets repeated — the new chat understands the project but not what's finished.
The problem is the shape, not the length
A summary is one narrative. Continuing work needs structure — six separate fields that a summary routinely mixes together:
| What the new chat needs | In a normal summary | In task state |
|---|---|---|
| Goal | Buried in narrative | Separate field |
| Confirmed decisions | Mixed with open ideas | Separate, explicit |
| Completed work | May be mentioned | Listed, won't repeat |
| Excluded approaches | Often omitted | Listed, won't resurface |
| Unfinished point | May not be highlighted | Explicit next step |
| Restore flow | New chat interprets freely | Restore, review, confirm |
What to do before you leave the old chat
None of this requires exotic tech. Write the six fields down before you leave the old chat, and make the new chat show them back for confirmation instead of silently guessing.
- Decisions need the why — without it, the new chat will relitigate them.
- Excluded needs the reason — otherwise the same idea returns wearing a different hat.
- The next step should be one action, not a roadmap.
See the restore-and-confirm flow
Task state is restored first and shown back to you. Confirm only when it's right, then continue.