Example of a real working loop orchestrator
Lloyd, an orchestrator, manages its internal tickets table, which is a simple SQLite table. It has successfully managed over 1200 tickets, functioning like an internal Jira system. This allows Lloyd to query previous related tickets whenever a new one arises, enhancing its ability to handle new work efficiently.
This account details a specific orchestrator's design and its use of an internal SQLite table to manage over 1200 tickets, unlike general discussions of orchestrator concepts.
Time & source
Times shown in UTC
Display time zone: UTC
Local time zone unavailable; showing UTC.
PublishedOffset at this time: UTC+0Oct 10, 2026, 04:14 UTC
IngestedOffset at this time: UTC+0Oct 10, 2026, 09:00 UTC
- Published
- Oct 10, 2026, 04:14
- Ingested
- Oct 10, 2026, 09:00
- Source type
- Dev community
- Tier
- Community
- Source status
- Healthy
Tier is a per-source editorial setting, not a per-item score.
Wanted to give a little peak into what one of my loop orchestrators 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 1200 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/0qvm6nb7fkuh1.png?width=2164&format=png&auto=webp&s=814071470bfd4e3ddb3ba7a6ceb7a6b32fa79f6f
The main concept I want to point out is the heart beat, and the pulse action items.
- 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
- 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.