Control Flow

How agents manage execution beyond the basic loop: planning, permissions, subagents, and orchestration.

Plan Mode

All agents except Pi have explicit plan mode. The designs vary significantly:

Codex — In-Loop Status Tracker

• Tool: update_plan
• Model manages a step list with statuses: pending → in_progress → completed
• Exactly one in_progress at a time
• Steps are 5-7 words max
• Plan is displayed in the TUI but doesn’t change execution flow

Goose — Separate Planner/Executor Architecture

• A dedicated “planner” LLM call that outputs either:
  1. A detailed step-by-step plan (if enough info), OR
  2. Clarifying questions (if not)
• Plan is injected as a user message into a fresh conversation for the executor
• Executor has no prior context — only the plan
• One-shot: planner responds exactly once

Grok Build — Goal-Oriented with Verification

• enter_plan_mode / exit_plan_mode tools
• Separate prompts: goal_planner_prompt.md, goal_verifier_prompt.md, goal_summarizer_prompt.md
• Goals tracked by goal_tracker.rs with file persistence
• Goal verification as a separate LLM pass

OpenCode/Kilocode/Qwen Code — Mode Toggle

• enterPlanMode / exitPlanMode tools
• Plan mode = explore only, no mutations
• Exit triggers user approval before implementation begins

Cline — Plan/Act Mode Switch

• <user_input mode="plan"> vs <user_input mode="act"> tags
• Plan mode: read-only inspection, no file edits, no destructive commands
• switch_to_act_mode tool transitions to implementation
• User must explicitly approve before switching

Permission/Approval Systems

Codex — Static Modes

Three approval levels configured at session start:

• never: Full autonomy, no confirmations
• untrusted: Confirm destructive actions
• on-request: Confirm everything except reads

Goose — LLM-Based Permission Judge

• permission_judge.md prompt: LLM analyzes tool calls for read-only detection
• PermissionManager + PermissionInspector + PermissionConfirmation
• Tool annotations (read_only, destructive) enable fast-path classification
• Falls back to LLM judge for ambiguous cases

Grok Build — Router + Confirmation

• tool_confirmation_router.rs: Routes tools to appropriate confirmation flow
• Safety framework in system prompt (reversibility assessment)
• Per-tool categorization: Shell, (other categories)

OpenCode/Kilocode/Qwen Code — Classifier Prompts

• PermissionV2 system
• classifier-prompts/system-prompt.ts: LLM classifies tool calls
• Confirmation bus for async permission requests

Kimi Code — Service-Layer Permissions

• Full permission system in agent-core services
• Experimental flags can gate features

Subagents

Goose — Bounded Workers

• Max turns + timeout limits
• Cannot spawn children (no recursion)
• Separate system prompt emphasizing efficiency
• “Use tools sparingly and only when necessary”
• Limited tool access (subset of parent’s tools)

Grok Build — Resolved Subagents

• xai-grok-subagent-resolution crate handles agent selection
• Custom subagent prompt (shorter, focused)
• Hashline workflow instructions in subagent prompt
• AGENTS.md scoping rules apply to subagents too
• Memory search available to subagents

Kimi Code — Host + Batch

• subagent-host.ts: Manages subagent lifecycle
• subagent-batch.ts: Batch execution of multiple subagents
• Full session isolation per subagent

Qwen Code — Full Orchestration

• Arena: Multiple agents with different configs
• Team: Collaborative multi-agent with team-create/delete/plan-approval
• Agent tool: Spawn focused workers
• Workflow tool: Deterministic multi-agent orchestration scripts
• send-message: Inter-agent communication

Cline — Team Subagents

• subagent-prompts.ts in extensions/tools/team
• Team-based coordination

Workflow/Orchestration

Beyond simple subagents, some agents have structured orchestration:

Qwen Code — Workflow Scripts

• JavaScript-based workflow scripts with deterministic control flow
• agent(), parallel(), pipeline(), phase(), log() primitives
• Fan-out/fan-in patterns, adversarial verification
• Budget-aware (token target enforcement)
• Up to 1000 agents per workflow, 16 concurrent

Goose — Recipe System

• YAML-based reproducible workflows
• Scheduled execution via cron
• Session management for recipe runs
• manage_schedule tool for CRUD on scheduled recipes

Grok Build — Goal Tracking

• Goals persist across turns with verification
• Planner → Executor → Verifier → Summarizer pipeline
• File-based persistence of goal state and history

Hooks (Pre/Post Actions)

Some agents support hooks that run before or after certain events:

• Codex: Pre-compact hooks, post-compact hooks, stop hooks (can deny agent from stopping)
• Goose: UserPromptSubmit hooks, stop hooks with deny/allow decisions
• Qwen Code: promptHookRunner for pre-processing user input
• Kimi Code: Session hooks system with typed events