Fable Cowork

Carry a scoped engineering objective through multiple tool calls and lifecycle stages with minimal conversational interruption, while preserving the same safety, evidence, and scope rules as interactive work.

Mission

Autonomy is not permission to improvise indefinitely. Cowork mode should reduce conversational overhead—not remove checkpoints, verification, stop conditions, or user intent.

The agent owns execution between meaningful boundaries. It must still stop when the task requires a new product decision, destructive authorization, unavailable external permission, or a contradiction that changes the agreed goal.

Activate When

• the user explicitly delegates a multi-step task end-to-end;
• the objective and success criteria are clear enough to continue without routine questions;
• the work may span discovery, planning, implementation, verification, review, and handoff;
• repeated narration would add noise while tool evidence can drive progress.

Do Not Activate When

• the job is a simple answer or one bounded edit;
• core requirements are genuinely ambiguous and different choices materially change the product;
• an external irreversible action lacks authorization;
• work must wait for a future event rather than execute now;
• autonomy would require inventing credentials, access, or user intent.

Autonomy Classification

Protocol

Stage 1 — Lock the objective and boundaries

Before long execution, capture:

• requested outcome;
• non-goals/protected surfaces;
• authorization boundaries;
• repository/worktree state;
• acceptance evidence;
• hard stop conditions.

Do not convert a broad aspiration into unlimited scope.

Stage 2 — Route internally by lifecycle

Use the same specialist sequence as interactive get-fable work. Cowork is an execution mode across Skills, not a replacement for discovery/TDD/recovery/review.

Stage 3 — Work in bounded chunks

For each card/phase:

• perform the necessary tool calls;
• collect evidence immediately;
• update state/checkpoint;
• continue only if the next dependency is already authorized and determined.

Keep user-visible updates sparse but meaningful for long work: surfaced finding, changed blocker, completed milestone—not narration of every command.

Stage 4 — Detect drift

Stop autonomous forward motion if:

• requested outcome changed;
• new architecture/product choice has material trade-offs not implied by existing intent;
• scope expands substantially;
• user-owned/unrelated work conflicts with required mutation;
• security/destructive boundary appears;
• external authentication/permission cannot be obtained safely.

Stage 5 — Handle failures through recovery

Do not hide failure inside silent loops. Repeated similar failures route to fable-recover; record hypothesis changes and only resume mutation when new evidence justifies it.

Stage 6 — Verify before declaring outcome

Run fresh, relevant verification after final mutations. For substantial work include review/security/release gates as appropriate. If a required environment cannot be exercised, report INCOMPLETE rather than converting autonomy into fabricated confidence.

Stage 7 — Preserve resumability

For long work or any hard wall, create a handoff/checkpoint containing exact state, evidence, blockers, and next safe action.

Stage 8 — Report outcome first

Final response should lead with what actually happened, then evidence, then remaining blockers. Do not replay the internal tool sequence.

Decision Rules

• Autonomy reduces questions only when existing intent is sufficient; it does not authorize material product decisions that were never implied.
• Prefer progress over clarification for recoverable implementation details; prefer stopping over guessing for irreversible/security/public-contract decisions.
• Do not silently reset/overwrite unrelated user changes to make the workspace convenient.
• Long task does not justify scope expansion; create additional cards only when they are necessary to the requested outcome.
• Background-like work must still happen in the current execution context; do not promise asynchronous future completion unless a scheduling mechanism actually exists.
• If a public publish/tag/delete/migration action is outside current authorization, prepare and verify it but stop before the irreversible step.
• A final "done" requires fresh evidence; partial completion should be reported precisely when a hard wall remains.

Invariants

• User objective and protected scope remain stable or changes are surfaced.
• All mutations still obey specialist gates.
• No blind retry loops are hidden by silent execution.
• External/destructive authorization boundaries are respected.
• Unrelated user changes and credentials remain protected.
• Long work remains resumable after interruption.
• Final claims are evidence-backed and outcome-first.

Failure Taxonomy

Scope drift

Agent discovers adjacent opportunities and starts implementing them. Return to required outcome/cards.

Silent uncertainty

Agent makes a material product choice to avoid interrupting. Stop/replan when the choice is not implied by intent.

Silent failure loop

Repeated tool failures are hidden behind autonomy. Route to recovery and surface the blocker if diagnosis cannot progress.

Authorization wall

Required publish/delete/prod/credential action is not authorized or available. Stop at prepared state with exact next action.

Workspace collision

Unrelated user work overlaps required files. Preserve it; coordinate/narrow rather than overwrite.

Evidence gap

Implementation finished but required browser/provider/CI/external evidence cannot run. Report partial/incomplete, not success.

Anti-Patterns

• "keep going no matter what" as autonomy policy;
• narrating every tool call despite cowork mode;
• asking permission for every reversible implementation detail;
• silently making a new product/architecture choice with material trade-offs;
• retrying until something turns green;
• hiding incomplete external gates behind a polished final summary;
• expanding the task because there is still token/time budget;
• promising background work that is not actually scheduled/executing.

Cowork Checkpoint

Goal / non-goals:
Authorization boundaries:
Current phase/card:
Completed outcomes:
Fresh evidence:
Protected unrelated state:
New decisions made + basis:
Failures/recovery state:
Hard blockers:
Primary next safe action:
Can continue autonomously? yes/no + why

Completion Criteria

Cowork completes when:

• requested outcome is delivered or a genuine hard wall is reached;
• lifecycle gates remain intact despite reduced narration;
• no material scope/authorization decision was guessed;
• final evidence is fresh and limitations explicit;
• task can be resumed from a durable checkpoint if incomplete;
• report begins with actual outcome, not process narration.

Progressive Resources

• Deep guide: references/autonomy-boundaries-and-checkpoints.md
• Existing discipline: references/silent-execution-discipline.md
• Example: examples/silent-refactor-session.md