Workday
Run a focused Pulse AI workday from board scope to dispatch, proof, and review.
Operating model outline
| Page | Reader job | Unique section | Media need |
|---|---|---|---|
| Workday | Turn selected board work into an active session | Before you start the day | Workday surface screenshot |
| Dispatch | Choose the right dispatch path | Pool dispatch vs direct dispatch | Dispatch workflow diagram |
| Board | Understand what can move | Lifecycle flow | Status flow visual |
| Review Queue | Decide the next move after completion | Review changes the next dispatch | Review evidence checklist |
Before you start the day
A Workday is not the whole board. It is the active operating session for a selected slice of work: a task, batch, sprint, sprint group, or reviewed workday pool. Start by confirming the board scope, the dependencies that must finish first, and the review state of recent work.
Use a focused Workday when the goal is clear enough to watch from request to evidence. Use a reviewed workday when the agenda is large or launch-critical and the first move should be a manager pass that chooses the right pool.
What the pool is allowed to do
The pool can queue eligible board items and dispatch them up to the configured concurrency limit. It should preserve context for blocked, done, or review items without treating those states as runnable work.
The pool is allowed to run items when the item exists on the board, its dependencies are satisfied, its status is dispatchable, and the requested scope matches the pool identity. It should not use empty slots as permission to pull unrelated backlog.
Watch the session
During a Workday, watch three signals together:
- Board state: todo, in-progress, blocked, review, and done show what the durable task record says.
- Pool state: queued, running, completed, failed, cancelled, blocked, and free slots show what the runtime is doing now.
- Evidence state: validation output, runtime proof, Knowledge Items, and review notes show whether the work is trustworthy.
Do not call a Workday healthy just because workers are running. A running worker can still be blocked, looping, or working from stale instructions.
When to pause, stop, or repool
Pause when the user needs to inspect cost, terminal output, or a risky active change. Stop when the pool is wrong, unrelated work entered, a terminal is stalled, or the next dispatch would waste credits. Repool only the remaining relevant items after the board source of truth has been reconciled.
If reload changes the visible pool, compare the new state to the board item and sprint group files before dispatching again. The durable board is the source of truth; the live pool is the current runtime queue.
Done with the day
A useful Workday ends with work in the right lifecycle state:
- Finished agent submissions move to review with proof.
- Blocked downstream work stays blocked with a clear owner.
- Approved work moves to done only after review.
- Follow-on work is added as a focused owner task instead of hidden in chat.