34 agents, and what broke

The situation

I run my own business on an AI agent organization I built and operate myself. It is not a demo and not a diagram. I can open it on a call.

Measured on my own machine on September 3, 2026: 34 agents, and 56 n8n workflows of which 11 are switched on. There is also a live MCP server I shipped, which answered a request while this page was being written.

The count is not the interesting part. Anyone can generate 34 agent files in an afternoon. The interesting part is what it takes to stop 34 of them becoming 34 sources of confident, wrong answers.

What I built

One real copy of every agent, symlinked into place. All 34 live in one git tracked folder, and the runtime loads them through symlinks pointing back at it. There is exactly one copy of each agent’s instructions in existence, so nothing drifts and no agent quietly diverges from the version under review.

A three file standard, enforced by a checker rather than by discipline. Every agent gets its job description and its own private memory file, and shares a folder level file holding the machine facts: IDs, endpoints, known traps. The split exists because a database ID is identical for every agent in a folder, so copying it into each one guarantees that the day it changes, most copies start lying. A checker fails if an agent is missing any of the three, is installed as a copy instead of a symlink, or is not in git.

Credential separation, which is the safety design and not a detail. The agents that decide what to do hold no credentials. In the social team, exactly one agent can publish, and it publishes what it is given. The sales organization holds no sending ability at all. The thing with judgment is never the thing that can broadcast, which means there is one place to revoke if anything ever misbehaves.

What broke

On August 15, 2026, recursive status sweeps exhausted my Claude plan in a day. Agents asked other agents for status, which asked other agents for status. Nothing was malicious and no single file was obviously wrong. The tree had no depth limit.

The fix is written into the operating rules every agent inherits. Status and reporting mode does zero delegation: read the existing receipts, report what is missing as unverified, stop. At most two direct delegates per task, each with one bounded deliverable, never "as many as possible." Subagents are leaves, so they return work to their parent and cannot create another agent, and a hook enforces this rather than leaving it to memory. Counting, inventory and reconciliation are done by scripts, and a model reads the resulting snapshot only when asked.

The honest limitation

These agents are invoked. They are not always on, they do not watch anything, and they do not talk to each other in the background. Anything that runs unattended is a scheduled job or an n8n workflow, and there are far fewer of those than there are agents: of the 56 workflows, 11 are currently switched on.

That gets said plainly, because the alternative is letting someone believe they are buying an autonomous organization. Nobody is selling one, and the systems that run reliably are the ones whose limits are written down.

What I would not have done

I would not have given the agents credentials to make them more useful.

It is the obvious next step and it is available every single day. An agent that can send the email is more useful than one that drafts it. The reason not to is that judgment and reach are the two things that must never sit in the same process, because the failure mode is not a bad file, it is a bad file that already reached a customer.

The August 15 incident cost a day of account limits. The same design failure with sending credentials attached costs a reputation.