While building my stock app, I wrote my own agent orchestration system. I split the roles seven ways — Planner / Worker / Tester / Refactor / Manager / Screen Tester / Reviewer — gave each role a feed file (feeds/<role>.feed.md) with a cursor and a dispatch counter, and ran pub/sub through Python scripts like feed-append.py and feed-read.py. I even built a chain where a PostToolUse hook would automatically spin up the Tester whenever a Worker finished. What I wanted was simple: everything except business judgment — implementation, testing, review — running on its own without a human in the loop.
It didn’t run well. The pub/sub kept dropping messages, so I consolidated everything into a central index — and then that started colliding. I had the task status in a single 46KB README, and with multiple agents touching it at once, I ended up having to add a rule banning edits to that file from worktrees. If I open the chat from that period, I’m asking: “pub/sub doesn’t seem to circulate right. The single-index approach collides way too much… any better ideas?”
That’s where things stood when Opus 4.8 came out on May 28. Skimming the release news I asked, “I saw something about running a bunch of parallel multi-sessions,” and the answer was Dynamic Workflows. Claude plans the work, spins up subagents — 16 concurrent, up to 1,000 per run — and verifies the results itself. Loops, branches, and intermediate results live in a script, and only the final answer lands in Claude’s context. That was exactly what I’d been trying to build with feed files and cursors. It already existed, and it was built better.
Turning it on was almost anticlimactic. I typed /effort ultracode, got the error “Ultracode needs dynamic workflows enabled (see /config) and an xhigh-capable model,” toggled workflows on in /config, typed it again — done. The thing I’d been assembling out of Python scripts and hooks was one settings toggle. The only reaction I left in the chat that day: “it worked lol.”
What I used my first ultracode run for is a bit funny: designing how to fix the orchestration system I’d built by hand. Ten agents read through my pub/sub documents in parallel and pitted four design proposals with different philosophies against each other. I had the built-in orchestration draft the improvement plan for my handmade orchestration.
And this wasn’t even the first time. For a long while I didn’t use skills at all — I managed every agent rule as conventions in CLAUDE.md. When I asked, “I’ve handled everything with conventions so far, but things slip through sometimes,” the underlying principle came out. CLAUDE.md gets re-read with every message, but as the conversation grows, the rules dilute across the whole context into a “present but ignored” state. So heavy procedures go into skills (injected right next to the task the moment they trigger, so compliance goes up), and rules that must never slip go into hooks (exit code 2 — no model judgment involved at all). I didn’t need to invent that distinction. It was already designed into the tool; I just didn’t know.
Only after putting the two incidents side by side did the pattern show. The things we called prompt engineering and context management are moving into the tools. When to inject a rule — skills took that. Deterministic enforcement — hooks. Multi-agent orchestration — workflows. Reasoning budget — the effort slider. What required hand-engineering half a year ago is a settings value now.
And when a new capability lands, everything around it gets rearranged too. Once skills existed, CLAUDE.md’s role shrank from “the place for every rule” to “only what’s worth carrying in every message.” Commands and skills, once separate, merged into the same slash interface — the real distinction now isn’t file location but “does a human invoke it or does the agent.” It’s not one feature being added; it’s the whole arrangement being redrawn.
Which means memorizing syntax is pointless — it’ll change again next version. What lasts is a feel for how LLMs behave. Long context dilutes earlier instructions. Instructions injected at the moment of need are followed best. The layer that relies on model judgment and the layer that enforces deterministically are different layers. Intermediate outputs piling up in context degrade quality. With that feel, reading release notes you immediately see “this replaces that part of my setup.” Without it, new features are just passing news, and you keep turning your own wheel.
Something in the next release will replace another part of my setup. I don’t know what it’ll be — but this time, I think I’ll at least recognize it in the release notes.