A Redditor's screenshot of an agent named "Lloyd" running 600+ tickets through a SQLite database got 431 upvotes in r/ClaudeAI this week — not because the tool is new, but because it's the clearest public example yet of a pattern most loop-engineering write-ups only describe in the abstract: a persistent agent that never really stops, remembers everything it's ever seen, and only escalates to a human when something looks genuinely wrong.
The post, titled "Example of a real working loop orchestrator" by u/croovies — a self-described full-time developer with 20+ years as a senior engineer and designer — is worth a proper teardown, because it's a rare from-the-wild specimen of the pattern explainx.ai's loop engineering guide and official loops breakdown describe as a target to build toward. This post walks through what Lloyd actually does on every pulse, why the SQLite ticket table is the part that matters more than the UI around it, and how to build the same pattern with plain Claude Code if you don't want to wait for a Windows build of the tool that runs it.
TL;DR
| Question | Direct answer |
|---|---|
| What is Lloyd? | An orchestrator agent built on scape.work (Mac-only tool) that manages its own SQLite ticket table — 600+ tickets so far, per u/croovies |
| What triggers it? | A recurring "heartbeat" — a standing checklist re-run on a cadence, not a one-shot scheduled job |
| What does each pulse do? | Check email for bug reports, check docs for staleness, scan app logs for silent errors, investigate anomalies read-only, log findings, file tickets |
| What's the clever bit? | Scanning query_oslog for Error/Fault-level noise catches bugs that never generated a user-facing report |
| What's the safety pattern? | A read-only investigation agent runs first; write-access tools (PR, commit, release) are a separate toolkit used only after a ticket is staffed |
| Do I need scape.work? | No — the pattern (mission file + heartbeat + ticket DB) is replicable with plain Claude Code, cron, and SQLite |
| Where's the community reaction? | u/DeepFuckingVigo built a similar 12-hour-heartbeat orchestrator for client email triage; the thread pointed to OpenAI's Symphony repo as another reference point |
What Lloyd actually does on a heartbeat
u/croovies' orchestrator is named Lloyd, built on a Mac-only tool called scape.work (a Windows version is reportedly in development). Lloyd's primary job, in the OP's framing, is managing its own internal tickets table — "like Lloyd's own private Jira" — which has accumulated 600+ tickets by the time of the post.
The screenshot attached to the thread shows a Sessions panel listing several named orchestrator instances running in parallel — Lloyd, another top-level orchestrator called Morty, and per-repo or per-feature child sessions like 555-argus- and 388-integr- — each pinned to a different model (Opus 4.8, Opus 5, Fable 5 all appear), each with live status, a ticket count, and a running cost that ranges from $0.01 to $4.70 per session in the screenshot.
The core mechanism is the heartbeat: a recurring pulse, on the order of an hourly cadence in the UI shown (the interval is user-configurable), that re-runs a fixed checklist every time it fires. Per the post, the checklist is:
- Run a playbook to check email for new customer bug reports, cross-referencing related previous tickets before staffing a new one.
- Check whether website docs need updating based on tickets merged since the last pulse.
- Query the app's own runtime logs (
query_oslog) over roughly the last 15 minutes, scanning for problematic entries. - Dispatch a read-only investigation agent when something looks worth investigating, to root-cause it before any ticket is filed — or staff a ticket directly if the cause is already obvious.
- Record every pulse's findings — window and finding, even when the answer is "clean" — in a running log table.
- Skip transient or expected noise — Lloyd is explicitly instructed not to ticket normal, expected log churn, only genuine problems.
- Surface, don't auto-act, on new ideas. Bugs or enhancements spotted along the way get added to the ticket table tagged "to be prioritized with you" — the agent proposes, the human still decides priority.
That last point is easy to skim past but it's a real design decision: Lloyd has write-access tooling (the sidebar in the screenshot lists Create PR, Commit & Push, Worktree, Create License, Release Notes, Bump Version, Release DMG/RC, Open in Xcode — a genuinely production-capable toolkit), yet it's told to route new discoveries into a human review queue rather than act on them unprompted. Investigation is autonomous; prioritization stays human.
Heartbeat vs. cron: a distinction worth taking seriously
When u/GratefulForGarcia asked in the thread whether this is just a scheduled workflow, u/croovies drew a specific line: it's not cron-scheduled in the "run this command every N minutes and forget about it" sense. It's closer to "a person always checking your email every 10 min" — a persistent presence that returns to the same standing context each time, rather than a stateless job invocation.
That distinction matters because a cron job and a heartbeat loop can look identical at the infrastructure layer — both are "a thing that fires on a timer." What separates them is what happens inside the fired unit:
| Cron job | Heartbeat loop | |
|---|---|---|
| Trigger mechanism | Timer | Timer (can literally be cron underneath) |
| Memory between runs | None by default | Persistent — reads/writes a durable state store every pulse |
| Checklist | Whatever the script does, once | A standing checklist re-run every pulse, with context of all prior pulses |
| Escalation | Script exits or errors | Investigates, then files a ticket a human reviews |
| Failure mode | Silent unless you check logs | Logs every pulse's finding, including "clean," to a running table |
The mechanism is boring — it's a timer either way. The pattern is what's interesting: a standing checklist plus durable, queryable memory turns a stateless timer into something that behaves like a team member doing the same rounds every shift. This is the same distinction explainx.ai's Anthropic loops guide breakdown draws between turn-based loops and one-shot invocations — a heartbeat orchestrator is the proactive, standing-checklist end of that spectrum.
Why SQLite beats a markdown scratch file at scale
A lot of loop-engineering setups — including plenty covered on this blog — lean on a markdown file (PROGRESS.md, TODO.md) as the agent's memory between runs. That works fine for dozens of items. It stops working somewhere well before 600.
u/croovies' framing is the useful part: the ticket table gives the orchestrator "a database of tribal knowledge that can be passed to any model." Two things fall out of that:
- Structured cross-referencing. When a new bug report comes in, Lloyd can query for related past tickets the way a human engineer checks prior context before starting new work — a
WHEREclause, not a full-text skim of a growing markdown file that eventually blows past what fits comfortably in context. - Model portability. Because the memory lives in a database rather than baked into one model's running context, the sessions panel shows Lloyd's children running on different models (Opus 4.8, Opus 5, Fable 5) against the same ticket table. The knowledge compounds independent of which model happens to be doing the work that pulse.
This is the same underlying bet PrimeIntellect's Prime Agent makes with its Continual Harness — durable state that outlives any single session — and the same problem LoopX is solving at the control-plane layer with objectives, gates, and evidence living in .loopx/ on disk instead of inside a model's context window. Different implementations, same root insight: the agent's memory should live outside the conversation, in something you can query.
The silent-bug technique is worth stealing on its own
The email-scanning step in Lloyd's checklist is unremarkable — plenty of support-inbox triage agents exist. Step 3, the query_oslog scan, is the genuinely clever piece of this whole setup.
Most bug-discovery loops are downstream of a report — a customer complains, a crash gets submitted, a support ticket lands. That entire category misses bugs that are real, reproducing, and degrading the product, but that never generated a user-facing symptom loud enough to prompt a report. Think: a background sync silently failing and retrying, a watchdog firing and relaunching a process without visibly crashing the app, a repeated warning nobody's paying attention to because it never blocks anything.
Lloyd's fix is to treat the app's own logs as a first-class signal source, independent of whether a human ever noticed anything. Every heartbeat, it queries roughly the last 15 minutes of runtime logs for:
- Error and Fault-level entries
- Crashes and exceptions
- Watchdog fires and relaunch loops
- Sync or scan failures
- Repeated warnings
— and only escalates to investigation when something crosses the bar of "worth looking at," per the explicit instruction not to ticket transient or expected noise. That last constraint is doing real work: a naive version of this step would flood the ticket table with every routine warning and turn 600 tickets into 6,000 of mostly noise. The discipline of "log it as clean unless it's genuinely a problem" is what keeps the ticket table a signal, not a firehose.
The read-only investigation agent is the safety pattern to copy
Before Lloyd files a ticket off something it noticed in the logs, it dispatches a read-only investigation agent to root-cause the anomaly first — unless the cause is already obvious, in which case it staffs a ticket directly. That investigation agent has no write access. It can look, but it cannot touch.
This is the load-bearing safety boundary in the whole setup, and it's worth separating from the flashier toolkit sidebar (Create PR, Commit & Push, Release DMG/RC, and the rest). Those write-capable tools exist and are real — this is not a toy demo — but they're gated behind a ticket that a human has staffed, not behind "the log scanner found something odd." A misread log line during investigation produces, at worst, a wrong ticket a human dismisses in seconds. It can't produce a bad commit, a bad release, or a bad PR, because investigation and action are different agents with different permissions.
If you're designing your own heartbeat loop and only take one thing from this teardown, this is the one worth taking: investigate read-only first, act only after a human-reviewable artifact (a ticket) exists.
How to build your own version with plain Claude Code
You don't need scape.work specifically — it's one tool implementing this pattern with a UI (sessions panel, toolkit sidebar, a "Laws & Permissions" section) around it, and it's currently Mac-only. The pattern itself — mission file, heartbeat cadence, ticket database, investigate-then-ticket flow — is buildable with Claude Code's own primitives, per explainx.ai's loop engineering guide and the /goal command.
1. Write a mission markdown file. u/DeepFuckingVigo's version of this pattern — a similar orchestrator built for triaging inbound client emails — defines the heartbeat's checklist declaratively in the orchestrator's mission markdown, the same way you'd write a CLAUDE.md. Keep it to a numbered checklist, not prose: check X, cross-reference Y, escalate if Z, never ticket W.
2. Pick a heartbeat cadence that matches the noise floor. u/croovies' Lloyd runs on roughly an hourly cadence for a live product's logs and bug reports. u/DeepFuckingVigo's client-email triage runs on a 12-hour heartbeat — slower, because inbound client email doesn't need 15-minute freshness the way a crash loop does. Set the interval to how fast a genuine problem needs a response, not to an arbitrary default. explainx.ai's own /loop and /schedule guide covers the built-in interval commands if you're staying inside Claude Code rather than wiring your own cron.
3. Sketch a ticket table before you write any agent logic. A minimal schema that supports cross-referencing looks like:
CREATE TABLE tickets (
id INTEGER PRIMARY KEY,
title TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'open', -- open, staffed, merged, wontfix
source TEXT NOT NULL, -- email, log_scan, docs_check, manual
severity TEXT,
related_ticket_ids TEXT, -- JSON array, for cross-referencing
investigation_notes TEXT,
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
CREATE TABLE pulse_log (
id INTEGER PRIMARY KEY,
pulse_at TEXT NOT NULL,
window_start TEXT,
window_end TEXT,
finding TEXT NOT NULL, -- can be "clean"
ticket_id INTEGER REFERENCES tickets(id)
);
The pulse_log table matters as much as tickets — it's what lets you (or the agent) later answer "was this always broken and we just never noticed" rather than only ever seeing the moment a ticket got filed.
4. Separate the investigation step from the write-access step. Give the log-scanning/investigation agent read-only tools — grep logs, read code, query the ticket table. Give a different invocation (or a gated Claude Code permission mode) the write-capable tools — commit, PR, deploy. The Lloyd setup's toolkit sidebar is real production tooling; the discipline is in when it's allowed to be used, not whether it exists.
5. Log "clean" pulses, and tell the agent explicitly not to ticket noise. Both are easy to skip and both matter. Logging clean pulses gives you an audit trail proving the heartbeat is actually running, not just silently dying. The explicit "don't ticket transient noise" instruction is what keeps the ticket table usable at ticket 600 instead of drowning in duplicates by ticket 60.
What the thread's reactions add
Beyond u/DeepFuckingVigo's client-email variant, the subreddit's auto-mod TL;DR summary noted the SQLite ticket-memory pattern as the detail that elevated the post from "cool demo" to "genuinely useful long-term infrastructure" in the community's read — several other commenters described their own multi-agent setups sharing a database or "blackboard" as the coordination layer between agents. One commenter pointed to OpenAI's Symphony repo as another blueprint for this same category of pattern; treat that as a reference point the thread named worth investigating on your own rather than a claim this post is verifying — we haven't reviewed Symphony's internals directly.
The throughline across all of it, OP's setup included, is the same one explainx.ai's loop-engineering coverage keeps landing on: the interesting work isn't the scheduler. It's what the agent remembers between pulses, and how disciplined it is about not acting on what it finds until a human's had a chance to look.
Related reading
- Loop Engineering: How to Design Coding Agent Loops That Run While You Sleep — the pillar guide this post's pattern extends
- Claude Code Loops Official Guide: Turn-Based, /goal, /loop, and /schedule — Anthropic's own loop taxonomy, mapped to commands
- Claude Code /goal command — completion-condition primitive for multi-turn work
- LoopX: A Control Plane for Long-Running AI Agent Work — a different tool solving the same durable-state problem at the control-plane layer
- Prime Agent: Prime Intellect's Self-Improving RLM Coding Agent — another persistent-memory harness, refining its own state via /refine
- How to Turn Agent Skills Into Loops — packaging repeatable checklists as skills your heartbeat can call
- Top 5 Loop Engineering Courses — structured learning if you want to go deeper than one Reddit teardown
Source: r/ClaudeAI — "Example of a real working loop orchestrator" by u/croovies, ~431 upvotes as of August 14, 2026. scape.work is a third-party tool independent of Anthropic; specifics of the tool (interval defaults, pricing, Windows release date) may change after publication — verify against the tool's own site before relying on them.