Skip to main content
Lightning Jar - Web Studio Lightning Jar Wordmark

Not Every Automation Deserves an Agent

A vintage wooden clock with Roman numerals and a hot air balloon automaton display below the dial

We build with coding agents daily, we publish open research on how they behave, and our own website answers questions through one. So the following sentence carries some weight coming from us: this month we moved Replicator's operations layer to a tool whose founding argument is that most automation should not be an agent at all.

The tool is swamp, from Swamp Club. Its pitch is composable behaviors instead of open-ended agent sessions: typed building blocks wired into declarative YAML workflows, secrets held in vaults, every run scheduled, logged, and repeatable. You describe the automation once, commit the description to the repository, and it runs the same way every time, which is precisely the property an agent transcript does not have.

The Ops Problem is a Repeatability Problem

Replicator accumulated the operational chores every production application accumulates: data audits that should run nightly, orphaned-storage sweeps, health probes, preflight checks before risky changes. For a year the honest answer to "how do these get done" was "an agent session does them when someone remembers to ask." The sessions did good work. They also did slightly different work each time, at conversation prices, with the audit trail scattered across chat logs.

The realization was not that agents are bad at this. It is that the work is beneath them. A data audit is the same twelve queries every night. A storage sweep is the same classification of the same six blob families. Paying a reasoning model to rediscover a fixed procedure nightly is renting intelligence to do a checklist, and the token bill is the smaller half of the cost; the bigger half is that a procedure rediscovered nightly is a procedure that can drift.

What the Committed Definitions Look Like

Replicator's repository now carries six swamp workflows as versioned YAML, each a sentence to describe:

  • prod-data-audit, nightly: scan, gated fix, re-validate, with versioned findings.
  • orphan-blob-audit, weekly: sweep six storage families, gate any deletion behind approval, re-validate after.
  • prod-smoke, every thirty minutes: external health checks that email on failure. The definition file carries our favorite comment in the repo: a scheduled probe that fails silently would be theater.
  • esm-bundle-audit: build the deployment output and load-check every serverless function bundle in real Node, asserting the whole import graph actually loads.
  • model-swap-preflight: a spend gate, then a thirteen-gate regression suite, then a recorded go/no-go, run before any production model change.
  • phased-db-migration: ship with fallback, gate the deploy, migrate, validate.

The fourth one has a story. Last week a dependency's internals broke our production MCP endpoint with an error that never appears in local dev or tests, only under the deployed runtime's module loader (the finding has its own entry). The incident response was agents at their best: diagnosis across repositories, a fix, a write-up. The prevention is a workflow: load every bundle the way production loads it, on a schedule, forever. An agent earned the lesson; a behavior keeps it.

The Division of Labor We Actually Believe In

That split generalizes. Agents are for work that is different each time: diagnosis, design, writing, refactoring, the response to a novel failure. Scheduled, deterministic, auditable procedures are for work that must be the same each time: audits, sweeps, probes, gates. The failure mode on one side is an expensive agent reinventing a checklist with occasional creative liberties. The failure mode on the other side is a brittle script nobody can safely change. The division keeps each tool where its failure mode is least dangerous.

What makes swamp fit the agent era rather than predate it is that the two sides compose. The YAML definitions live in the repository, which means our coding agents can read them, reason about them, and propose changes under review, the same structure-is-the-context principle we keep finding everywhere. The agent authors and amends the procedure; the procedure runs without the agent. When a workflow fails, its structured reports become the input to the next agent session instead of a mystery.

Keep in Mind

This is a young adoption: one production codebase so far, with a pilot for this site under consideration, and we expect to learn where the edges are. Swamp is proprietary (free for solo use), so it is a bet on a vendor, softened by the fact that every definition is plain YAML in our own repository and the CLI degrades gracefully offline. And behaviors do not absolve you of judgment: a gated fix still needs a human at the gate, which is where we want one anyway.

But the early economics are hard to argue with. The chores that used to cost an agent session each now cost approximately nothing per run, the definitions are reviewed like code because they are code, and the agents we do run spend their tokens on problems that deserve them. A studio that measures LLM behavior for a living should be the first to admit when the right amount of LLM in a loop is zero.

headshot of Kevin Peckham
Kevin Peckham
Principal, Lightning Jar

Ask Eljay

Ask about the studio's work, research, packages, or writing. A few starters:

Answers come from this site's own content and link their sources. For anything that matters, email hello@lightningjar.com.