19 agents, 47 scheduled jobs, zero restarts

The problem we were solving for ourselves

Running an agency means the same work every week: research the market, spot the patterns, decide what to build, build it, check it, ship it, then work out whether any of it was worth doing. We were the bottleneck at every one of those steps.

The obvious move — one big agent with a long prompt — fails for a reason that has nothing to do with model quality. A single agent that researches, decides, builds, and verifies its own work has no independent check on itself. It will confidently ship something wrong and then confirm that it was right. The failure is structural, not intellectual.

So we built the thing an agency actually is: specialists with defined mandates and a chain of custody between them.

The architecture: a pipeline with a hard gate

Nineteen agents, each with its own identity file stating its mandate and its hard limits, its own skills directory, and its own model configuration. The core content path runs in one direction:

research → dreamer → operator → coder → qa → publisher
(gather)   (pattern)  (approve)  (build)  (verify) (ship)

Each handoff is a real boundary, and the boundaries are written into the agents themselves. The build agent's own instructions read: "You build what Operator approved. Nothing more. Nothing less." The approval agent's read: "You are the gate between IDEA and BUILD… nothing reaches Coder without going through you."

The verification agent is the one that matters most, and it is deliberately kept ignorant:"You are independent of the build — you don't know what coder thinks the result should be; you read the manifest yourself and check the artifact against it." That single design decision is what stops the system from grading its own homework.

The two agents that produce nothing

This is the part most multi-agent designs skip. Two of the nineteen agents create no output and take no action at all — they exist purely to keep the rest honest.

• The health mirror reads what every other agent is doing and reports whether the system is healthy, watching for trouble, or in trouble. Its instructions are explicit that it does not act: "You compute the state. You do not interpret it for action."It runs a sweep every morning.
• The retention auditor looks at every track the system has produced and asks whether it is still earning its keep — improve, park, or prune. It recommends; a human decides. And when something is pruned, "the artifact moves to archive — never deleted." It runs weekly.

An agent fleet with no auditor drifts silently. You do not find out until output quality has been degrading for a month. These two are the cheapest insurance in the system.

The orchestration layer

One agent acts as the operator and thought partner for the whole fleet, and it owns the schedule: 27 of the 47 scheduled jobs are it dispatching work into other agentsrather than doing the work itself. A representative slice of what runs unattended:

Twelve jobs run daily, nine weekly, and eight on continuous intervals. Across 68 days the fleet logged 972 agent sessions — roughly fourteen a day, unattended.

What it runs on

One Linux VPS: 4 vCPU, 15 GiB RAM. No Kubernetes. No container orchestration platform. No managed agent service. The agents run as plain systemd user services, behind a Caddy reverse proxy, with PostgreSQL and Valkey for state, fail2ban on the edge, and the control dashboard reachable only over a private Tailscale network — never exposed to the public internet.

At survey time all five agent services and all nine hosted application services reportedzero restarts, on a host with disk at 16%.

We mention the modest hardware deliberately. The interesting constraint in agent systems is almost never compute — it is context, state, and control. A fleet this size fits comfortably on a machine you could rent for the price of a couple of lunches.

What broke — the honest part

Of 47 scheduled jobs at survey time: 34 healthy, 6 in error, 7 never yet run. We are showing you the 6, because their pattern is the single most useful thing on this page.

Not one of those failures was the model being wrong. Every single one was dependency drift, configuration, or an upstream outage. That is the entire argument for building guardrails before you build capability — and it is why we tell clients that the interesting engineering in agent systems lives in the plumbing, not the prompt.

The delivery-channel class is the one worth internalising: eight jobs did their work correctly and then dropped it on the floor because the last mile was not wired. An agent that completes successfully and delivers nowhere looks healthy in every metric that matters to the model and is completely useless to the business.

What this case study does not prove

We would rather state the limits than let you infer something we cannot support:

• It does not prove cost efficiency. Our host carries no per-task cost ledger. We are not going to publish a dollar-per-agent-day figure we did not measure.
• It does not prove business outcomes. Session counts and uptime are evidence of a system running, not of revenue earned. Those are different claims.
• It does not prove this is the right architecture for you. Nineteen agents is the right answer for an agency that produces research, content, and pipeline. It is the wrong answer for a single well-scoped workflow, where one agent with memory will beat this every time.
• It is not a client system. It is ours. Client engagements are under NDA and are not published without written permission.

What we would carry into your build

The transferable parts are not the agent count. They are the four structural decisions: separate the agent that builds from the agent that verifies; put a hard approval gate in front of the build step; give something the job of auditing the fleet with no power to act on it; and wire the last mile before you celebrate a green run.

None of that requires nineteen agents. All of it applies to your first one.