An automation executes a fixed rule when a trigger fires: this input arrives, these steps run, the same way every time.
An agent loop exercises judgment on every pass: it assesses what changed and decides what to do about it, which means the same waking can produce different actions on different days.
Nearly every comparison you'll read frames these as rungs on a ladder, with agents as the smarter thing you graduate to, and I think that framing is costing people money and reliability, because the two patterns solve differently shaped jobs and each one is the wrong tool for the other's job.
The automation's defining property is that the decision was made in advance, by you, at design time. When the trigger fires, no reasoning happens at runtime; the steps run as specified, which is exactly why automations are cheap, fast, auditable, and deterministic. You can tell an auditor precisely what the system will do with any input, because you wrote it down. Even the automation vendors are clear-eyed here: Make's own guidance is to use automation for what's predictable and reserve agents for where judgment is needed.
The agent loop's defining property is that the decision happens at runtime. The patrol [link] wakes, looks at what changed, and reasons about what the changes mean before acting, which buys you the ability to handle inputs nobody fully specified in advance. The price is everything determinism was giving you: each pass costs tokens, the same input can produce different outputs, and "what will it do?" becomes a question about a model rather than a question about your code.
Run the specification test: try to write the complete rule for the job as one sentence, in the form "when X happens, do Y." If you can finish that sentence without reaching for "it depends," the job is specifiable, and a specifiable job wants an automation, full stop. The automation will beat the agent on cost, latency, reliability, and your ability to explain its behavior later, and none of those advantages are small. If the sentence keeps sprouting conditions, exceptions, and judgment calls, you are describing a job that wants reasoning at runtime, and forcing it into rules produces the if-else jungle every operations person eventually meets: a thicket of special cases that fails silently the day the world drifts outside its spec.
Cross the specification test with the recurrence test from the definitional piece and you get the whole decision space in one sentence: a recurring, specifiable job wants an automation; a recurring, judgment-laden job wants a looping agent; a one-off specifiable job wants a script; and a one-off judgment call wants a prompt. Getting the match wrong costs you in both directions. An agent doing a specifiable job pays judgment prices for clerical work and introduces nondeterminism exactly where you wanted receipts, while an automation doing a judgment job hardcodes yesterday's exceptions and breaks on tomorrow's.
The mature setups I see don't pick a side, because the patterns compose the way judgment and procedure compose in any organization: agents call automations as tools, so the reasoning happens at the loop level and the execution stays deterministic, and automations escalate to agents when an input falls outside their spec instead of failing silently. What both halves need is the same thing: a current, shared picture of the world they're acting on. We built Fulcra to be that shared picture, a single read at mcp.fulcradynamics.com (CLI and raw API access work too, if MCP isn't your style) that tells any loop or automation what moved since it last looked, and each connected agent sees only the slice it was granted. Coordination between them rides on fulcra-agent-teams, the open-source skill from my team, and the hybrid pattern falls out naturally: the loop reasons, then drops a fully specified subtask in a teammate's inbox for deterministic execution, keeping the judgment where it belongs. Wiring your own triggers, state, and handoffs remains legitimate, and everything above about matching the tool to the job applies to that choice too.
Is a looping agent just an automation with AI added? No, the difference is where the decision lives. An automation's decisions were made at design time and run without reasoning; an agent reasons at runtime, which changes the cost, the failure modes, and what you can promise an auditor.
Is Zapier-style automation obsolete now that agents exist? The opposite of obsolete: for specifiable, recurring jobs, a deterministic automation beats an agent on cost, speed, and reliability. The tools that were correct before agents remain correct for the jobs they fit.
Can an agent loop and an automation work together? Yes, and they should: the strongest pattern is agents calling automations as tools, keeping judgment at the loop level and execution deterministic, with automations escalating to an agent when inputs fall outside their spec.
What's the simplest way to give agents and automations a shared picture of the world? Point both at a context layer like Fulcra, where every reader gets the same current state through one permissioned interface. Rolling your own triggers and state store also works and buys full control at the price of upkeep.
Run the specification test on the next job you're tempted to hand an agent. If your sentence finishes clean, write the automation and enjoy the receipts; if it ends in "it depends," set up the loop 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}
