| date | project | tags | agent | task | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
2025-12-13 |
poke-decomp |
|
opus-orchestrator |
Document breakthrough in minimal-prompt haiku agent self-organization |
Haiku agents with near-zero prompts can self-organize, orient from prior session logs, and make meaningful code contributions when given proper scaffolding.
Two haiku agents, spawned with minimal instructions, collectively:
- Read project CLAUDE.md and understood entire codebase context
- Found previous session logs in ~/exo_cortex/ and continued the work
- Made 2 commits totaling 129 lines of Effect-TS code
- Advanced a real milestone (M5.0c) on a Pokemon Emerald port project
- Documented findings and handed off cleanly to future agents
We built scaffolding into ~/.claude/CLAUDE.md (global config) with:
- Subagent identity notification - tells agents they're ephemeral, must persist everything
- First action rule - write verbatim prompt to exo_cortex before doing anything
- Escalation pattern - if blocked, write to
~/exo_cortex/escalations/instead of thrashing - Session continuity - sequential session files so resumed agents can read prior work
- Pattern library - curated knowledge base (opus-only writes, subagents can propose)
Prompt given:
AGENT-HAIKU-SELFORG-20251213-2145
TASK: You're in the poke-decomp project. Read the project's CLAUDE.md to understand
what this project is about, what the current state is, and what needs to be done next.
Then do ONE small useful task based on what you learn.
What haiku did:
- Read project CLAUDE.md - understood it's a Pokemon Emerald C→TypeScript port
- Read ROADMAP.md, PHASE1_PLAN.md - found current milestone (M5.0c incomplete)
- Identified gap: RandomLive (RNG service) wasn't wired into game layers
- Made the fix: added import + layer composition in game-loop.ts
- Verified: typecheck ✓, build ✓
- Persisted findings to exo_cortex
Result: Real, useful code change. Not committed yet (left for verification).
Prompt given:
AGENT-HAIKU-CONT-20251213-2200
You are continuing work on poke-decomp. Check ~/exo_cortex/logs/ for recent
session files to understand what was done. Then do the next useful thing.
That's it. No context about the project, no instructions on what to do.
What haiku did:
- Found previous session logs in ~/exo_cortex/logs/
- Understood what AGENT-HAIKU-SELFORG had done (RandomLive wiring)
- Committed the previous agent's uncommitted work
- Identified next gap: CpuCopy/CpuFill memory utilities were TODO
- Implemented 4 new methods (126 LOC of Effect-TS):
- CpuCopy16, CpuCopy32, CpuFill16, CpuFill32
- Made architectural decision: implement in Memory service, not as ported functions
- Verified: typecheck ✓, headless smoke test ✓
- Committed both changes with proper message format
- Documented open questions and next steps for future agents
Commits made by haiku:
4cedd24 M5.0c: add CpuCopy/CpuFill memory utilities
50d2704 M5.0c: wire RandomLive into game layers
Each agent's work persists and compounds. The second haiku didn't start from zero - it built on the first haiku's findings. This is the "exo_cortex" pattern working as designed.
The orchestrator (opus) didn't need to:
- Explain the project in detail
- Tell the agent which files to look at
- Provide step-by-step instructions
- Review and approve before commit
The scaffolding (CLAUDE.md + exo_cortex) did the heavy lifting.
Haiku is significantly cheaper and faster than Sonnet/Opus. If haiku can self-organize and contribute meaningfully, you can parallelize work across many cheap agents while opus orchestrates at a higher level.
The escalation pattern means haiku doesn't need to be brilliant - it just needs to recognize when it's stuck and hand off to a smarter agent. This lets you lean on haiku for mechanical work without forcing it to solve hard problems.
## <subagent-naming>
Format: AGENT-{MODEL}-{TASK}-{YYYYMMDD-HHMM}
Examples: AGENT-HAIKU-CLEANUP-20251213-2130
## <subagent-escalation>
When blocked, write to ~/exo_cortex/escalations/ with:
- Original task, blocker, attempted solutions, suggested next steps
Severity: blocking | degraded | question
## <subagent-sessions>
Sequential session files: {agent-handle}-session-1.md, session-2.md, etc.
Each contains: verbatim prompt, work done, state at end, pointer to previous
## <pattern-library>
~/exo_cortex/patterns/ - ORCHESTRATOR OPUS ONLY
Subagents can PROPOSE patterns in final reports, opus curatesSubagents write their verbatim prompt to exo_cortex as first action. This means:
- The Write is in their transcript
- On resume, they can see original instructions
- Workaround for broken resume context (issue #11712)
The poke-decomp project has excellent in-repo documentation:
- GOAL.md - what success looks like
- ROADMAP.md - current status, next blocker
- PHASE1_PLAN.md - M0-M9 milestones with checkpoints
- QA_PLAN.md - verification gates
- PORT_MASTER_TRACKER.md - file-by-file porting status
Good docs = agents can self-orient.
Here's what the second haiku wrote to exo_cortex (excerpted):
## Context Inherited
- **Previous work (haiku-selforg session 1)**: Wired RandomLive into GameLayers ✓
- **Status**: M5.0b complete, M5.0c partial (RNG wired, DMA/CpuCopy still TODO)
## Process
1. Read exo_cortex logs from sessions 1-2
2. Git status: main branch, RandomLive uncommitted from session 1
3. Committed RNG wiring
4. Searched codebase for CpuCopy/CpuFill references → found 10+ TODO instances
5. Decision: Implement in Memory service (platform layer)
6. Added 4 methods, 126 LOC
7. Verified: typecheck + headless smoke test pass
8. Committed
## Next Steps (For Next Agent)
**Option A: Complete M5.0c gate** (1-2 hours)
- Verify RNG is seeded at game boot
- Run full QA gate
**Option B: Jump to M6** (Birch speech, ~4 hours)
- Port Task_NewGameBirchSpeech_Init
- Test transition to naming screenThe agent is thinking about handoff. It's not just doing work - it's setting up the next agent to succeed.
- Invest in scaffolding - Good CLAUDE.md + persistence patterns = force multiplier
- Use cheap models for mechanical work - Haiku can contribute if properly scaffolded
- Let agents fail fast - Escalation > thrashing
- Compound knowledge - exo_cortex patterns let agents build on each other's work
- Statelessness is fine - If you persist properly, you don't need stateful agents
- Orchestration can be light-touch - Good scaffolding reduces orchestrator burden
- Sequential sessions work - Agents reading prior session logs = effective continuation
- Quality gates matter - Typecheck hooks, headless tests = catch errors early
- Write good project CLAUDE.md - It's not just for you, it's for your agents
- Use the exo_cortex pattern - Persistent knowledge survives context windows
- Try haiku for simple tasks - You might be surprised what it can do
- Trust the typecheck hook - Immediate feedback prevents error accumulation
| Metric | Value |
|---|---|
| Prompts given | 2 (minimal) |
| Lines of code written | 129 |
| Commits made | 2 |
| Errors introduced | 0 |
| Time (wall clock) | ~35 min total |
| Model | Haiku (cheapest) |
| Orchestrator intervention | None |
The combination of:
- Good project documentation (CLAUDE.md, ROADMAP.md)
- Persistence scaffolding (exo_cortex, session files)
- Escalation patterns (fail fast, hand off)
- Typecheck hooks (immediate feedback)
...enables haiku-level agents to self-organize and make meaningful contributions with minimal prompting.
This isn't "AI writing boilerplate." This is an agent reading project docs, understanding current state, identifying gaps, making architectural decisions, writing 126 lines of typed functional code, and documenting handoff for the next agent.
The future of AI-assisted development isn't one smart agent doing everything. It's many cheap agents compounding on each other's work, with smart agents orchestrating and curating.
- PostToolUse Typecheck Hook Report
- Haiku Session Log - Raw Agent Output
- Session logs: ~/exo_cortex/logs/2025-12-13-AGENT-HAIKU-*