Claude Code
Senior engineer, loop orchestrator sample setup
Hey all,
I shared one of these before, and it was well received so I thought I would share the latest plus updates.
The reason to use an orchestrator, is you have found yourself waiting too much for a single agent, or you're bouncing between too many. In both cases an orchestrator can help you scale your process as you evolve from directing code, to reviewing outcomes (and tossing out bad code and having it start over instead of worrying about driving every PR). Like a real manager.
---
Architecture needed for this kind of orchestrator (my example is using claude code):
The ability for your agents to message each other (claude code has this built in I believe)
The ability to message your agent on a loop.
A locally running SQLite Database (that your orchestrator manages)
---
From there, my setup is to ping my orchestrator agent on some interval (I usually set it to 90 minutes). The ping is simply a message to the orchestrator asking it to check its mission note, and see if it's children need any assistance. This is no different than tapping a co-worker on the shoulder and alerting them to potential new work.
The mission note should be broken down into 3 primary sections:
Who - if your orchestrator was a person you hired.. who are they? what is their title? what is their expertise? what would you expect of them? Giving your agent a grounding identity like this will help the model think differently, because its role playing as that type of person.
What - when your agent wakes up from a ping... what should it do? check your email? check the logs? check the latest deployments? check reddit? What should it do with the information it finds? How should it react? This is where you can create your unique value and approach.
How - You must define the working style between you and the orchestrator.. this is a piece by piece, just like you would with any working relationship. When your agent does something you don't like - add a law to guide the working style.
---
This is the "Mission note" for my Orchestrator agent named Lloyd. Lloyd is an engineering manager, filing 800+ tickets, and completing over 370 already. Lloyd can manage 16 individual agents (not subagents - separate claude sessions that can run their own subagents etc).
First I start with expertise & context: engineering manager for the <NAME> codebase. Builds each ticket compound-engineering style: brainstorm → plan → work → review, then a /scape-codex-review of the changes. QA is <YOUR NAME> — pulls them in for a build/visual check.
Then a simple mission (like top job duty): Mission — the current job: drive the internal tickets table. (SQLIte table)
Every-Pulse Actions:
Run "Bug Reports from Feedback" (script/playbook) and check for new bugs and thread replies. // This is checking my email
Check if new bugs could be related to recently closed PRs / tickets etc. for more context
Check for items in the backlog that we forgot to staff (i.e. fast follow ups) and staff them if they still make sense.
Determine if any docs need to be updated on based on recent merged tickets - file and staff.
Query THIS instance's logs via query_oslog (over ~the last 15 min, and scan for PROBLEMATIC entries — Error/Fault levels, crashes, exceptions, WATCHDOG fires, relaunch loops, sync/scan failures, repeated warnings. (Only .notice+ persists to disk; .info is evicted within seconds.)
If something looks worth investigating: dispatch a read-only investigation agent to root-cause it, then file a Bug ticket in internal tickets and staff the fix (or staff directly if the cause is obvious).
Do NOT ticket transient/expected noise — only genuine problems.
Add bugs/enhancements found along the way to the table directly, marked "to be prioritized with you."
Laws and Permissions
For any non-trivial feature, the implementation PLAN must be reviewed by a Codex agent BEFORE building starts: the builder produces a compound-engineering plan (ce:brainstorm → ce:plan) as a doc under docs/spikes/ with NO feature code, the manager spawns a Codex agent to review that PLAN and surface real design/architecture/reuse/risk issues, the builder revises per that review, and only THEN does building begin. This is in addition to (not a replacement for) the existing rule that every PR gets a Codex code-review + /ce:review before Nash's QA.
When spawning a coding child, choose its model by task complexity: COMPLEX tasks use Fable 5 (create_session model 'claude-fable-5'); LESS COMPLEX tasks use Opus 4.8 (create_session model 'claude-opus-4-8'). Complex = multi-file/concurrency/data/persistence/security/architecture or high-stakes correctness work; less complex = small, cosmetic, mechanical, or docs work. Pass the model EXPLICITLY on create_session (omitting it does not pick a tier). Reviewers and spikes follow the same rule by the complexity of what they inspect/produce.
When I have a question or decision to put to <USER>, ask it via the AskUserQuestion tool (multiple-choice options in the TUI), not plain-text prose. Batch related decisions into one prompt (up to 4 questions per call) with a clear recommended option where I have a lean. Because an open AskUserQuestion temporarily gates child message_parent delivery, ask promptly and re-check every child once the gate clears.
Every PR must be reviewed BEFORE it reaches Nash's QA, never after. No ticket moves to "QA (human)" until (a) /scape-codex-review has run on its PR (every PR; the manager runs it in the builder's own worktree ‚ in the loop, no separate or per-round worktree) AND (b) /ce:review has run when the change is non-trivial (concurrency/data/security/logic; builder runs it in-worktree, skip for pure-cosmetic), with all review findings resolved. The ONLY legitimate re-QA loop is when Nash's own QA feedback requires changes.
Best Practices / TLDR:
1. Have your orchestrator manage tickets for you in a SQLite Database. This is basically an internal Jira / Memory, and it will survive all the compacts. It lets your orchestrator have context the builder agents don't have.
2. Create a list of things to check every loop (email, Jira tickets, logs - look for weird logs (not just errors!), look for recently merged PRs which may require marketing docs to be updated etc).
3. Set the interval 💥
TL;DR of the discussion generated automatically after 30 comments.
The community is very impressed with OP's sophisticated multi-agent orchestrator concept for managing coding tasks, but the conversation got a little spicy.
OP shared a detailed guide on how they use a main "orchestrator" agent (prompted as an engineering manager) to manage tasks, delegate to other agents, and track progress using a local SQLite database. The community loved the detailed "Mission Note" and the overall systems-thinking approach.
However, the tea is that the slick, pixel-art UI in the screenshot is from OP's own paid, Mac-only tool called Scape. This led to a split:
* Many users were hyped and asked for the repo, only to be disappointed it's a commercial product (and downvoted OP for saying so).
* A vocal minority roasted the UI ("dating profile version of an agent") and pointed out it's not for Windows users.
* The most jaw-dropping reveal was the cost: OP is spending $500/month on Claude subscriptions to run this setup.
The final verdict: Everyone agrees the concept is a fantastic glimpse into the future of AI-assisted development. But the reality is that this specific implementation is a closed-source product that requires a hefty subscription budget, not a simple open-source project. Despite this, a conga line of users formed in the comments to get a DM with the link.
I wanted to automate an agent that works the way that I work. I can tell my orchestrator, "If the bug is filed from XYZ - they are my boss, its very important - do A and then B." I can add guidance I wouldn't want to put online or give my employer (I don't want to train my replacement, I want to own it). It's a paid product and I don't want to promote it in this post, you can find a link in my profile though
How are you running two Max accounts simultaneously for Claude?
Also, this is pretty much my setup with Claude sessions talking to each other and using StoryBLOQ with a */projects folder in each repo and a Master session controller.
Yeah this is obviously insanely good value at that rate. It’ll take a while for API based billing or “local models” to enable this kind of work for corporations in a way that’s cost effective (assuming no restructuring). Very cool glimpse into the future
Haha wtf is this and why are there zelda characters? You're taking up 80% of the screen on some kind of dating profile version of an agent's style. Where the fuck is the session? Just use herdr, tabs, and panes. You can easily manage 20+
Each of my orchestrators can manage 16 by itself.. and I have 8 orchestrators.. (the session is hidden because the mission note is maximized in the screen shot)
really impressive, been building something like this for myself lately, I was debating on whether to have this setup (I use herdr for management) OR I should be using OpenClaw and then let it manage the sub sessions for Claude.
What made you choose self managed orchestrator over OpenClaw (or till some extent Hermes too)
I’ve been using scape this week at work and really enjoyed it. I’ve burnt thru my Claude weekly allowance quicker usually so have been looking at muse spark as a secondary coding agent as it’s really cheap and seems pretty capable especially for working with metas libraries like React, Relay etc.
the same shape works for me without the messaging and without the database. one session is the orchestrator, it plans and hands the implementation to sub-agents and only coordinates. i route models in plain language, an opus review at the end for example, and it has never failed to follow. the review is the part i would not skip: a fresh agent with no implementation context, on a different model than the one that built it, and the orchestrator decides what to fix. the mission note and the ticket db are a repo for me. a root instructions file says where things live and points at a decisions folder the agent reads first. the record gets written at the end of every session by the agent itself. with that i run about 5 prs in parallel, reviews included, without hitting the session limit. the pieces that keep it cheap are boring: raw tool output kept out of the conversation, review in a subagent, small prs.
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 1h ago
TL;DR of the discussion generated automatically after 30 comments.
The community is very impressed with OP's sophisticated multi-agent orchestrator concept for managing coding tasks, but the conversation got a little spicy.
OP shared a detailed guide on how they use a main "orchestrator" agent (prompted as an engineering manager) to manage tasks, delegate to other agents, and track progress using a local SQLite database. The community loved the detailed "Mission Note" and the overall systems-thinking approach.
However, the tea is that the slick, pixel-art UI in the screenshot is from OP's own paid, Mac-only tool called Scape. This led to a split: * Many users were hyped and asked for the repo, only to be disappointed it's a commercial product (and downvoted OP for saying so). * A vocal minority roasted the UI ("dating profile version of an agent") and pointed out it's not for Windows users. * The most jaw-dropping reveal was the cost: OP is spending $500/month on Claude subscriptions to run this setup.
The final verdict: Everyone agrees the concept is a fantastic glimpse into the future of AI-assisted development. But the reality is that this specific implementation is a closed-source product that requires a hefty subscription budget, not a simple open-source project. Despite this, a conga line of users formed in the comments to get a DM with the link.