Threads, runs, and cards
A work thread is the durable conversation and context container. It tracks channel, creator, backend state, timestamps, messages, run records, cards, memory proposals, and any action requests raised by the work.
| Entity | Purpose | Typical owner |
|---|---|---|
| work_thread | Conversation, channel state, and accumulated context | Operator or channel plugin |
| work_run | One agent execution with backend, status, error, actor, and timing fields | Worker |
| briefing_card | Structured summary or recommended next step shown in the UI | Agent or workflow |
| workflow_output | Reusable artifact, report, observation, or generated summary | Workflow run |
Identity and actor
Records that matter for governance carry actor fields such as actor_user_id, actor_role, backend, and run references. This allows the control plane to distinguish a human request, an agent run, a plugin action, and a workflow-triggered action.
When dual-identity audit is enabled for an org, audit records can preserve both the human operator and the executing agent context. The feature flag controls availability; the schema already includes the fields needed to record the chain of responsibility.
Queues and workers
The worker owns asynchronous work: running agent jobs, evaluating watchers, dispatching plugin actions, executing approved actions, extracting memory, and sweeping feature-gated behavior alarms.
- Approved action requests enqueue execution work.
- Watcher hits enqueue workflow fires with singleton keys to avoid repeated runs.
- Memory extraction creates pending memory for review before team context changes.
- Behavior alarms run only when the behavioral_alarms feature is enabled.