Sessions are implementation details. Work is the product surface.
What Changed
I am still iterating on the architecture, but the direction already cleaned up several design decisions:
- follow-ups route to tasks, not just the latest session
- retries can keep the same task identity
- reviewer agents can attach to the same task as editor agents
- approvals can be remembered at task or project scope
- channel messages can stay short without losing full traceability in the dashboard
This also made failure handling less awkward. If a runtime dies, the assistant does not need to tell the user "your session is gone, please start over." It can start a new runtime under the same execution or create a fresh execution under the same task, depending on what actually failed.
That is a small implementation detail with a large UX effect.
The Takeaway
I used to think agent memory meant better summaries of previous messages.
Now I think the more important question is: what are you summarizing into?
If everything collapses back into a conversation, the assistant will eventually lose the shape of the work. If the product has explicit projects, tasks, executions, and runtime sessions, the agent has somewhere stable to put its memory.
That has become one of the design principles behind CliGate.
If you are building coding agents, how are you modeling the difference between a conversation, a task, and a runtime session?