How a one-person company runs on an agent fleet

One person runs this company. The staff is a fleet of agents across a small rack of servers in a back room: one strong model that plans and reviews, cheaper models that execute bounded work, and a layer of scripts that watch reality. The founder's job has narrowed, over time, to judgement.

Day to day, almost nothing is done by hand. Drafting, coding, deploying, invoicing, monitoring, content updates, internal research, even much of the sales correspondence: each goes through an agent, gets reviewed by another agent, and only then lands in front of a human. The human's job is the parts the agents can't do well. Deciding what to build. Saying no to clients. Taking blame when something goes wrong. Signing things.

This piece is about the operating system underneath that arrangement. Not the tools, not the latest model release, not the clever prompts. The discipline of running a small operation through agents without it collapsing, and the one move that made the discipline possible in the first place.

The deletion that made it work

The setup used to be the opposite of lean. Fifty-two instruction files. Fourteen role definitions. A thick rulebook covering tone, format, escalation, sub-tasks, tool selection, error handling, response length, and several other concerns I can't now reconstruct. Almost all of it got deleted. What survived is one page of hard rules and a handful of reusable skills. The cut was the move that mattered.

The reason is counterintuitive but consistent. Detailed process instructions were written, originally, to compensate for weaker models. They are scaffolding for a model that cannot generalise: tell it the steps and it follows them. A stronger model does not need the steps. It needs facts, goals, tools and feedback, and it will use judgement. Cluttering the stronger model with steps designed for the weaker one drags it back down to following the steps and producing the mediocre output the steps were meant to prevent.

This is the move that actually moved the needle on throughput. Not a better model. Not a fancier tool. Cutting the rules and trusting the model with judgement, then bounding the judgement with reality checks rather than process audits.

Watching reality, not process

Twice a day, scripts probe the live sites, the backups, the storage mounts, and the live integrations. If anything drifts, a message lands on the founder's phone. Nothing in that loop checks whether the agents followed a process. Everything in that loop checks whether the world is in the right state.

That distinction matters. A process audit says the agent did step three in the right order, and it feels reassuring, but it doesn't tell you whether the customer's site is up. A state check says the customer's site is up, the backup ran, the storage mount is healthy, the scheduled job fired. That is the question that actually matters. The first kind of check optimises for the appearance of control. The second kind optimises for control.

When something fails, the failure surfaces fast and with the actual evidence. Not "the agent reported success" but "the agent reported success and the response code was 502". That is the feedback loop a small operation needs, and it is cheaper to build than people assume.

The vendor problem

Any model can vanish. A price change. A policy change. An outage. A lab that decides its best customers are no longer its best customers. Every founder who has been in this game longer than two years has watched a model they relied on quietly become unusable, and most of them were caught flat-footed when it happened. The insurance against any one of those outcomes is small and unglamorous: a profile file per alternative model, a one-command switch script, and a two-tier context system that changes the rules around the model, not just the model itself.

Frontier models get a two-line note in their context: use judgement, no process constraints, just produce the right answer. Lesser models get mandatory scaffolding: plan first, prove done with pasted output, stay inside the task's boundary. The same work order can go to either tier; the wrapper around the model is what changes. The model itself is the smallest part of the wrapper.

Two small artefacts carry most of the value of the whole arrangement.

# Model tier: frontier
No process constraints. Use judgment.

./switch-model.sh backup     # swap the model, the context tier, and the keys in one move
./switch-model.sh frontier   # put everything back

That switch script is the difference between a 48 hour incident and a ten minute one. When the strong model goes away, the system does not stop. It falls back, the work continues at lower quality, and the founder gets a note about which work needs re-review once the strong model is back. There is no magic in it, and that is the point.

Two seats, not one

The seat split is simple and hard to fake. The best available model writes the plan and verifies the result. Cheaper models execute bounded work orders that must paste evidence for every step. Nothing merges unreviewed. Nothing reaches a client without a reviewer pass.

A model that plans needs to hold the whole problem in its head, weigh trade-offs, write a brief specific enough that another model can execute it, and spot its own blind spots before the work goes out the door. A model that executes needs to be cheap, fast, disciplined enough to stop at the boundary of its competence, and honest enough to paste the evidence that proves the step actually worked rather than the step that the model hoped would work. Those are different skills. Pretending one tier can do both well at the same price is how small operations burn through time and budget without anything to show for it.

This post is itself an example of the split working. The plan was written by the strong model, fact-checked, and handed to a cheaper executor as a work order. The cheaper executor drafted this body, paste by paste, from that spec. The strong model reviewed the result. If you are reading this, the system produced it. That is the system working as designed.

The honest ending

What does not transfer is judgement. When the strong model is unavailable, the human becomes the verifier of last resort, and throughput on anything non-mechanical drops to a crawl. That is the price. The honest version of this operating system designs for that drop, instead of pretending it does not happen.

The temptation in any small operation is to over-automate. To claim a model can do judgement when it cannot. To hide the fallback path so the founder does not have to explain it. Both moves feel productive and both cost more than they save. The honest version is: agents handle the parts that can be verified by checking reality. The human handles the parts that cannot. The boundary moves slowly, not because the agents are not improving, but because judgement is the part that does not transfer cleanly, and pretending otherwise is how small companies get caught out at the worst possible moment.

This operational discipline is what Alvento builds for clients. Not magic. Not full autonomy. A system that knows what it does not know, with a founder who still has the time to make the calls that matter. If that sounds like the system your operation is missing, start with a diagnostic at alvento.ltd, or email hello@alvento.ltd. The first conversation is free.