Work orders and planning
Track a goal across dependent work items and multiple workflows.
A work order groups the cards needed to achieve a goal. Its rollup includes progress, active runs, blocked work and tokens across workflows.
Plan the work
Describe the goal and constraints. A planner can propose items and dependencies. Review the proposal before turning it into cards: check the scope, acceptance criteria, destination workflows and ordering.
A work order can also arrive from a linked OpenBook space as an epic: the planner writes its stories, and they wait for a person's approval before any card exists. See epics from OpenBook. The concierge can open a work order for you as well, with its plan lines as proposals.
Templates make recurring work orders reusable. Dependencies determine which items are waiting on others. The critical-path and risk views help explain why a goal may be delayed, and the report can be printed for review.
Planning history
Open a work order and expand Planning history in its plan. The latest 50 invocations show the planner, plan or replan, instruction version, status, attempted model calls and recorded tokens. A replan links to the preceding invocation. Failed or partial attempts remain visible with their reason; proposals saved before a provider failure remain in the plan.
The planner uses the instruction release configured in Agent studio. It selects a version before the first model call and retains it throughout that invocation. A later replan selects the release current when it starts. Without a release, the history labels the invocation Live instructions. Historical work orders from before this feature have no invented history.
Each invocation also has Model input history. It lists the latest 50 prepared inputs, including fallback attempts: turn, model, input bytes, shortened earlier items, approved-memory inclusion and omission, request hash, and the person or factory-supervisor replan that authorized it. These are fitted logical requests prepared for Bookbag SSO. They do not prove provider delivery or replay historical prompt bodies.
Approved memory refreshes before each turn. CodeBook checks current access, goal, pause state, tool permissions and applicable supervisor authority before a call and again before using its answer. If those change while an answer is pending, planning stops; earlier proposals remain inert and autonomous replanning does not create cards from them. Ask for a new plan after resolving the change.
Completion records that planning ran, not that its proposal was correct. Review the proposed scope and acceptance criteria before creating cards. Planner execution counts stay separate from station quality results.
Control execution
Pause or resume a work order when priorities change. Cancellation includes cleanup of the tracked work, but cannot undo external effects already performed. Inspect active external runs and repository changes before assuming a cancellation reversed them.
The planner proposes work. A workflow supervisor handles bounded exceptions during execution, a specialist can take one class of failure, and a factory supervisor sits above every workflow with a closed list of options, including replanning the unmet rest of a partially met work order. See factory supervision. Nothing in that ladder learns from outcomes; a person raises autonomy, and a person is asked past every limit.
Use operations for active work and events to connect external outcome signals.