This document covers session-local workflow modes. Plan, Light Loop, Lattice, and Boss Mode are owned by one session, while BlueprintLoop has a separate execution lifecycle bound to a session.
Synergy workflows change how a session should continue beyond a single model response. They are durable session modes with explicit completion rules, not prompt labels.
Only one of Plan, Light Loop, Lattice, or Boss Mode can be active on a session at a time. BlueprintLoop is the execution lifecycle for a Blueprint and can either be started by the user or owned by a Lattice step.
| Need | Use |
|---|---|
| Decide what should be done before execution | Plan |
| Execute an authored Blueprint with independent review | BlueprintLoop |
| Keep working on one bounded task until an independent reviewer accepts it | Light Loop |
| Decompose a larger goal into an ordered sequence of planned and reviewed steps | Lattice |
| Coordinate a tree of persistent specialist workers from one boss session | Boss Mode |
Normal chat remains the right choice when the work does not need a durable outer loop.
Plan turns a request into an authored Blueprint. The active agent can inspect context, research, ask blocking questions, and delegate analysis, but it does not carry out the requested outcome. For code work, that means no implementation or project-file edits; for external work, it means no identity-bearing action such as sending or publishing.
A useful Blueprint is decision-complete. It captures the goal, constraints, selected approach, deliverables, acceptance criteria, verification, risks, and relevant exclusions. Decisions that materially change the result should be resolved with the user rather than left for an execution session as TBD or an open question.
Blueprints are a specialized kind of Note. They can be read from any workflow, but note tools can create or modify them only while Plan or Lattice is active. Ordinary Notes remain writable outside those workflows.
BlueprintLoop binds a specific Blueprint version to an execution session. It resolves an execution agent, an audit agent, an optional model, and a run location:
- the current session
- a new session
- a dedicated worktree session
The execution agent reads the full Blueprint and any run-specific start instruction, then continues until it can provide concrete completion evidence. A normal assistant response does not finish the loop. On idle, Synergy wakes a running loop to continue.
When the executor believes the outcome is complete, it requests an audit. Synergy launches a reviewer Cortex task, normally using supervisor, which appears in the execution session's Task details on Workbench-enabled servers and inspects the Blueprint, start instruction, execution history, artifacts, workspace state, and verification evidence.
The reviewer has two outcomes:
- approve — mark the loop complete and return the audit summary
- reject — return concrete remaining work and resume execution
Only the recorded audit session can approve or reject that request. The execution session cannot approve itself.
Starting a user-owned BlueprintLoop exits Plan or Light Loop when the session is idle. A Lattice-owned BlueprintLoop is controlled by its Lattice run instead.
Light Loop is the smaller persistence workflow. It records one task description and wakes the same session whenever the agent becomes idle after a valid terminal response. The agent repeatedly checks the requested deliverables, current work, verification evidence, errors, and edge cases.
Completion is a review request, not a claim. Calling loop_stop launches a visible lightloop-reviewer Cortex child in Task details on Workbench-enabled servers and pauses generic continuation while review is pending.
- approval clears the Light Loop workflow and reports the verdict
- rejection records the review attempt, clears the pending stop request, and delivers actionable remaining work so the loop continues
Light Loop does not require an authored Blueprint or a multi-step Pathway. Use it for one task whose scope is already sufficiently clear. Light Loop and BlueprintLoop share a compact row at the bottom of the pending-message stack above the editor. A workflow icon, short stage and goal identify binding, execution, review, pause, rework and the authoritative result. Direct icon buttons open the Light Loop goal editor or Blueprint, and cancel the current loop. Editing is available while stopped outside review; running and reviewing goals remain readable. The ordinary message control still pauses or continues work. Review feedback and failures are available through the information icon. A terminal result remains inspectable without occupying the workflow slot; pending reads keep the row and never claim approval.
The row label is the saved Light Loop goal or the associated Blueprint note title. Keep it verbatim, truncate long labels to one line with an ellipsis, and expose the complete text on hover. Execution summaries and review feedback must not replace that identity.
Lattice coordinates a larger goal as an ordered Pathway. Every step has an objective, acceptance criteria, assumptions, status, and an associated Blueprint. Each Blueprint is executed and independently audited through BlueprintLoop before the Pathway advances.
A Lattice run moves through seven work states:
clarifying- align the goal, success criteria, constraints, non-goals, and assumptionsplanning- author the ordered Pathwayreviewing_pathway- check the proposed route and choose the next stepblueprinting- author and bind the current step's Blueprintreviewing_blueprint- verify that Blueprint before executionawaiting_execution- wait for explicit approval in collaborative modeexecuting- give the step to its independently reviewed BlueprintLoop
In auto mode, Synergy starts a reviewed Blueprint without asking for another approval. In collaborative mode, the run stops at awaiting_execution; approving the panel action starts exactly the reviewed Blueprint and does not attach an extra execution instruction.
The Pathway remains adaptive. After every successful step, a run with future work returns to reviewing_pathway, where unstarted steps can be reordered, refined, added, or removed. Completed history and prior BlueprintLoop attempts are retained. A failed or cancelled attempt pauses the run on the same step; explicit resume reopens that step for Blueprint work without erasing the failure evidence.
Run status is separate from work state. An active run can be paused, a paused run can be resumed, and cancellation is irreversible. An optional model-call budget also pauses the run when exhausted; explicitly resuming that pause grants exactly one additional model call. Starting a later run for the same session does not overwrite completed, failed, or cancelled Lattice history.
Boss Mode turns one session into the root boss of a worker tree. The boss session is the human's only entry point: you talk to the boss, the boss spawns specialist workers, assigns them tasks, and summarizes their reports back to you. Workers are persistent child sessions that work unattended and can spawn their own workers, so the tree can grow several levels deep.
Pick Boss from the workflow selector in the composer. The session must be idle, and the option is blocked while Plan, Light Loop, Lattice, or an active BlueprintLoop occupies the session. Enabling Boss Mode opens the Boss panel and marks the session as the tree root.
While Boss Mode is active, the composer shows its workflow chip. You can leave Boss Mode from the same selector when the session is idle; worker sessions and their history remain, and workers stop receiving new work once the root is gone.
In the Boss panel, use Spawn worker and give the worker a specialist role label (for example code, review, or research) and optionally a specific agent. The worker appears as a direct child of the boss session. A worker can spawn its own workers in turn.
Select an idle direct child worker in the panel and assign a task. The assignment is delivered to the worker's inbox and wakes it; the worker works unattended and reports back to its parent through boss_report. Cancel interrupts a running turn and removes that worker's pending assignments.
Boss Mode needs no manual recovery. Assigned tasks live in each worker's inbox, so after the runtime restarts, workers with pending tasks resume through the normal boot wake path, and the next turn refreshes the tree overview automatically.
BlueprintLoop, Lattice, Light Loop, and Boss Mode share one session drive. Every completion, Agenda wake, workflow resume, or active-turn release asks that drive to arbitrate instead of independently starting another model call.
When the session becomes idle, persisted Inbox work goes first. If no runnable Inbox item exists, the shared workflow gate acts only when:
- the session exists and is not archived
- no Cortex child task for the session is queued or running
- the latest reply-required user task has a terminal assistant response without an error
- no one-shot Agenda watch is still responsible for the next wake
Only wake-capable Agenda items with autoDone === true hold that final wait. Ordinary recurring or manually managed schedules can still wake the session at their trigger times, but they do not pause workflow continuation just because they remain active.
While a one-shot Agenda watch owns the next wake, stop tools (loop_stop, blueprint_loop_stop) refuse to run and show the cancellation commands needed to clear it. The wait ignores nextRunAt, so an overdue or just-fired watch continues to hold until it is cancelled, paused, removed, made silent or non-waking, or automatically completed. After automatic completion, the Agenda result is persisted before ordinary continuation resumes.
If more than one policy could react, the priority is BlueprintLoop, then Lattice, then Boss Mode, then Light Loop. Workflow continuations use stable Inbox delivery identities, so concurrent wake requests and restart recovery do not create duplicate continuation messages. Explicit Lattice resume and startup repair also enter through durable Inbox work before the shared drive; they do not bypass Inbox ordering or invoke the model directly.
This ordering gives the innermost execution loop control while a Lattice step is running, then returns control to the Pathway after the BlueprintLoop reaches a reviewed terminal state. Boss Mode continuation applies only to workers with an assigned task that has not reported; the root boss session remains human-driven.