A Fleet, Not an Assistant
The moment agents stop waiting to be asked, your job stops being prompting and becomes management.
By the time I sit down with coffee, the reports are in. Overnight an agent ran a prospecting pass: it scanned public funding databases for research groups whose work fits what my company sells, read up on the promising ones, and left a brief on each: who they are, why they fit, and a draft first email I can send in about a minute. Another one reconciled our internal task files against the dashboard my cofounder works from and settled the discrepancies it could justify, leaving the judgment calls for me. This morning a third reviewed the system itself and filed three improvement proposals. On Saturday another will look at the whole business the way a sharp fractional executive would, and tell me what it thinks matters most next week.
I did not ask for any of this. Not last night, anyway. Nobody typed a prompt at three in the morning.
There is a version of working with AI that everyone can picture by now: a chat window, a request, a response, a refinement. Nearly every mental model we have for these tools assumes that shape, one person driving one assistant, the human always the one who starts. The first time an agent does useful work you did not ask for, that shape breaks. It took me a while to name what replaced it. I had stopped being a user. I had become a manager.
A fleet, not an assistant
Two kinds of agents run my operation.
The first kind I work with directly, side by side in a terminal, on whatever is novel or hard that day: a tricky analysis, a pricing decision, a document that has to be right. This is the kind almost everything gets written about. The recent wave of markdown-and-agents systems (Andrej Karpathy’s LLM wiki, Nicolas Bustamante’s personal-admin stack) lives here too. Capable, increasingly reliable, and fundamentally reactive. It waits to be asked.
The second kind I never open a window for. They run on their own schedule, on my behalf, and I find out what they did after the fact. The overnight prospector is one. Another keeps two systems honest: it reconciles the task files my agents work from against the dashboard my cofounder uses, resolving what it can defend and escalating what it can’t. One keeps the repository tidy, committing and pushing finished work when it is safe to do so. Two more are reviewers on a standing schedule: one audits the system itself every Wednesday and proposes improvements; the other reviews the business every Saturday like an outside advisor. The roster keeps growing, and the pattern is set: agents that do the work and report back, not agents that wait to be asked.
Here is the part worth being precise about: the difference between the two kinds is not capability. It is often literally the same model reading the same files. The difference is initiative, who decides when the work happens. An assistant becomes a fleet the moment that decision moves from you to a schedule. And that moment, not any jump in model quality, is where the operating problem changes character.
The math that forces the inbox
A fleet has arithmetic an assistant does not.
One assistant interrupts you on your own cadence, because you are the one summoning it. Autonomous agents, left to their own devices, each report on their schedule: a ping here, a message there, something finishing at four in the morning. With five of them you are not managing a fleet; you are being managed by one. Your day becomes N open loops, each demanding that you stay in it.
In an earlier essay I argued that with a single model the operator’s scarce resource is evaluation bandwidth: generation is nearly free, judgment is not. A fleet makes that asymmetry brutal. It multiplies the production side by N and does nothing at all for the judging side. If the fleet’s output arrives as interruptions, your attention gets spent on the fleet’s schedule, which is to say, wasted.
The fix is not clever, which is exactly why I trust it. It is the structure every manager of people eventually arrives at: reports flow to one place, and the manager reads them on the manager’s schedule. Every autonomous agent in my system writes its results to one inbox: the brief, the artifact it produced, the decision it wants made, flagged clearly when it acted on its own authority. I clear that inbox on my schedule, usually in a few minutes over coffee. The agents stay busy, and I stay in the loop without being in every loop.
That sentence is the whole trick of running a fleet as one person.
At the center of the picture is a file tree: plain text, under version control, the source of truth for the business and, honestly, for most of my life. Everything else is agents acting on it. Some are the ones I drive; more of them, every month, are not. Around the core sit the things the work touches: the dashboard the company runs on, email, code, customers. None of the pieces are exotic. What is unusual is only that it is one system, a fleet on a shared substrate, addressable and auditable end to end, instead of a drawer of disconnected bots.
Reports are claims, not evidence
The inbox solves attention. It immediately creates the second management problem: everything in it is a claim.
“Done” is a claim. A tidy summary is a claim. And an agent grading its own work is a junior employee marking their own homework. Most of what makes a fleet safe to depend on is the structure you build around this one fact.
Three pieces do most of the work. First, gates: autonomous agents draft but do not send, propose but do not spend. Anything irreversible or outward-facing stops at the inbox and waits for a yes. Second, rules that accumulate: every correction I make becomes a written rule that the next run inherits, so the system learns in writing and mistakes become policy instead of memories. Third, verification as a habit: when a report matters, I check the artifact, not the summary. Open the file. Run the check. Recompute the number. I wrote a whole piece about agents producing beautifully wrong work when nothing constrains them; the reporting layer of a fleet is where that discipline either exists or does not.
None of this is exotic either. It is what any manager does with a new hire until trust is earned. The difference is that the fleet never stops being new: every run starts fresh, so the trust has to live in the structure, not in the relationship.
The cadence that stops the rot
Gates and verification are reactive. They catch problems in the moment, at the point of action. A system that runs real things needs something proactive too: a standing rhythm that pulls the whole fleet back into alignment before it drifts, rather than after.
Mine is a weekly review. Every Saturday an agent walks the same loop: last week’s record, the open projects, the inbox, the goals, and compiles one honest list of what matters next. It is the least glamorous part of the system, and it is the single thing that keeps something this size from quietly rotting. Some of the fleet exists to review the fleet: the Wednesday agent’s entire job is to look at the machinery, the rules, the tooling, the recurring friction, and propose what to fix.
A knowledge base can afford to drift; the worst case is a stale note. A fleet acting on your behalf cannot. Its worst case is work you did not want, done confidently, at scale.
The frontier is management, not models
The models were never the hard part of this. They have been good enough for most of what I have described for a while now. The gap between a demo and something you depend on is management structure: a reporting surface, gates, written rules, verification habits, a cadence. Not one of those is an AI invention. Every one of them is a management invention, older than software.
I think that is the genuinely useful news for anyone running a real business and wondering what this technology means for them. The skills a fleet rewards are not engineering skills, though engineering helps. They are operator skills: deciding what gets delegated, reading reports skeptically, turning corrections into standing rules, holding a rhythm. If you have ever managed people, you already know the shape of the work. The employees are just stranger now, tireless, fast, occasionally and confidently wrong.
What you get on the other side is not a smarter assistant. It is a kind of leverage one person has never really had before: work that happens while you sleep, run by a system you can read, audit, and own. Crossing over does not feel like magic. It feels like writing careful rules, watching the system fail in small ways, and fixing it one correction at a time until you trust it with something real. For an operator, that trade is the whole game.