Hey everyone,

Wanted to give a little peak into what one of my loop orchestors looks like as a 20+ year senior engineer & designer, so people could see a real working example.

My orchestrator Lloyd's primary goal is managing it's own internal tickets table. In my example thats 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 it's 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 assigned new work.

It gives the agent a database of tribal knowledge that can be passed to any model.

https://preview.redd.it/0nyyd00bl7jh1.png?width=1940&format=png&auto=webp&s=f383811da3c23f3bc0645672291bcfa05e6de1ac

The main concept I want to point out is the heart beat, and the pulse action items.

You can see exactly where the value comes:

- first it runs a playbook (automation script) to check my email for any new bug reports from customers, checks for previous context before staffing a ticket
- checks if any docs need to be updated on the website
- check's the own app's running logs to just see whats 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 and error, but maybe a noisy problem.
- adding it's own tickets for bugs and enhancements along the way, gives the agent a voice to surface ideas and problems for _me_ to triage as well.

What do your loops look like?

Once you start handing real work to an agent, you stop being the person who writes the code and become the person who's answerable for it. That's a good trade, but it changes your job. When something breaks in production nobody's going to ask how the code got written. They're going to look at you.

Left alone, an agent produces slop. Not because it's stupid ‚because that's what anything does when nobody checks its work. A junior does the same. So might you on a bad day.

There are roughly two ways to run an agent. You can sit on top of it and drive every step, which is quicker than typing the code yourself but leaves you babysitting: every time it pauses and resumes you have to load the whole problem context back into your head, and if you look away and get distracted, that ends up slower than just doing the work.

The other way is to treat it like someone who reports to you. You say what you want and roughly how, and you come back when there's something worth looking at. This is how senior engineers use agentic tools. You don't need to watch every keystroke to be accountable for the result‚ no manager does‚ but the review lands on you, and if you skip it, slop is what goes out the door.

So point a second model at it and tell it to find the problems

That's all an adversarial review is. One model writes the code. A different one‚ or at least one that hasn't touched any of the context‚ reads the diff and goes looking for what's wrong. It doesn't get to touch your code; it can only raise findings. The author model decides what to act on. Then it reads the result again. Most of the time it finds something.

You get better code out of it, but that's not really why you do it. You do it so you can trust work you didn't watch get written. The agent already handed you the time‚ another round, more tests, a second set of eyes that costs nothing but tokens. This is what you spend it on.

The data

Looking at my last 83 completed tickets that got a Codex review, at least 67 ended in a real change to the code‚ something the first pass got wrong or left exposed, caught before it went out. That's four out of five reviews turning up something worth fixing.

Sorted by what kind of problem they were, across all 122 commits these reviews drove:

What got caught	Share of commits
Correctness / logic	34%
Concurrency / races	22%
Durability / data	19%
Security / injection	9%
Test integrity	9%
Other (docs, dead code)	7%

Half of every commit these reviews drove‚ were the incident kind. Concurrency, durability, security. The stuff that corrupts data or leaks a secret, not the stuff that misaligns a button.

The claude skill

• Run them side by side. The author in one session, a reviewer in another‚ Codex, or a fresh Claude with none of your context‚ both pointed at the same working directory so the reviewer can see your diff. When the reviewer finds something, paste it into the author; when the author fixes it or pushes back, paste that over.
• Use a file as the mailbox. Have the reviewer write its findings to a file (or a PR comment) instead of chatting, then hand that file to the author to work through. No live channel needed ‚ the review is just a document that gets passed along.

The brief to the reviewer is the same:

>You're reviewing the change in this working directory. You're read-only: review and discuss only‚ do not edit files, commit, push, or reset the tree. Run git rev-parse HEAD and git status first, and anchor every finding to that commit. Write your findings out as a numbered list‚ don't touch the code.

The wording doesn't matter as long as its a second model that hasn't seen your context, told to find what's wrong, before you call the work done.

>Disclosure: this is a from an article on how to automate adversarial reviews between Claude Code and Codex posted to this tool's website scape.work/adversarial-reviews get a free license for scape with reddit-scape2 at signup

hey everyone,

I've been experimenting with different tech to create content like this video (vs low effort blogspam), related to my saas. Curious what everyone's experience has been? What kind of tools are you using to create content (posts, ads, etc.) where are you posting it?

Hey all,

I keep seeing everyone on X talking about loops and loop engineering with agents, and I thought people might find it interesting to see what an orchestrator loop looks like in practice.

I use orchestrators to run many agents in parallel, while following a specific process I write out for them. Orchestrators are basically project managers, and you write their job description.

Disclosure: this is my tool - Scape (I'm an engineer and designer, and built Scape using claude code amongst many other tools).

Scape is a free to try with "reddit-scape1"

Please let me know if you have any questions about building orchestrator loops in general!

Hey all,

I just released a feature in my tool where people can use claude code to create automations that live as editable documents (you can add many different steps - bash script, api, claude sessions, etc). It's still early so I'd love to give out some licenses if anyone is interested in testing and providing feedback thanks.

Requirements: Claude code, MacOS

Finally got this working this weekend, where I can be running multiple sessions at once, and they can all message each other via MCP. This is showing claude code writing a story with a codex session. Very excited about this!

been playing since SARPBC and I am terrible (only sniffing diamond occasionally), but this was my best move

Hey all,

I've been working on creating documents that users can type into to edit and add programmatic steps - where each step can be a bash/claude prompt/api request etc. The output of one step can be used in following steps. Currently claude is able to create the playbook document for me to make the entire thing easier, but it still needs human oversight from a UX perspective in my opinion.

I've been working on a few use-cases, and I was wondering how most people here usually manage your automations? Do you use an AI? is it all CLI?

I used to play a game just like this that was somewhere on addictinggames forever ago. It was a shockwave game and I was never able to find it (it looks very very close to this, please let me know if you know the game)..

After giving up, I figured claude could probably just build it now using threejs... and it did an amazing job.

Being able to replay games that no-longer exist is such a fun use-case (this took less than a day). Try it out it works on mobile and desktop