My engineering team is a fleet of AI agents

Most days my engineering team is a fleet of AI agents. That's not a prediction or a pitch. It's a description of a normal Tuesday: a dozen agent sessions open at once across different projects, each one working a scoped task, me steering in short imperative lines and reading what comes back. I analyzed my own transcripts once - 92% of my prompts are commands, not questions, and the median prompt is 64 characters. I direct. They execute. I verify.

Getting to that day took less engineering than you'd think and more discipline than I expected. The models were the easy part. Everything that makes the fleet actually reliable came from one loop I keep running:

Measure a behavior. Write the rule. Then build the machinery that enforces it - because the rule alone does almost nothing.

Rules written in prose don't hold

Here's the measurement that taught me this. I had a rule asking agents to write a structured handoff at the end of every work session - what got done, what's still open, what the next session should pick up. The rule was written down in the instructions every agent loads. It was polite. It said "proactively offer" to close out the session.

I counted: 93 session starts, 2 handoffs written. About 2% follow-through.

Not because agents are careless. Because an instruction file is advisory context, not enforcement. The vendor documentation says as much, and the only published academic measurement I've seen of agents complying with repo-level instruction files found 6.5% compliance. My 2% is in the same neighborhood. So I stopped writing polite rules and started converting each rule into a hard rule with no wiggle room, and then - for the ones that matter - into a hook: a small program that runs at a fixed point in the agent's loop and either injects the fact at the exact moment it's needed or blocks the action outright. Prose shapes behavior. Hooks guarantee it. Those are different things, and mixing them up is how you end up trusting a rule that fires 2% of the time.

No claim without evidence

The single biggest trust-breaker with agents - measured across five months and about 23,000 of my own prompts - is the false "it's fixed." An agent says done, you move on, and the thing collapses on a real run. It happened enough that I made it a standing rule: never claim something is fixed without verification. Build it, run it, test it. If the change is live on a production URL, drive that URL in a real browser and confirm it's serving before saying done.

The deeper version of this rule is that self-assessment doesn't count. The agent that wrote the code is the worst possible reviewer of it - same blind spots, same assumptions, same context. So verification goes to something with fresh eyes: a separate review agent that never saw the reasoning, the actual test suite, the actual build, the actual browser. Verdicts come from harness signals, not from the agent's summary of itself. When an agent runs a task on my cluster of machines, the pass/fail check is a shell expression evaluated by the harness after the agent finishes - the agent's own "I completed the task" is advisory, and it's treated that way.

Fan out, but own your files

The speed of an agent team comes from parallelism. Non-trivial work gets decomposed into independent units and dispatched to several agents at once - a research question fanned out five ways comes back in roughly the wall-clock of one. The failure mode is just as concrete: two agents writing to the same file, where the last write wins silently.

I learned that the direct way. Early on, three agents working the same repo clobbered a build before it existed. The fix wasn't "be careful." The fix was structural: every parallel agent gets explicit, disjoint file ownership stated in its brief, and agents that are only supposed to report back get a hard anti-instruction - "do not write files, return the report as your final message" - because I watched the soft version get ignored and a report agent silently overwrite a document another agent owned. After the ownership protocol: zero collisions. Same loop as always. Observe the failure, write the rule, make the rule mechanical.

What fails, honestly

The clearest failure I've measured: agents walk away from work they opened. At one point I audited the open pull requests across my repos and found 36 of them, 16 in a state nobody could merge - conflicts, failing checks, unresolved review threads, the oldest untouched for 79 days. Every single one had been opened by an agent that then considered its job done. "I opened the PR" is not done. Mergeable is done.

The fix, again, had to become machinery. There's now a hook that records every PR an agent opens or pushes to during its session, and blocks the end of the agent's turn if one of those PRs is behind its base, conflicted, failing checks, or carrying unresolved reviews. The agent gets the exact fix list and has to work it before it's allowed to stop.

And the machinery itself fails, which is worth saying plainly. The PR guard once blocked an agent for a pull request that wasn't actually its responsibility - shared checkout, wrong attribution. The agent refused the hook, said why, and it was right. I fixed the guard, not the agent. Enforcement that can't be challenged with a reason is just a different way of being wrong.

There's a second limitation: very little of this is proven in the way I'd like. I can show you the before and after - 2% handoff compliance before the hook, near-total after; collisions before file ownership, none after - but these are my own workflows, measured by me, without controls. When I studied my own communication patterns with agents properly, with significance tests, a majority of my intuitions didn't survive. I assume the same would be true here if I tested harder. The discipline is real; the evidence for each individual piece of it is thinner than the confidence I carry it with.

What it adds up to

People ask whether managing agents feels like managing people. It doesn't, and I think that's the point. With people, you invest in judgment and trust. With agents, trust is the wrong tool entirely - what works is the loop. Measure the behavior you actually get. Write the rule. Build the hook. Keep the receipts, especially the unflattering ones. The agents get better models every few months and none of my machinery cares; it checks outcomes, not capabilities.

My team is a fleet of AI agents. What makes it a team is not that they're smart. It's that nothing they claim is taken on faith, nothing they're asked to do is left to prose, and everything that failed once is now a check that runs every time.