[vamsiraju]

Maybe we don't take sessions, but take something else that we can fully control. Sessions were always a poor substitute to capture or archive the basis on which the implemented code rested on. They get noisy over time even with compaction, were not always inspectable, no real science behind when to ditch a session and start a new one, and rarely have a clean mapping to the work done. So instead of trying to archive sessions as a means to preserve basis, we should create our own structures to make the agent/model capture basis outside of a session, and archive that instead.

[DenisM]

Suggestions? My attempts to get the agent to summarize the discussion largely failed. Other options I’m considering is capturing design, implementation plans, and maybe sub-plans. I’m Other words precursor to actions. Another idea is to get an agent to review code post-action and capture that. In other words action outcomes. The actual reasoning is between these “checkpoints” and remains hidden. But maybe that’s ok.

[vamsiraju]

What you said is pretty much the same somewhat tangential approach I am taking too. Force the agent to write code alongside another set of docs which form the basis- Intent (functional and non-functional requirements), Blueprint (architecture etc.), and Description files (describe the code at a high level alongside every source file). This information set is not the same as the reasoning/thinking trace information thats in the session, but reading this somewhat compressed set is easier, helps me better understand whats happening in the final output with lower effort than if i read the entire thinking/reasoning trace in the session and tried to grok what the agent did to generate the code.