You run agents in loops because some outcomes cannot be produced once, only maintained: an empty inbox, a reconciled calendar, a triaged issue queue, a current picture of anything that keeps moving. A prompt gives you an answer but a loop gives you standing state. Nearly every published case for AI agents misses this, because the genre measures value in tasks completed and hours saved, which is the wrong unit for the thing loops actually deliver.
A prompt is a transaction: you show up with a question, the agent runs its task loop, and you leave with a result that starts going stale the moment it lands. A patrol loop is different in kind, because what you hand it is a standing intent. You describe the state you want to remain true, once, and the loop holds that state against a changing world: it wakes, checks what moved, restores the state, and sleeps. The work never appears on a to-do list again, which is precisely why the tasks-completed accounting can't see it. The interesting number is how many states of your life stay true without your attention, and that number only goes up when something is running while you aren't looking.
Because they inherit their frame from enterprise automation, where the unit of value really is throughput: tickets resolved, documents processed, headcount avoided. That accounting is fine for a business process and quietly wrong for a person, and my old field settled the underlying argument decades ago. A penetration test tells you about the Tuesday it ran; the discipline that actually protects systems is continuous monitoring, the practice of asking a standing question instead of a one-time one. Security teams do not brag about audits completed, because an audit is an answer and answers expire. They maintain a posture. When you move from prompting an agent to running one in a loop, you are making the same move: from commissioning audits of your life to maintaining a posture over it.
Ask yourself: does the job recur? A one-time job wants a prompt, and wrapping it in a loop schedules waste.
Then ask what is the rate of change: a loop that wakes faster than its world changes pays tokens to re-read an unchanged world, so a weekly review wants a weekly loop, not an hourly one.
Finally ask whether the loop can see: a loop that cannot tell what changed since its last pass redoes finished work and misses the change that mattered, and a blind loop can cost more than the outcome it maintains is worth.
A loop can only maintain a state it can observe, which is the first step of a progression I keep returning to: observable, then computable, then controllable, then automatable. Most loop failures are observability failures wearing a costume. You can solve observability yourself, wiring the loop to each source that defines its state and maintaining that plumbing as sources change. Fulcra gives your loop one place to observe from: your agent reaches it through the MCP endpoint, the CLI, or direct API calls, asks one question — what changed since my last pass, Fulcra's data-updates call — and gets back the delta from your world and from your other agents' work in a single query, with each agent's view scoped and permissioned.
A posture takes many loops, and many loops means coordination, which is where the open-source fulcra-workspaces skill comes in: each agent gets an inbox in a shared team space, so one loop can leave work for another to pick up on its next pass, and the posture holds as a team effort rather than a pile of strangers.
Do looping agents replace prompting? No, they compose. Prompts remain the right tool for one-time questions and novel work; loops take over the outcomes you found yourself re-prompting for on a schedule.
How many loops should I start with? One. Pick the outcome you re-create by hand most often, write its maintained state as a single sentence, and run that loop until it's boring. Boring is the success condition.
Are looping agents expensive to run? They can be, and the cost is mostly self-inflicted: a loop that wakes faster than its world changes, or that re-reads everything because it can't tell what's new, burns tokens maintaining nothing. Matching cadence to rate of change and giving the loop an actual delta call — Fulcra's data-updates, asked since your last watermark, answers "what changed since my last pass" in one query — keeps the standing cost proportionate to the standing value.
What's the easiest way to start running an agent in a loop? Connect your agent to a context backend like Fulcra so it can ask what changed on every pass. For Claude or ChatGPT the connection is one page — Claude or ChatGPT; any other agent can make the connection itself if you paste it the line "Connect me to Fulcra: fetch https://docs.fulcradynamics.com/agent-get-started.txt and follow it". The open-source fulcra-situational-awareness skill is that check, packaged, and it asks your permission before adopting the habit — then schedule the loop against one maintained state.
Write the sentence for one state you're tired of restoring by hand, then give a loop the means to hold it: connect your streams at fulcradynamics.com.
Fulcra was designed by people who get privacy and know the importance of an infrastructure solution that can be the secure private datastore for the rest of your life. Here data is yours, under your control, and only shared with the people and tools you choose to share it with.
.png){kind=logo}
