Background execution was fast and consistent. But I had no idea what actually happened until I checked the logs. I needed systematic logging, timing data, automated commits, PR creation—the full testing workflow. Claude wrote me a shell script. That script became the foundation for testing at scale.
Claude Code
Running Claude in Background
Parallel execution helped, but testing still had problems. The CLI would flicker during long runs. Conversations would compact mid-execution. The context would get huge. I needed a different execution model. Then I discovered Claude could run in the background. No interactive output. No context display. Just: start it, let it run, check results later.
Running Agents in Parallel
I was researching agent execution to understand the timing inconsistencies. Reading documentation. Testing scenarios. Then I found it in the docs: agents can be invoked in parallel. Multiple workers, same message, executing simultaneously. I had been running everything sequentially. No wonder it was slow.
Testing Bottlenecks
The patterns worked. I built workflows 2, 3, and 4 in days instead of weeks. Then I started testing them on real codebases. The workflows took forever. Sometimes 15 minutes. Sometimes 25 minutes. Same workflow, same repo, different times each run. I couldn’t figure out what was actually happening or whether they were working correctly.
Building a Second Workflow
The first workflow took three weeks. Discovery, refactoring, flattening hierarchies, reducing cognitive load. Learning patterns the hard way. Then I needed a second workflow. I pointed Claude to the first one and said “build one like this.” One day later, done.
Reducing Coordinator Cognitive Load
After a week writing documentation, I looked at the workflow with fresh eyes. Workers invoked skills and dumped raw output. Every loop iteration, the coordinator parsed, categorized, grouped, and sorted that output. I was making the coordinator do too much. Time to move the work where it belonged.
Creating Standards Files
Workers needed context to understand their tasks, but adding it directly made the instructions impossibly complicated. Steps mixed with explanations mixed with examples. I stared at the mess and saw the same pattern I’d seen in code a hundred times before. Time to apply the principles.
Defining Success Criteria
My workers were using skills 25% to 50% of the time. The other half, they’d bail and try something else. I thought clearer instructions would fix it. They didn’t. The problem wasn’t understanding the instruction, it was understanding what I considered success.
Teaching Thinking, Not Steps
Five rounds of reorganizing documentation. Each version better than the last. But something still felt wrong. Saturday night, staring at perfectly organized docs, I finally asked the right question. Not “how do I document these components?” The real question: “how do I teach someone to think about them?” Everything changed.
Agent Jobs
Over the long weekend, I’d rebuilt everything. The three-tier architecture was gone, replaced by a flat coordinator and workers. During that rebuild, I’d faced a question: how many responsibilities should one worker have? I saw potential for dozens of nearly-identical workers, each with massive duplicated context. But allowing multiple jobs per worker seemed to violate Single Responsibility Principle. I came up with a solution. Today I’m sharing it.