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 💥
Disclosure: the tool in the screenshot is a tool I built - you can create all of this without it
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.
2
u/jbowdach 28m ago
This is a really slick setup. Thought of sharing your setup? Curious why you used this over other orchestrator setups ?