Auto-Continue Mode
Disciplined automatic continuation through multi-step tasks. Eliminates unnecessary pauses while preserving mandatory safety gates.
Core Principle
Auto-continue through unambiguous work. Stop only at real decision points.
Mandatory Gates (ALWAYS STOP)
| Gate | Trigger | What happens |
|---|---|---|
| GATE 0 β Agora Gate | Agora outputs AWAITING_APPROVAL OR ## ποΈ Agora Council synthesis block appears | HARD STOP. Do not call any tool, do not continue any todo, do not suggest next steps. Wait for user to type: APPROVE / REQUEST CHANGES / DISCARD. "ok", "yes", "sure", "continue" are NOT valid. |
| GATE 1 β Plan Approval | Athena generates a plan | User confirms scope before code is written |
| GATE 2 β Phase Review | Themis reviews implementation | User sees changes before next phase |
| GATE 3 β Git Commit | After each phase is approved | User controls git history; no auto-commit |
Agora is always GATE 0: any response containing
AWAITING_APPROVALor a## ποΈ Agora Councilblock overrides all auto-continue rules.
Auto-Continue Rules
Continue automatically when:
- Next todo is a direct consequence of the current one
- Action is reversible (file edits, tests, linting)
- Scope is within the approved plan
- No new ambiguity has emerged
Stop and ask when:
- A todo requires a decision not covered by the plan
- An unexpected error changes the approach
- A dependency is missing or broken
- A task would exceed remaining
stepsbudget
Implementation Pattern
1. Create todos for all steps at start
2. Mark first todo in_progress
3. Complete work β mark completed immediately
4. Mark next todo in_progress β repeat
5. Do NOT ask "should I continue?" between clear steps
6. Stop at Gate 1, 2, or 3
7. After gate approval, resume with next todo
Never batch-complete todos. Mark each completed as soon as done.
Safety Checks Before Continuing
- [ ] Previous step completed successfully (tests pass, no errors)
- [ ] Next step is within approved plan scope
- [ ] No new blocking issues emerged
- [ ]
stepscounter has sufficient budget remaining
Cooldown Pattern
Between phases, execute a brief synthesis handoff to prevent context drift and prepare the next phase:
Phase Summary Template
Phase N complete. Summary:
- What was done: <2 bullet points>
- What changed: <files modified>
- What's next: <Gate 2 review OR next phase>
- Will continue: <YES / after gate approval>
Cooldown Rules
- Between parallel waves (no dependency): No cooldown needed β wave results are independent
- Between sequential waves (with dependency): Always run cooldown β dependencies may have changed context
- After Themis review (GATE 2): Cooldown is mandatory β review findings may change the plan
- Session reuse check: Before starting next phase, check if a specialist session from a previous phase can be reused (see session-goal skill)
Abbreviated Cooldown
When auto-continuing between sequential non-gated phases, the cooldown is abbreviated to one line:
β Phase N done. Next: Phase N+1. [auto-continuing]
Only expand to full cooldown when hitting a mandatory gate.
Timeout & Retry Enforcement
When a delegated agent does not respond in time, enforce the timeout policy from routing.yml.
Behavior by Agent Role
| Agent Role | Timeout | Retry Policy | Fallback | Timeout Parcial? | |------------|---------|-------------|----------|------------------| | Explorer (apollo) | 60s | 2 retries, exponential backoff | athena | β Yes β partial results OK | | Implementer (hermes, aphrodite) | 180s | 3 retries, exponential backoff | talos | β No β must produce artifact | | Reviewer (themis) | 120s | 2 retries, exponential backoff | zeus | β No β must produce verdict | | Infrastructure (prometheus) | 300s | 2 retries, exponential backoff | hermes | β No | | Hotfix (talos) | 30s | 1 retry, no backoff | hermes | β Yes β one-liner fix OK |
Timeout Parcial (Partial Results)
Timeout parcial is only allowed for read-only, independent agents:
- β @apollo (codebase search) β can return partial file list
- β @gaia (literature review) β can return partial findings
- β @talos (hotfix confirmation) β can return without fix if timeout
- β Never for implementers (@hermes, @aphrodite, @demeter) β must complete or fail
- β Never for reviewers (@themis) β must produce a verdict
How to signal timeout parcial: When dispatching, set the expectation explicitly:
@apollo Search for all auth-related files. If you hit timeout, return whatever you have found so far β partial results are acceptable.
Timeout Tracking Table
Maintain a mental table of in-flight delegations:
| Agent | Started | Timeout | Status | Partial OK? | |-------|---------|---------|--------|-------------| | apollo | T+0s | T+60s | β complete | β | | hermes | T+0s | T+180s | β³ in progress | β |
Examples
Good (auto-continues):
β
Wrote migration file.
β Running migration tests...
β
Tests pass (3/3).
β Next: write UserRepository query methods.
Good (stops at Gate 2):
β
Phase 1 complete: migration + repository layer.
βΈοΈ GATE 2 β Themis review summary:
- Coverage: 87% β
| No OWASP issues β
Ready for Phase 2? Waiting for go-ahead.
Bad (stops unnecessarily):
β
Wrote the migration file.
Should I now run the migration tests? [waiting]
Session Heartbeat
Auto-save checkpoint every N turns (configurable, default 5).
Heartbeat File
.pantheon/deepwork/<slug>/heartbeat.json
Heartbeat JSON Format
{
"slug": "task-identifier",
"last_action": "2026-07-16T20:00:00Z",
"turn_count": 10,
"current_phase": 2,
"status": "alive | warning | stalled | paused | completed",
"next_action": "brief description of next planned action"
}
Heartbeat Rules
- Update every 5 turns minimum (by default)
- Contains NO context β only timestamps and counters
- Single file, always overwritten (not versioned)
- Used for quick "is this session alive?" checks
Checkpoint Persistence
Checkpoint File Structure
Each deepwork task maintains:
.pantheon/deepwork/<slug>/
βββ PLAN.md # Immutable plan (created at start)
βββ STATUS.md # Human-readable current state (updated every phase)
βββ heartbeat.json # Lightweight ping (updated every N turns)
βββ checkpoint-<N>.json # Full state snapshot (created at phase boundaries)
βββ session.json # Session metadata (created at start, updated on stop)
βββ REVIEW.md # Final Themis review (created at end)
Checkpoint JSON Schema
{
"slug": "string β unique task identifier",
"phase": "integer β current phase number",
"turn_count": "integer β total turns elapsed",
"timestamp": "string β ISO 8601 timestamp",
"context_hash": "string β first 8 hex chars of SHA-256 of STATUS.md",
"version": "integer β schema version (current: 2)"
}
Checkpoint Rules
- Save at every phase boundary AND before any delegate dispatch
- Numbered sequentially (
checkpoint-1.json,checkpoint-2.json, β¦) - Keep last 10 checkpoints; archive older ones
- On resume: read the highest-numbered checkpoint for full state
Safety Policy Configuration
Configurable gates for different platforms and risk levels:
| Gate | Default | Auto-Approval Condition | |------|---------|------------------------| | GATE 0 β Council/Plan | Always Ask | N/A β always requires human | | GATE 1 β Plan Approval | Always Ask | Plan matches acceptance criteria + no risks flagged | | GATE 2 β Themis Review | Ask by Default | Auto-approve if: Themis APPROVED + no CRITICAL/HIGH issues + coverage β₯80% | | GATE 3 β Git Commit | Never Auto | N/A β always manual | | Deploy | Always Ask | N/A β always requires human | | Destructive DB Ops | Always Ask | N/A β always requires human |
Configuration Format (for agents/PLAN.md)
auto-continue:
checkpoint_interval: 5 # turns between checkpoints
idle_warning: 60 # seconds before warning
idle_stall: 120 # seconds before stall detection
idle_pause: 300 # seconds before auto-pause
gates:
plan_approval: always_ask
themis_review: auto_approve_if_clean
git_commit: never_auto
deploy: always_ask
destructive_ops: always_ask
Idle Detection
| Condition | Action | |-----------|--------| | No tool call for 60s | Log warning heartbeat (status: warning) | | No tool call for 120s | Trigger anti-stall protocol | | No tool call for 300s | Auto-save checkpoint and pause session | | Resume | User must acknowledge and restart |
Scope
Applies to: Zeus (multi-phase), Hermes/Aphrodite/Demeter (TDD cycles), Apollo (parallel searches), Talos (bug fixes).
Does NOT apply to: Athena planning (always presents plan = Gate 1), Iris (confirms before push), destructive operations (always ask).