I wanted to give a little peek into what one of my loop orchestrators actually looks like, so people could see a real working example instead of a diagram. I've been an engineer and designer for 20+ years, and this is roughly how I run agents now.
An orchestrator is an agent whose job is to run other agents on a loop. You hand it an objective and a heartbeat. It wakes up on that heartbeat, does a round of work, files what it found, and goes back to sleep until the next one. Mine is named Lloyd, and it manages some of the engineering work on Scape.
Give it a database to manage its own memory
Lloyd's primary goal is managing its own internal tickets table. In my case that's just a simple SQLite table. An orchestrator can do anything, so giving it a database to manage its own memory has compounding value. Lloyd has managed over 600 tickets for me that it can query — like its own internal Jira, that I can click through.
This means every time I have a new ticket, it can look up previous related tickets. Just like any of us should when we get assigned new work. It gives the agent a database of tribal knowledge that can be passed to any model.
The heartbeat and the pulse
The main concept I want to point out is the heartbeat, and the pulse action items. This is where you can see exactly where the value comes from. Lloyd wakes up on a heartbeat I set — a bit over two hours in my case — and I cap how many child agents it's allowed to run at once.
Each time it wakes, it works through the same short list of standing checks I gave it. That's the pulse.
Already using Scape? You can clone this sample mission note and start from it.
Here's what mine checks on every pulse:
- First it runs a playbook — an automation script — to check my email for any new bug reports from customers, and checks for previous context before staffing a ticket.
- It checks if any docs need to be updated on the website.
- It checks the app's own running logs to just see what's up. This is such an important practice. It will surface bugs you didn't know existed because nobody reported them and the logs didn't produce an error — maybe a noisy problem that never crashed anything.
- It adds its own tickets for bugs and enhancements along the way, which gives the agent a voice to surface ideas and problems for me to triage.
That last one is the part I like most. The agent has the agency to create its own work, and it puts it on the table for me to triage.
It works because it's simple
A table it owns, a heartbeat, and a short list of things it checks every time it wakes up. That's the whole shape, and it works because it's simple — every pulse it puts the priorities back in front of the model, the same way you'd keep them in front of a person you manage.
Scape gives every project its own SQLite tables, synced to your iCloud. The playbooks are the automations Lloyd runs, and the fleet of child agents is Lloyd staffing the work across isolated worktrees, each one running an adversarial review on its work before it reaches me. Scape calls the orchestrator an Argus, after the hundred-eyed watcher, because keeping a pulse on the whole fleet is the entire job.
