Autonomous Project Management with Subagents

Pain Point

Traditional orchestrator patterns create bottlenecks — the main agent becomes a traffic cop. For complex projects (multi-repo refactors, research sprints, content pipelines), you need agents that can work in parallel without constant supervision.

• Context window overflow: A single agent juggling multiple project tracks fills its context fast.
• Sequential bottleneck: One agent can only do one thing at a time — tasks that could run in parallel get serialized.
• No persistent state: When the agent's context resets, project progress is lost unless manually tracked.

What You Can Do

• Decentralized coordination: Agents read/write to a shared STATE.yaml file — no central orchestrator needed.
• Parallel execution: Multiple subagents work on independent tasks simultaneously.
• No orchestrator overhead: Main session stays thin (CEO pattern — strategy only, 0-2 tool calls).
• Self-documenting: All task state persists in version-controlled files.
• Git as audit log: Commit STATE.yaml changes for full project history.

Core Pattern: STATE.yaml

Each project maintains a STATE.yaml file that serves as the single source of truth:

# STATE.yaml - Project coordination file
project: website-redesign
updated: 2026-02-10T14:30:00Z

tasks:
  - id: homepage-hero
    status: in_progress
    owner: pm-frontend
    started: 2026-02-10T12:00:00Z
    notes: "Working on responsive layout"

  - id: api-auth
    status: done
    owner: pm-backend
    completed: 2026-02-10T14:00:00Z
    output: "src/api/auth.ts"

  - id: content-migration
    status: blocked
    owner: pm-content
    blocked_by: api-auth
    notes: "Waiting for new endpoint schema"

next_actions:
  - "pm-content: Resume migration now that api-auth is done"
  - "pm-frontend: Review hero with design team"

Skills You Need

• sessions_spawn / sessions_send for subagent management
• File system access for STATE.yaml
• Git for state versioning (optional but recommended)

How to Set It Up

1. How It Works

1. Main agent receives task → spawns subagent with specific scope
2. Subagent reads STATE.yaml → finds its assigned tasks
3. Subagent works autonomously → updates STATE.yaml on progress
4. Other agents poll STATE.yaml → pick up unblocked work
5. Main agent checks in periodically → reviews state, adjusts priorities

2. Example: Spawning a PM

User: "Refactor the auth module and update the docs"

Main agent:
1. Checks registry → no active pm-auth
2. Spawns: sessions_spawn(
     label="pm-auth-refactor",
     task="Refactor auth module, update docs. Track in STATE.yaml"
   )
3. Responds: "Spawned pm-auth-refactor. I'll report back when done."

PM subagent:
1. Creates STATE.yaml with task breakdown
2. Works through tasks, updating status
3. Commits changes
4. Reports completion to main

3. Label Conventions

Use pm-{project}-{scope} for easy tracking:

• pm-auth-refactor — Auth module refactoring PM
• pm-docs-migration — Documentation migration PM
• pm-frontend-redesign — Frontend redesign PM

Key Insights

• STATE.yaml > orchestrator: File-based coordination scales better than message-passing.
• Git as audit log: Commit STATE.yaml changes for full history.
• Label conventions matter: Use pm-{project}-{scope} for easy tracking.
• Thin main session: The less the main agent does, the faster it responds.
• PMs can spawn sub-subagents: For truly complex projects, allow recursive delegation.

Inspired By

This pattern is inspired by Nicholas Carlini's approach to autonomous coding agents — let agents self-organize rather than micromanaging them.

Related Links

• OpenClaw Subagent Docs
• Anthropic: Building Effective Agents

Deploy with ShipClaw

Skip the setup — get a fully managed OpenClaw instance ready to run this use case.

Quick Start

1. Pick a plan — Pro recommended for this use case
2. Go to your Instances Dashboard and click Deploy New Instance
3. Once deployed, use the sample prompt above to configure your agent
4. Customize thresholds, schedules, and sources to fit your workflow