Threads
Threads are the inspectable trail of a run.
They hold the user request, model responses, tool calls, approvals, attachments, summaries, and completion state on one timeline.
Canonical History
Decubed treats thread history as append-only and event-based.
The canonical persisted surface is the ordered event stream for the thread, not a hidden provider transcript and not a UI-only chat array.
Materialized Current State
The product still needs a fast current view, so Decubed materializes the latest state from the event history.
That current view exists for product ergonomics, but the event log remains the source of truth.
This matters because it keeps three things compatible at once:
- durable auditability
- fast UI reads
- safe compaction and replay
What A Thread Preserves
A useful AI thread needs more than message bubbles.
Decubed keeps a trail that can include:
- user and assistant messages
- tool requests and tool results
- approvals and permission outcomes
- summaries
- run metadata
- attachments and file references
That is what makes the workspace inspectable instead of theatrical.
Compaction Without Losing The Trail
Long threads eventually need summarization.
In Decubed, compaction is represented as a normal thread fact. The summary can help with future prompt assembly, but the canonical history still exists as the durable record of the thread.
Why Threads Are Separate From Memory
Threads capture what happened on this trail.
Memory captures what should stay reusable outside this trail.
That boundary matters because not every message deserves to become durable recall.
What Users Get From This
When the thread model is explicit, users can:
- review why a tool was called
- inspect when approval was required
- understand what the model saw
- carry the same thread history across provider changes