Building an agent cold: why every stage of our new endpoint agent shipped inert

An endpoint agent is the highest-trust software an MSP installs. It runs as the most privileged account on the machine, on every machine, at every client. If it is wrong, it is wrong everywhere at once, and the thing you would normally use to fix it is the thing that is broken.

So when we rebuilt ours as a native Windows service, we did it in a way that looks strange in a commit log: stage after stage landed disarmed. Identity and key custody merged before anything could sign. Durable local state merged before anything wrote to it. Transport and health adapters merged unable to transmit. Script supervision merged with nothing permitted to run. Each piece arrived in the codebase inert, was reviewed and tested in that state, and only then was switched on.

Why not just build it and turn it on

Because "build it and turn it on" collapses two very different questions into one moment. Does this code do what it claims? And should this code be permitted to act? When those get answered simultaneously — at merge, under deadline — the second question tends to get answered by the first one's momentum.

Separating them buys something specific: at every point during the week, the answer to "what can this agent currently do on a real machine?" was a short, deliberate list rather than an inference from the diff. Nobody had to reason about whether a half-finished component was reachable, because reachability was its own switch, flipped on its own evidence.

Inert-by-default turns "is this safe yet?" from an argument into a lookup.

What it actually cost

It is slower. Composing a component that cannot yet run means writing the wiring twice in effect — once cold, once armed — and it means a stretch of days where the honest answer to "is the new agent working?" is "it is not doing anything yet, on purpose." That is an uncomfortable status to report and an easy one to shortcut.

It also produces a genuinely odd artifact: a fully-assembled agent that is deliberately useless. If you are not disciplined about finishing, that is a very expensive shelf ornament.

Where it actually is

Honest status, because this is the part vendors usually blur: the new agent runs as a real Windows service under the Service Control Manager as LocalSystem, with crash-safe execution state, service recovery, native hardware and Windows inventory, bounded diagnostics, and a transactional updater. It has survived a forced child crash, a custom restart, and a full service-manager restart with its identity and state intact. Its first server-acknowledged installer cutover ran on a single lab endpoint.

That is a lab-validated candidate. It is not a fleet rollout. Exact-commit rebuild, code signing, reboot and update and rollback acceptance, and broader validation are all still ahead of it, and our existing agent remains what runs in production. We would rather write that sentence than the one where a lab success gets described as a launch.