Context

Every piece of infrastructure work described on this shelf could, in principle, be typed by hand: log into a machine, run the command, write the file. Instead, most of it runs through a small "virtual team" of specialized AI agents. This page is about why that trade is worth making — and where it stops being worth it.

What delegating to a scoped agent actually buys

• A precise, written brief instead of a running mental list. Handing a task to a subagent means writing down, explicitly, what it's allowed to touch and what "done" looks like — a discipline that's easy to skip when you're just typing commands yourself, and that pays for itself the moment you come back to a chantier a week later and need to remember why a decision was made.
• Isolation by default. A subagent only sees the scoped brief it was given, not the full history of everything else happening in a session. That's not just tidiness — it means a task about, say, network segmentation can't accidentally leak unrelated context (like an internal credential mentioned three tasks earlier) into work it has no business seeing.
• Real parallelism. Several scoped, independent pieces of work — say, a network change and a documentation update — can genuinely run at the same time, each with its own narrow context, instead of one person context-switching between them serially.
• Documentation as a side effect, not an afterthought. A dedicated agent whose only job is tracking and writing things down means every finished chantier leaves behind a record — not because I remembered to write it, but because writing it down is that agent's entire job.
• Guardrails that are explicit, not just remembered. A rule like "never touch a real system belonging to my employer" is written into the agents' shared instructions, checked every time, rather than relying on me remembering it under pressure at eleven at night.

Where it doesn't help — and can actively slow things down

• Trivial, one-off tasks. Writing a scoped brief for a two-line config change takes longer than just making the change. Delegation earns its overhead on anything non-trivial, multi-step, or worth documenting — not on everything.
• Judgment calls with real consequences. No agent in this setup decides, on its own, to expose a new service to the internet, delete production-adjacent data, or grant an access level it wasn't explicitly asked to grant. Several of the write-ups on this shelf exist specifically because an agent stopped and asked, rather than guessing — a bug that would have locked every admin out, a discordant DNS record it refused to silently resolve one way or the other. That's the system working as intended, not a limitation to route around.
• Context an agent genuinely doesn't have. A subagent only knows what's in its brief. If the brief itself is wrong or incomplete, the agent will faithfully execute the wrong thing — the same failure mode as delegating to a very literal-minded junior colleague. The fix is the same in both cases: a better brief, not more trust.

The honest summary

This isn't automation replacing judgment — it's judgment applied once, at the point where a task gets scoped and handed off, instead of being re-applied by hand at every single step after that. The interesting failures documented elsewhere on this shelf are mostly moments where that scoping was incomplete, not moments where an agent "went rogue" — which says something about where the real risk actually lives.