The honest answer is that most of what you would put on a list of things to automate does not belong in a loop, and the jobs that do belong there are ones you have never written down, because you do not experience them as work. They are the small restorations: checking whether the thing you set up last week is still true, noticing that something drifted, putting it back. A loop holds a state rather than completing a task, so finding candidates means auditing what you restore rather than what you do.

Why doesn't a to-do list work as a source of ideas?

Because a to-do list records intentions, and intentions get crossed off. The items that survive a week of crossing off are the ones that were never really finished: your calendar was prepped on Monday and needs prepping again on Tuesday, your inbox was clear on Friday and is not clear now. Those recurring entries look like nagging tasks and are actually the shape of a state you keep restoring by hand, which is exactly what a loop is built to hold.

The audit that works better takes a week and a notebook. Every time you catch yourself thinking "let me just check whether X is still…" write down what X was, because that sentence is the tell: checking implies a condition you expect to hold and a suspicion that it might not, which is the entire job description of a patrol. By the end of the week you will have somewhere between three and fifteen entries, and they will be more useful than any list of agent use cases on the internet, since they came from your actual life rather than someone's marketing page.

Which candidates deserve a loop?

Run each entry through three filters and expect most to fail at least one. The first is recurrence, meaning the job comes back because your world keeps moving rather than because you left it unfinished. The second is judgment, since a candidate you can express completely as "when X happens, do Y" wants an automation instead, which will be cheaper, faster, and easier to audit than any agent. The third is observability, and it kills the most promising ideas, because a loop can only maintain a state it can see, so a candidate whose drift signal lives somewhere the agent cannot reach is an integration problem wearing a loop costume.

My own rule sits downstream of all three: if a candidate survives them and I still cannot describe the state in a single sentence, it is not ready, and I read that failure as information about the candidate rather than about my writing.

Loops worth stealing

Each of these is written as the state rather than the task, which is the form your loop's instructions need anyway:

• Meeting preparation. Every meeting on tomorrow's calendar has a prep note with the attendees, the last conversation, and the open question.
• Commitment capture. Every message where I promised someone something has a corresponding task, so the promise outlives the thread it was made in.
• Issue triage. No issue in the repository has sat unlabeled for more than a day, and anything matching my urgent criteria has been flagged to me directly.
• Dependency advisories. No project I maintain depends on a package with an open security advisory that I have not at least seen.
• Review latency. No pull request I opened has been waiting on someone for more than two days without a nudge, and none waiting on me has gone unanswered.
• Charge reconciliation. Every charge on this month's statement is matched to a receipt or flagged as unexplained, which is the loop that finds the subscription you forgot in 2023.
• Document filing. Every document that arrived this month is named by a convention I can search and filed where I will look for it.
• Follow-through. Nobody I said I would get back to has gone longer than two weeks without hearing from me.
• Backup verification. Last night's backup completed, and the loop has confirmed a sample file is actually restorable rather than merely present.

The near misses are instructive too. Anything creative fails the judgment filter in the wrong direction, since you do not want a patrol quietly rewriting your work while you sleep. Anything with real consequences on a single wrong action, meaning money moving or messages reaching people who matter, should start as a loop that prepares and proposes rather than one that acts, at least until its diary has earned that trust. And anything you check once a quarter is a calendar reminder rather than a loop, because the standing cost of a patrol only makes sense against a world moving faster than your attention does.

‍

Frequently asked questions

How many loops should I run at once? Start with one and let it become boring before adding another, because the failure modes of a first loop live in the sentence or the cadence, and you will diagnose them far faster without three other loops muddying the picture.

What if my candidate fails the observability filter? Then the work in front of you is connecting the source rather than writing the loop, since an agent that cannot see the state has no way to know when it drifted and will report success while your world quietly diverges.

Can a loop handle something with real consequences? It can, though I would run it in propose-and-confirm mode first, letting it do the noticing and the preparation while you keep the final action, and promote it only once its record shows it would have been right.

What is the fastest way to find out what my agent can already observe? Connect your sources at Fulcra and ask your agent what changed in the last day, since the answer is a concrete inventory of what a loop could watch rather than a guess about what might be possible.

Spend a week writing down every time you check whether something is still true, then connect those sources at fulcradynamics.com and hand the shortest entry on your list to a loop.