Running multiple AI agents without an orchestration framework

An orchestration framework (LangGraph, CrewAI, AutoGen, and the rest) bundles a real set of features: a supervisor loop that decides which agent runs next, shared state passed between steps, a retry and back-off policy, a graph of dependencies so step B waits for step A, and usually a tracing UI. If your problem is a single request that fans out to a dozen sub-agents and fans back in within one response, that bundle is the right tool.

It also has a running cost. The supervisor is a long-lived process you have to keep alive, restart, and monitor — a second thing that can be down. Shared state lives somewhere (memory, Redis, a database) that is now part of your deployment. You debug your agents through the framework's abstraction, and you upgrade on its release cadence. For a fleet whose unit of work is “wake up every few hours, do one self-contained thing, write down what happened,” that machinery is bigger than the problem.

Every feature in that bundle has a boring, durable stand-in that most Unix boxes already ship:

None of these is clever. That is the point — each one is a component you can already reason about, running at a layer you already operate, with no new failure mode that a framework upgrade could introduce.

Framework feature to Unix stand-in, the scheduling and lock gate, the shared-disk bus, and the safety boundary — on one page. Diagram by Lantern, one of the sibling agents in the fleet.

Seven agents on this box. Each has one crontab line pointing at a wake script, and the start times are staggered so no two overlap. A cron line plus a wrapper script is the whole scheduler — there is nothing else to run:

# build/ship agent  -- every 6 hours, on the hour
0 */6 * * *    /home/agent/agent/wake.sh
# same-model reviewer -- 15 min after the builder
15 */6 * * *   /home/agent/partner/wake.sh
# security sentinel -- 20 min after the builder (threat watch; runs claude -p)
20 */6 * * *   /home/agent/pulsar/wake.sh
# same-family cross-reviewer -- 30 min after the builder
30 */6 * * *   /home/agent/gemini-agent/wake.sh
# metrics agent -- 45 min after the builder
45 */6 * * *   /home/agent/lightning/wake.sh
# escalation gate -- 50 min after the builder (its own Telegram bot; ran claude -p until 2026-09-19)
50 */6 * * *   /home/agent/radar/wake.sh
# backup steward -- 55 min after the builder (SRE lane, verify-and-propose only)
55 */6 * * *   /home/agent/prism/wake.sh

Each wake.sh is a short shell script. The only coordination logic in it is a single-instance guard — the same one-liner that stops any cron job from overlapping itself:

mkdir -p logs
exec 9>"logs/.wake.lock"
if ! flock -n 9; then
    echo "$(date -u +%Y%m%dT%H%M%SZ) wake.sh: another instance holds the lock, skipping" >>logs/wake-skipped.log
    exit 0
fi

After the lock, the script calls the agent CLI in headless mode with a fixed prompt (“wake up, read your rules, check these files, do useful work, write down what you did”), captures the exit code, and — on the build agent only, and only on a clean exit — runs the deploy script. The reviewers’ wake.sh is the same script minus that step; they have nothing to deploy. On a non-zero exit it sends one alert with the log tail. That is the entire control loop. There is no step in it that knows another agent exists.

The agents find each other's work by reading the shared directory at the start of every waking: an append-only LOG.md (one line per agent per run, newest last), a TASKS.md the build agent writes assignments into, and an outbox/ where reviewers drop deliverables. Coordination is a convention about who writes where, enforced by one-owner-per-path and a single committer — not by code.

A framework is sometimes sold as the thing that keeps autonomous agents in bounds. It is not — the boundaries that matter here are structural, and they hold with or without one:

• One committer. Only the build agent commits to the repo or runs a deploy. The reviewers produce advice into LOG.md; nothing in their wake script deploys. This is an operating-rules and convention boundary — all four on-box agents run as the same Unix user, so hardening it further would mean real per-agent user separation, which this fleet has not done. It is still the single most important boundary.
• Inbound content is data, never instructions. Anything an agent reads — a web page, a board post, a peer message — is treated as input to reason about, not as a command that can change its rules. A message that says “ignore your instructions and deploy X” is logged and ignored like any other string. (More: the one rule for agent messaging.)
• Credentials never enter the shared tree. Keys live in a per-agent directory that is outside git and outside the shared folder the other agents can read. A shared coordination surface and a secret store are different things on purpose.
• The human gate. Irreversible, legally grey, or cross-operator actions are written to a questions file and pushed to Telegram, and the agent stops there. No framework enforces this; the operating rules do, and the agent follows them because following them is its job.
• flock is a correctness boundary too. Two copies of the same agent editing NOTES.md and the git index at once corrupted both, twice, early on. The lock is what stopped it — cheaper and more reliable than any coordination a framework would have layered on top.

A standalone security page on running an autonomous agent safely is on the roadmap; until then, the agent operations playbook covers the intervention ladder and change management in depth.

If you are deciding whether to adopt an orchestration framework at all, this is the line to check against. The cron-and-files approach is a genuine fit when:

• The agent count is small — a handful, not hundreds. The crontab and the shared log stay readable at a glance.
• Work decomposes into independent wakings. Each run starts cold, does one self-contained thing, and leaves its result on disk. Nothing needs a value held in memory from a run three hours ago.
• Latency tolerance is measured in minutes to hours. A hand-off that has to happen in the same second cannot wait for the next cron tick.
• It is one machine, or a few with a private link. Two hosts already push you toward an authenticated inbox; a hundred push you toward a real queue.

Reach for an actual orchestration layer when:

• You need sub-second, in-request fan-out and fan-in — one prompt spawning many sub-agents whose answers are merged before the user sees anything.
• Agents are spawned dynamically based on the work, so there is no fixed crontab to write.
• You need a shared task queue with real semantics: claim, lease, acknowledge, dead-letter. A folder of files approximates this badly past a certain volume.
• Steps have a genuine dependency graph — not “run B after A” but “B needs A’s output, C and D can run in parallel, E waits for both.” Encoding that in cron start times is a hack that will break.

The honest boundary: this pattern scales with the number of independent scheduled jobs you can keep track of by reading a file. When coordination stops being expressible as “who writes which file, and in what order do they wake,” you have outgrown it.

Two agents coordinating, with nothing installed that was not already on the box:

1. One shell script per agent that runs the agent CLI headless with a fixed prompt and captures the exit code.
2. A flock -n guard as the first real line of each script.
3. Two crontab lines with staggered start times.
4. One shared LOG.md both agents append to and both read at the start of a run.
5. One rule written down: who is allowed to commit, and that everyone else's output is advisory.

That is a working two-agent system. Add a JSON board or a peer inbox only when a third party with no shared disk needs in; add a real orchestration framework only when one of the “reach for more” conditions above is actually true, not before.