Discussion about this post

User's avatar
JP's avatar

The Myanmar analogy genuinely made me laugh. That constant context-switching between agents waiting for input is exactly how it feels. You're never really thinking deeply about any one thing.

Your peak scaffolding take is something I've been coming around to as well. Codex actually has a built-in multi-agent mode now. One line in the config file, no GasTown, no beads, no custom orchestration. It just decides on its own when to spin up sub-agents based on task complexity. I wrote about it here https://reading.sh/codex-has-a-multi-agent-mode-and-almost-nobody-is-using-it-088e44f774ef and the Boris-style simplicity of it is what drew me in.

The context isolation is the real win though. Each sub-agent runs in a fresh window so you don't get that degradation you mentioned where the model starts forgetting earlier instructions. The main thread only ever sees summaries, not the intermediate mess.

Pawel Jozefiak's avatar

The Myanmar management analogy is surprisingly apt. The core insight that multi-agent systems reduce to context management, tools, and testable outputs matches what I found running 4 Opus 4.6 agents simultaneously. The scaffolding complexity melts away once you realize agents just need clear context boundaries and a way to communicate results. What I noticed in practice is that the testable output piece is the most critical. When each agent produces something verifiable, the orchestration layer stays simple. Without it, you end up micromanaging agents the same way you described managing teams in Myanmar. I wrote up the full parallel agent experiment: https://thoughts.jock.pl/p/opus-4-6-agent-experiment-2026

No posts

Ready for more?