Orchestrating Claude Code Agents: The Chief of Staff Pattern
octalpixel
24 points
23 comments
September 20, 2026
Related Discussions
Found 5 related stories in 87.5ms across 7,193 title embeddings via pgvector HNSW
- Maximizing the value of your Claude Code sessions twapi · 170 pts · August 14, 2026 · 59% similar
- How to organize Claude Code for product work adamfaik · 35 pts · August 11, 2026 · 57% similar
- Claude Code skills for advanced context engineering techniques and patterns leovs09 · 16 pts · September 04, 2026 · 55% similar
- Claude for Commerce Agents ashazal · 60 pts · September 03, 2026 · 55% similar
- Agent-Manager: A Tmux TUI for Running Claude Code, Codex and OpenCode yoanwaidev · 95 pts · July 30, 2026 · 54% similar
Discussion Highlights (6 comments)
simianwords
Bitter lesson means all these tricks will not be needed in a year or two. Either labs will abstract it in harness or models will become good enough that it can do it by itself
nvch
I’ll tell the missing part, what comes next: the team, with teammates and managers, starts making their product decisions. If the user was anywhere near the chat and wrote a mere “ok”, they will be recorded as “user's”. They will write tests. Lots of tests. Instead of removing any code, there will be 3 layers of backward compatibility, and tests that test presence of tests that test that backward compatibility. The reviews will find all possible edge cases, including those that can never happen, and make the UI gracefully handle them. With tests. The diff from any integration PR from team work will be over 10K lines, half of them bureaucracy. Zero chance to review even one – they will churn half-a-dozen per day. For anything outside of known shape, the original hard topics become quickly displaced with shortcuts and familiar patterns. Next, the app will break under load, and you will find that it’s caused by a quadratic sweep over the whole DB on any insert to prevent something irrelevant that you specifically told not to do. You will ask, “wtf? why is it there?”. “It’s load-bearing, you ruled it”. (That's not a joke. That's how I spent the summer.)
ffsm8
i mean its not wrong, basically everyone learns this within a few weeks of actively working with the agentic loop. but as usual with ai written content, the word bloat is roughly x5 of the words necessary to convey the message - with basically no effort on the meat proxy's part to clean it up in any way, shape of form
gritzko
This is close to my default workflow. One Fable to rule them all, many Opuses to implement. All work is planned, tracked and logged in plain Markdown tickets. No magic. Nothing to talk about. Still, I have to keep an eye on it or it devolves into a mess real fast. An example from yesterday: I noticed the commit added 10K lines where it clearly should not have. 5min of digging: it was a combinatorial state explosion in the parsers. All at once because a shared grammar was tweaked. Oopsies like this happen all the time, and with every passing hour it becomes harder to fix. Can only rely on that chief-of-stuff for mundane things.
albert_e
> What this is normally called Is this also what Microsoft calls "Magentic" pattern? (for a long time i kept reading it as Magnetic pattern) https://learn.microsoft.com/en-us/semantic-kernel/frameworks...
zhoujinliang
Coordinators and other agents are as unreliable as other agents. It has the same problems, empty assertions, undiscovered mismatches, and outdated memories. I tend to work with multiple agents in parallel. Based on the same agreement, everyone chooses a more suitable agent to do the final finishing when they need to make decisions.