The Agent Fleet Operating Manual: How a Small Team Runs a Business on AI Agents Without Drowning in Them

You run a business on AI agents by treating every manual action as a temporary bug, automating it into an agent-and-app pair only when the cost of doing it by hand finally outweighs the overhead the agent adds — and then deleting that agent the moment it stops earning its place. The agents are not the asset. The operating discipline around them is. This piece documents that discipline: the rule that turns chores into automations, the two kinds of agent and when each one is correct, how to gate expensive intelligence behind cheap checks, and why deleting agents matters as much as building them.

Rule zero: every manual action is a bug you haven't fixed yet

The founding principle is brutal and simple: every time you do something by hand, the goal is to automate it. Not because manual work is beneath you, but because the plan is to scale. A step that is perfectly tolerable at ten customers a month is physically impossible at twenty thousand. If you are personally checking for strange processes, spam the model accidentally sent, or a new platform policy, that time does not exist at scale.

So the question is never 'is this manual step painful today?' It is 'does this manual step survive the next order of magnitude?' If the answer is no — and it almost always is — then the manual step is a bug. You may not fix it this week, but you log it as debt, not as the way things are.

The agent-and-app pair — the last resort, not the first

The unit of automation here is a pair: a specialist agent that holds the judgement, and an app that gives it a surface — a page to look at, scripts in the corner, a place the work lives. When something becomes critical enough, you build the pair. A channel getting suspended is exactly that kind of critical: severe, expensive, and recurring. That is when a dedicated agent is justified.

• The agent carries the expertise and the rules — what good looks like, what must never happen, how to decide.
• The app carries the state and the controls — the dashboard, the scripts that run the checks, the place a human can glance and understand.
• Together they make one capability you can point at, reason about, and improve as a single thing.

But building a pair is the last resort, not the reflex. Every agent you add has a cost: it dilutes attention, it is one more thing that can drift, and at the level of the system it weighs down the whole. You do not get smarter by adding agents. Past a point you get dumber. So the bar for a new pair is high — reserve it for the failures that are genuinely severe and genuinely repeating.

Two kinds of agent: the expert at your shoulder and the worker that never sleeps

There is a distinction that matters more than any other, and it is easy to miss because both things get called 'agents.' One kind supervises you while you work, on demand, inside a session. The other runs unattended, around the clock, through an API. They are good at opposite jobs and they cost wildly different amounts.

The practical rule: prefer the expert-on-call almost always, because it is near-free and the most intelligent option available. Build the always-on worker only for the processes that must keep running while no human is present. When you sit down to build a new automation, you call the relevant specialist to do the work and the risk specialist to check it — exactly like having two experts on retainer who you summon for the part of the job that is theirs.

How to build a top agent, not a quick one

Sometimes a strong agent needs nothing more than the model's own knowledge plus a tight set of rules. Sometimes it needs far more grounding than the model has, and the difference between an average agent and a top one is how much real-world data you fed it before writing a single rule. For a compliance specialist, for example, the right move is to spend twenty minutes running deep web-research sessions and pulling in as much current, specific data as possible — the kind of patient external research a coding session will not do on its own.

Monitoring is cheap heuristics first, expensive intelligence second

Once something is worth automating, the next thing to automate is watching it. The instinct to wire an AI judgement into every event is wrong — it is slow, costly, and overkill. Intelligence is the expensive layer. Spend it last.

1. Instrument the action with a dumb, deterministic check — counts, rates, timing. Five messages firing in under five seconds is a number, not a judgement call.
2. Let the cheap check run on every single event. It costs essentially nothing and it never sleeps.
3. Only when the deterministic check trips do you escalate to an AI agent for a real judgement: is this actually a problem, and what do we do about it?
4. Log every decision, so the next version of the check is sharper than this one.

Minimalism is the infrastructure

We have built around fifty internal apps. We have deleted roughly half of them. That is not waste — it is the method. Build fast, and delete just as fast. An app or an agent you keep out of habit is not neutral; it is surface area for entropy, one more thing to maintain, reason about, and accidentally trust.

If you are not deleting continuously, you are leaving room for entropy. Create fast, delete fast.— Operating principle

This is why deletion is not cleanup you schedule for later. It is part of the build. Every agent and app in the fleet should have to justify its continued existence, and the ones that cannot are removed on sight. A small, sharp fleet beats a large, vaguely-useful one — both for the humans reasoning about it and for the models operating inside it.

Keeping an agent sharp: never just append

The most common way an agent rots is the append. You are mid-task — building a site, say — and the agent does something wrong, like choosing ugly colours. The correct reflex is two-part: fix it on the spot, and make sure it never happens again by updating the agent. The failure mode is letting the assistant bolt another long paragraph onto the end of the agent's prompt. Do that twenty times and the agent is a junk drawer that no longer knows what it is for.

• Review every edit before it lands. Read what is actually being added to the instructions — do not just confirm that something was added.
• Stay concise and general. One clear rule beats five hyper-specific examples that only cover the exact case you just hit.
• Never blind-append. New guidance goes where it belongs in the structure, not reflexively at the bottom.
• Split by process when an agent gets long. Number the stages (R1, R2, R3) or draw an explicit pipeline so the model always knows which step it is on.

Order encodes priority. If an agent has ten rules for building a site, the first rule carries the most weight and is the least likely to be skipped — models tend to drop instructions from the middle and the end first. Put the rule you cannot afford to lose at the top.

And when in doubt, split. It is worth keeping an integration agent and a risk agent separate even when a single file could technically hold both, because every extra line of description raises the odds the agent loses the thread and quietly skips a step. Two sharp agents beat one bloated one.

The operating loop, in one paragraph

Do the work by hand once. Notice the manual step is a bug. If it is severe and recurring, build the agent-and-app pair — preferring the near-free expert-on-call over the always-on API worker. Ground the agent in real data before writing its rules. Wrap it in cheap deterministic checks that escalate to intelligence only when they trip. Keep its instructions concise, ordered by importance, and never blind-appended. And delete it the day it stops earning its place. That loop, run continuously, is what lets a tiny team operate a fleet that behaves like a much larger one.

Frequently Asked Questions

What is the difference between an in-session AI agent and an API agent?

An in-session agent is an expert you invoke inside a working session to supervise or review what you are building; it is near-free and the most intelligent option, so it is the default. An API agent runs continuously as an unattended service through the model API — useful for production processes that must keep going while no human is present, such as routing inbound customers overnight. Use the always-on API agent only when the job genuinely cannot wait for a session.

When should you create a new agent instead of writing a script?

Create an agent only when the task needs judgement a deterministic script cannot encode, and the cost of handling it by hand has started to outweigh the overhead the agent adds. A new agent is the last resort, not the first — it adds surface area and dilutes attention. Most monitoring should start as a cheap script that escalates to an agent only when a threshold trips.

How do you stop an AI agent's instructions from degrading over time?

Never blind-append. When you update an agent, read exactly what is being added, keep it concise and general rather than piling on case-specific examples, and place the most important rules first because models tend to drop instructions from the middle and end. When an agent grows long, split it by process or into separate specialist agents.

Why automate something you only do occasionally?

Because the plan is to scale. A manual step that is tolerable at ten customers a month is impossible at twenty thousand. Treat every manual action as a temporary bug: the question is not whether it hurts today but whether it survives the next order of magnitude.

Does adding more agents make the system smarter?

Not automatically. Past a point, more agents and longer instructions make the system worse — harder to reason about and likelier to skip steps. The teams that scale well on agents delete as aggressively as they create. Minimalism is the infrastructure.