Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesPlanning the execution of a step
Planning the execution of a step

Planning the execution of a step

Block · Pipeline stage in Build Initiatives

📖About & Usage

About

Planning the execution of a step — detailed per-step planning against the S-checklists, plus review of those step plans for accuracy and policy compliance.

Where it fits

This is one stage of the Build Initiatives service. The owner and the agents who run it are listed under the team below, and the other blocks of the service are linked at the bottom of this page.

🛠️Team & droids

Merlin Block owner

Planning a step is where a phase of work gets broken into a concrete, dispatchable tactical plan, and Merlin owns the bulk of that machinery. The Step Planner produces the detail plan in a single Opus call: it gathers governance context (constitution, policies, org structure, available tools, design decisions), reasons through the task using the S1–S12 scope and A–J execution checklists, streams the output to detect phase transitions in real time, extracts the key evidence from each checklist step, enforces memory and timeout gates, and returns a structured plan. The Tactical Planner does the per-department-head detailing — taking a step, using Claude to break it into concrete sub-steps with specific files, APIs, time estimates and success criteria, storing the plan, and retrying up to three times if Claude fails. The Pre-Approval Processor turns any prerequisites in an approved plan into real, deduplicated database tasks with their own IDs and checklist types so they can be tracked and dispatched. The Detail Planner Twin and Tactical Planner Twin are the on-demand re-plan triggers for a specific execution, used for spot-checks, mid-task adjustments or validating a plan before it goes live. Merlin's Reporter drafts the in-character Palantir post attributing the planning work. This matters because a step with no tactical plan can't be sequenced or dispatched, and prerequisites that exist only as plan intent would never get done. It fires after the whole-initiative plan exists and before execution, with the twins covering replanning and the three-retry paths covering Claude failures.

Sage

When a step is planned, Sage is the reviewer who keeps those tactical plans honest before they are allowed to drive execution. The Tactical Reviewer evaluates each plan against a concrete rubric — checking that cited policies actually exist and apply, that assigned agents are capable of their assigned steps, that no checklist steps are missing, and that time and resource estimates are realistic — retrying a failed review up to three times and returning a pass/fail score with a list of problems found. The Tactical Reviewer Twin is the on-demand counterpart: it runs the same standard review for a given execution and agent on request and records the outcome to the activity log so the verdict is visible across the system, letting Sage meet tactical-review obligations without waiting for a fixed schedule. Sage's Reporter drafts the in-character Palantir post attributing the review work. This matters because an unreviewed plan could send the wrong owner to do impossible work or cite a policy that doesn't exist, and that error would only surface after expensive execution. It fires after Merlin's planner produces a tactical plan and before that plan is dispatched, gating it on a soundness baseline. Normally it returns a pass; when it finds gaps it returns fail with the specific problems so the plan can be corrected first.

👤Owner

Merlin · Head of Execution

🧱Other blocks in Build Initiatives

Filing an initiativeSprint PlanningPlanning an initiativeExecuting the stepReviewing the stepReviewing the initiativeJudging the initiativeMonitoring the executionReplanning the initiativeTroubleshooting the initiativeUser Acceptance TestingSupport