A loop needs four things: something to wake it on a schedule, an agent that can run without a human watching, somewhere durable to write down what it did, and a way to ask what changed since last time.
Think of it as a clock, a worker, a notebook, and a newspaper. The clock is whatever wakes the loop meaning cron on a Unix or macOS box, Task Scheduler on Windows, etc. The worker is the agent itself, and if you already run Claude Code or Codex you have one that can be invoked headlessly. The notebook is durable storage for what the patrol did on its last pass. The newspaper is the part with no ancient equivalent: a way to ask what happened in your world since the previous pass and get back only the changes.
Start without one. Anthropic's engineering team, drawing on work with dozens of teams building agents, reports that the most successful implementations were not using complex frameworks or specialized libraries and advises developers to begin by calling the model APIs directly, because frameworks introduce abstraction layers that obscure the underlying prompts, make debugging harder, and tempt you toward complexity a simpler setup would have handled. That guidance applies with extra force to a patrol loop, which has none of the problems frameworks exist to solve, since there is no execution graph, no fan-out across worker nodes, and no handoff between specialists, just one short pass repeated on a timetable.
Frameworks do earn their keep when a single waking turns into a branching workflow whose steps need independent retry and recovery. So the rule is to add one on the day your pass structure stops fitting in five instructions but not before.
This is where the tooling question stops being trivial, because asking "what changed?" across the sources that define your state means either a service that maintains that picture for you or a change-detection layer you build and maintain yourself, and the second option amounts to roughly one integration per source, plus the logic to diff each one, plus the ongoing work of keeping all of it current as those APIs drift. Skipping the question entirely is the third option and the most common one, which produces the loop issue and the disappointing first month that usually follows.
The hosted version I would point you to is my own company's tool. Fulcra answers the newspaper question with data-updates over the period since your last pass, and its versioned file store covers the notebook, which collapses two of the four parts into a single connection. Both conventions are published as open-source skills your agent can install for itself, with fulcra-memory handling the notebook, fulcra-situational-awareness handling the newspaper, and fulcra-agent-teams handling the coordination problem that arrives with your second loop.
More than the tooling discourse suggests. A vector database is unnecessary until a loop demonstrates a real retrieval need, which for single-purpose loops frequently never happens. A message queue is unnecessary until loops need to hand work to each other, and even then a shared inbox in a file store covers the common cases. A dedicated observability stack is unnecessary at the start, because the loop's own notebook is a legible log written in prose, and reading a week of it will teach you more about your cadence than a dashboard would.
Can I run an agent loop without writing any code? Yes, since the clock is a scheduler you configure rather than program, the worker is an agent you instruct in English, and the notebook and newspaper are commands your agent can run on your behalf.
Do I need a server to run a loop? Not for personal loops, because your own machine and its scheduler are sufficient whenever it is awake, though a loop that must run while your laptop is closed needs somewhere that stays on.
When should I add an orchestration framework? When one waking involves a branching workflow whose steps need independent retry and recovery, which is a different problem from running the same short pass repeatedly.
What is the minimum tooling for a first loop? A scheduler you already have, an agent you already run, and one connection that answers what changed and stores what you did, which is what Fulcra provides through a single CLI, though building your own change detection per source works too and costs maintenance instead of trust.
Take inventory before you install anything, because you likely have three of the four parts already, and the fourth is one command away with uvx fulcra-api.
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}
