| 1 | # 3. Summarization protocol |
| 2 | |
| 3 | Summarization is inevitable in long conversations. |
| 4 | The problem isn't summarization itself, but that after it the agent often "loses itself." |
| 5 | |
| 6 | ## Goal of the protocol |
| 7 | |
| 8 | Ensure that after context is cut the agent doesn't become a new instance with zero memory. |
| 9 | |
| 10 | ## Protocol (short version) |
| 11 | |
| 12 | 1. Capture in notes: |
| 13 | - what we did, |
| 14 | - what decisions we made, |
| 15 | - what's unfinished, |
| 16 | - which working rules were confirmed. |
| 17 | 2. First step in the new chat: read notes. |
| 18 | 3. Confirm that context is restored. |
| 19 | 4. Continue from the current point, not from the beginning. |
| 20 | |
| 21 | ## What must be in the summary |
| 22 | |
| 23 | - target task and current status; |
| 24 | - changed files / artifacts; |
| 25 | - open risks and blockers; |
| 26 | - working hypotheses already tested; |
| 27 | - the next step explicitly stated. |
| 28 | |
| 29 | ## Recovery protocol (human ↔ agent interaction) |
| 30 | |
| 31 | 1. The human triggers summarization manually (or it happens automatically). |
| 32 | 2. The human reminds: "summarization happened, read your notes." |
| 33 | 3. The agent calls `read_agent_notes` and restores context. |
| 34 | |
| 35 | Key point: initiative is on the human side, but recovery is on the agent side. Without an explicit reminder the agent after summarization may not realize it lost context. |
| 36 | |
| 37 | ## Common mistakes |
| 38 | |
| 39 | - A "pretty retelling" without operational details; |
| 40 | - no explicitly stated next step; |
| 41 | - recording only facts without decision logic. |
| 42 | |
| 43 | ## Success criterion |
| 44 | |
| 45 | After summarization the agent returns to working context in 1-2 messages without quality loss and without unnecessary clarifications. |
| 46 | |