Skip to main content
Threads are the core persistence unit in Aegra. Each thread represents a conversation with its own state, message history, and checkpoints. Runs execute within threads, and state is automatically persisted after each node execution.

Creating threads

Thread status

Threads have a status that reflects their current state:
The snippets below assume you are inside an async def function with an initialized client — see the example above.

Getting thread state

The state contains the current values of all state fields, information about what nodes will execute next, and any pending interrupts.

Updating thread state

You can modify thread state directly, for example to inject data or correct values:

Checkpoint history

Every state change creates a checkpoint. You can browse the full history:

Get state at a specific checkpoint

This is useful for debugging, replaying, or branching conversations from a previous point.

Searching threads

Find threads by status or metadata:

Listing threads

Deleting threads

Deleting a thread cancels any active runs and removes all state, including the checkpoint history stored in the graph backend:

Thread metadata

Threads automatically track metadata about their usage:
  • owner: User identity at creation time (mirrors user_id on the Thread object, which is used for access control)
  • assistant_id: Last assistant used
  • graph_id: Last graph executed
You can add your own metadata at creation or update time:

User isolation

When authentication is enabled, threads are automatically scoped to the authenticated user. Users can only see and interact with their own threads.