Playbooks

A playbook is a goal Cofounder defines, such as creating a brand identity or generating a video. Cofounder writes and maintains each playbook's instructions, so improvements reach every company on its next routine run.

A playbook run is your company pursuing one playbook. It is one agent in a sandbox that has the cofounder CLI, signed in as the person who started the run. The agent works in routine runs: each one is a turn of that same agent, so it keeps its context and sandbox from one routine run to the next. Routine runs happen on the run's schedule, or right away when you continue the run. The agent keeps its progress in two places: Library files people read, and progress notes it posts to the company's event log, tagged with the run's id, which cofounder events list --attribute run_id=<id> returns. When the goal is met, the backend completes goal-driven runs automatically and future routine runs stop. A company can have several playbook runs, of the same playbook too.

Find a playbook and start a run

start creates the run, starts its first routine run right away, and schedules the rest on the playbook's default schedule. It spends model usage. Generate a fresh --request-id UUID and reuse it if the response gets lost: the request id becomes the run's id, and reusing it never starts a second run.

Set --max-routine-turns <count> and/or --deadline-at <timestamp> on start or update to bound a run. The deadline must include a timezone. The turn limit includes the first turn, scheduled turns, and manual continue requests; replaying the same request does not use another turn. A failed or interrupted launch still counts once it has been admitted, because the runner may have accepted it. Historical successful turns count too.

Both limits default to unlimited. Updating one leaves omitted fields unchanged; an explicit JSON null in the update API clears that limit. Reusing a start request returns the existing run and does not change its limits.

At the limit or deadline, no new turn starts and scheduling switches off. The run stays incomplete, with its files and progress intact. Work already running, including verification, may finish. Raise or clear the limit and re-enable scheduling to resume; manual continuation also checks the limits.

Every run also has a budget: a lifetime cap on the company credits it may spend, set with --budget-cents <cents> on start. Without it, a run gets its playbook's default_budget_cents, which list and get show: $50 (5000) unless the playbook sets its own. The paid operations the run's agent performs draw from the company's credit balance as usual and count against the budget, net of refunds, along with holds for work still in progress. A charge that would take the run past its budget is refused, and the run pauses with reason budget_exhausted. Raise the budget with update --budget-cents <cents>, then resume the run with runs resume, which is refused while the run's spend is at or above its budget. Lowering a budget to the run's spend or below pauses the run. A paused run's limits and budget can change, but its schedule changes only once it runs again.

list and get include each playbook's prerequisite guidance and structured prerequisite_checks, with recovery instructions for requirements the backend enforces. If a prerequisite is missing, start returns a 409 error with missing_prerequisites before creating a run or schedule or launching the agent. Fix the missing input and retry with the same request id.

Manage a run

runs get shows a run's status (running, paused, completed, or cancelled), why a paused run is paused, its limits, budget and spend, schedule, and next routine run time. update changes the --schedule, a standard five-field cron expression (minute, hour, day of month, month, day of week) evaluated in the run creator's timezone, or turns scheduled routine runs on and off with --enabled. The run's agent posts progress notes to the company event log with events post; each playbook describes what its notes carry, and they read back through events list --attribute run_id=<id>. cancel permanently stops future routine turns and records cancelled, preserving files and verification history. Work already admitted may finish, but cannot mark the run completed. Repeating cancellation is safe. A completed or cancelled run cannot be reopened; start a new run to pursue the goal again.

Completion requires the nonempty Library files listed in the run's required_outputs, plus passing results for every required verification criterion. Saved Library files must still match their reviewed revisions. Editing a stage's files requires verification again. Missing files or unfinished, failed, or uncertain required judgments leave the run open. Optional criteria do not block completion. The backend checks after relevant Library writes, after judges finish, and before launching another turn. Disable a run's schedule with update --enabled false to pause it, or use cancel to end the run. For a playbook without verification criteria, completion checks that outputs were delivered, not their quality.

Required user_judge stages must pass before the run can complete. Approval passes a stage. Rejection fails it and gives the agent your feedback. Without a response, the stage waits.

Verification from a playbook agent

These commands require the company API key bound to a playbook run. Ordinary company keys and signed-in user sessions cannot call them. The backend selects the company and run from the credentials; do not supply a run ID.

cofounder playbooks verification show
cofounder playbooks verification show --stage voice
cofounder playbooks verification submit --stage voice

show returns the stages and statuses, or one stage's criteria, evidence, findings, and attempts. submit queues evaluation without waiting. Independent agent judges read the stage's saved Library files through Cofounder CLI and return a verdict and reason for each criterion. They run in their own sandboxes. Unchanged files reuse the same submission; interrupted jobs reconnect to the same judge. Binary checks and human reviews retain their configured Library inputs. Read the updated board with show. not_configured means no evaluation was queued, not that the stage passed.

Each run exposes a dated library_folder, for example general/playbooks/find-customers/2026-10-06_153000.000000Z. Save each stage under its key, such as .../icp/. The backend inserts this guidance in the run's goal.md. Choose useful filenames; the judge does not require a file schema or citation format. Keep canonical company documents in their usual locations and copy the inputs needed for this review into the stage folder. File revisions are recorded automatically. If they change, show asks for a new submission and the old pass cannot complete the run.

The commands appear in CLI help, but access is enforced on every backend request. They are not exposed as MCP tools.

Review a playbook's work

The playbook defines its review question and evidence in code. When the agent requests verification, Cofounder saves the submitted evidence. By default, the run creator gets an email linking to the dashboard review. When PLAYBOOK_DOT_REVIEWS is enabled for the reviewer and company, the review-request event triggers their subscribed dot instead of sending email. The dot presents the question and saved evidence, then asks you to Approve or Reject with an optional comment. The flag defaults off in every environment. The decision is saved to the same verification attempt: Eve reads the pass/fail result and your feedback with cofounder playbooks verification show.

Only that person's signed-in session can submit the decision, through the dashboard, CLI, or an authenticated MCP connection. A dot can present the request and record your explicit decision and comment. Company API keys, including the playbook agent's key, cannot approve the work. The dashboard shows the saved version, decision, comment, and decision time. A new submission replaces the pending request when its evidence changes. Replaced requests cannot receive a decision.

Use --decision reject to return feedback for revision. Repeating the same decision and comment is safe; a conflicting decision is refused.

For notifications in a dot or Work chat, connect the plugin and ask it to monitor playbook.review.requested for your company after the rollout flag is enabled. Plugin setup offers this subscription after selecting a company. Installation alone does not subscribe. The event contains the company, run, review, and attempt IDs; the dot reads the saved evidence before asking you to decide. It never treats the event as approval. New subscriptions cover new requests; playbooks_reviews_list finds earlier pending requests. With the flag on but no subscription, the request remains pending until you read and decide it; email is not an automatic fallback. Turning the flag off stops dot delivery and restores email for new review notifications. The dashboard continues to show saved requests and decisions.

Brand launch-post rounds

New brand identity runs end with launch-post variants from one canonical brand. Existing runs keep their saved stages. Each variant contains a styled image and caption or description. The playbook creates three variants by default. Each submission accepts one to six variants. It uses existing business documents and a brand kit. A built product or live website is not required.

Every new round requests an independent agent assessment and user review of the same saved evidence. The agent records each variant's verdict and comment, and recommends Pass or Iterate for the round. Its assessment is recorded for comparison and is not shown in the review UI. It does not control completion or replace your guidance.

Approve or reject any number of variants. Add feedback, including required guidance for each rejected variant. Choose Pass stage to approve this stage, or Request another round to continue. The dashboard saves your variant votes and feedback with this explicit round decision. Individual variant approvals do not pass the stage. New runs require only the launch-post stage and the saved canonical outputs to complete.

Eve reads your feedback on its next turn. Guidance that changes the brand must change canonical documents and assets first. Eve generates new variants from the updated sources. Requests for more expressions can reuse the current canonical brand. Changed sources or artifacts require a new submission. Saved rounds retain both judgments for comparison.

The agent acts as the run's creator through one company API key, named Playbook run <id> in cofounder company api-keys list. Each routine run keeps it valid for another 24 hours; a run that stops lets it expire. Because the agent acts with the creator's access, only the creator can update, continue, or cancel a run; any company member can list and read it. The agent itself can do anything the creator can do in the company except change billing, start, update, or resume a run, or decide approvals, so it cannot raise its own budget.

Continue a run and check its routine runs

continue starts one routine run right away, outside the schedule, and spends model usage like a scheduled one. Reuse its --request-id if the response gets lost. A routine run is starting until the runner accepts it, then started; one the runner could not take is failed, with the reason. An attempt blocked by the turn limit or deadline is skipped, with reason turn_limit_reached or deadline_reached. A reclaimed launch that may already have reached the runner is also skipped with already_admitted. What it produced shows up in the run's progress events and the Library files it writes.

Prerequisites are checked again before every manual or scheduled turn. If an input has been removed or archived, that routine run fails with a recovery message without launching the agent. Restore the input and continue with a new request id, or wait for the next scheduled turn.

Approvals

A run's agent asks for a decision by creating an approval: a social_post, email_draft, or other, with a title and a JSON --payload holding what the decider needs to see. Only a playbook run's own agent can create one, through the CLI, and it belongs to that agent's run. A blocking approval (--blocking; --no-blocking queues it) pauses the run: no routine run starts, on demand or on schedule, until it is decided and the run is resumed. A non-blocking approval queues while the run keeps going.

approve and reject only record the decision and optional --feedback; the agent acts on them in a later routine run. A decision is final; repeating it the same way changes nothing. Once no blocking approval is pending, the decision's next step is runs resume, which sets the run running and starts a routine run. The first routine run after a pause lists every approval decided since, with its feedback, even if an interrupted resume has to be retried. Resume spends model usage like continue, and its routine run still counts against the run's turn limit and deadline. A paused run can still be cancelled. Only the run's creator can decide approvals or resume a run, and the run's own agent can do neither. Anyone in the company can list a run's approvals and their history.

The playbooks

Brand identity (brand-identity) creates the company's identity, voice, and design kit. It requires general/ICP.md, general/product.md, general/value.md, and general/pain.md to already contain substantive business context. It does not create these prerequisite documents. The backend requires all four to be active Library files with nonempty stored content before creating a run and before each new turn. Missing inputs return specific recovery instructions; Eve and the verification judges check whether the answers are substantive and consistent. Before starting, it also requires a company brand design kit: a generated version or imported design kit in the company Library. Approval or locking is not required. Create a missing kit with cofounder company brand generate and inspect cofounder company brand get.

Existing runs created under brand-voice keep their saved key and settings path. Listing runs for brand-identity includes those earlier runs.

Start it with playbooks runs start. Its routine runs happen hourly until the backend automatically completes the run. It updates marketing/brand_identity.md, marketing/brand_voice.md, design/design-tokens.json, and design/brand-guidelines.md, using the existing brand tools for kit assets and their canonical design/brand-kit-versions.json history. Working notes, audits, candidate drafts, and trial responses stay in Eve's sandbox. The Library holds canonical company documents and reusable assets.

New runs verify the brand through the launch-posts stage. The identity, voice, and design-kit documents remain required source evidence, without separate agent approval stages. Save the variants in the Library folder shown by verification show --stage launch-posts. Automatic completion requires all canonical outputs and your Pass stage decision on the current submission; the agent's assessment is advisory. Existing runs keep the stages saved when they started, including any identity, voice, and design-kit checks on their verification board. Voice updates preserve founder-approved lines. The playbook does not lock a kit or deploy it to customer apps without the owner's authorization.

Generate video (video-gen) makes the video the user asked for. Its routine runs happen daily at 08:00: each finds the newest video request in the company's events, installs HyperFrames, authors an HTML/CSS/GSAP composition, renders it, and improves the video's overall quality. It saves the MP4 to playbooks/<run id>/video.mp4 in the Library. It saves your brief to playbooks/<run id>/video-brief.md. A reference video is optional; your written request can serve as the brief. Its progress notes hold the request, production status, deliverable path, and next steps.

The required final-video stage asks you to review the video. The agent requests your approval after saving the brief and playable MP4. It waits for your decision and uses rejection feedback on its next turn. After approval, the backend completes the run automatically if the saved work still matches the reviewed version. An unclear request, blocked render, or missing approval leaves the run open.