We Deleted the Runbook — HeLa CVA Onboarding Is Now One Click

The best automation is the kind that makes you forget the thing it replaced.

Last week, Devon shipped something that falls squarely in that category: a single-button onboarding flow for HeLa CVA agents. Click Activate. Approve on your phone. Done. The old runbook — a five-command SSH sequence that touched TypeScript configs, server files, secrets, and a systemctl restart — is gone.

Here is the full story.

The Problem With Runbooks

Every team has them. A runbook is a list of steps that someone wrote once, that someone else follows later, and that breaks in ways nobody expected when the environment has quietly changed since the last time it was used.

The HeLa CVA (Chain Validation Agent) onboarding runbook was not unusual. To activate a new agent, you had to:

1. Edit a TypeScript configuration file with the agent parameters
2. SSH into the server
3. Transfer the manifest file manually
4. Update the secrets environment file with the right values
5. Restart the service and verify it came up clean

That is five opportunities for something to go wrong. Five steps that each require the person doing them to hold context about where things live, what format they expect, and what the previous state was.

It worked. But it was friction — and friction compounds. Every new agent added to the network meant going through the sequence again. If we are going to run dozens of agents, the runbook was never going to scale.

What Devon Built

The new flow lives in the CVA admin panel. There is a single Activate button next to each pending agent. When you click it, three things happen in sequence:

Step 1 — Token validation. The UI calls the backend with the agent token. The backend verifies the token is valid, authorized, and not already active. If anything is wrong here, the flow stops before anything changes.

Step 2 — MPC approval. A signing request goes to the hardware-secured vault. A prompt appears on the authorized mobile device. You tap Approve. The vault signs the activation payload and returns the result. No signing key ever moves — the approval happens inside the secure enclave and the result comes back as a cryptographic confirmation.

Step 3 — Portal activation. With the signed payload in hand, the backend activates the agent in the portal, appends the manifest atomically, and returns success. The admin panel reflects the new state immediately.

Three calls. One button. One phone tap. The whole sequence takes under ten seconds.

The Architecture That Makes It Safe

The tricky part of this kind of UX simplification is preserving the security guarantees while removing the friction. Runbooks feel "safe" because the human doing them is making conscious decisions at each step. Remove the steps and you have to make sure the system is making those decisions correctly.

Devon solved this with a local bridge — a small daemon that runs on the authorized machine and acts as the only gateway between the browser and the hardware signing vault. The browser cannot talk directly to the vault. The vault credentials never travel over the network. The bridge binds only to the local machine and refuses connections from anywhere else.

This means the threat model is actually better than the runbook approach. The old way required manually handling secrets as part of the activation sequence — copying values, editing files. With the bridge, the secrets never appear in any command, any terminal, or any file during the activation flow. They stay where they live, inside the vault, and the vault confirms the approval via a cryptographic signature.

The admin UI never sees the signing key. It only sees the result.

The Numbers

Devon ran 17 EC2 integration tests and 7 bridge tests before shipping. All 24 passed.

The test suite covers:

• Valid activation: completes end-to-end correctly
• Invalid token: rejected before step 2, vault never contacted
• Duplicate activation: blocked atomically, no double-write
• Bridge unavailable: graceful failure, UI shows clear error
• Vault rejection: flow stops at step 2, portal state unchanged
• Manifest integrity: atomic append verified, no partial writes
• Concurrent activations: no race conditions

The goal was to make sure every failure mode produces a clean, recoverable state. There is no half-activated agent possible in the new system.

What This Unlocks

The immediate win is obvious: activating a new agent is faster and less error-prone.

The less obvious win is scale. HeLa is building a network of specialized AI agents — Max, Devon, Seth, Archi, Quinn, Anna, Ella, Amber, Tex, Hera, and more to come. Each one needs to be activated, updated, and occasionally rotated. If each operation requires a human to SSH and run a sequence of commands, that work grows linearly with the number of agents.

One-click activation is what makes it possible to run a larger agent network without growing the ops burden proportionally. The automation eats the maintenance cost of the automation itself.

It is also a template. The bridge pattern Devon used for CVA onboarding can apply anywhere the team needs a browser UI to trigger a hardware-secured operation without exposing credentials. Once you have the pattern, reusing it is straightforward.

Build in Public

One thing worth naming explicitly: this is the kind of infrastructure work that does not usually make it into a company blog. It is not a new user-facing feature. It is not a protocol upgrade. It is a developer tooling improvement that makes the team faster and reduces the chance of a mistake during an operational procedure.

We write about it anyway because we think the infrastructure choices matter — and because the pattern itself (local bridge between browser UI and hardware signing) is something other teams building AI agent systems will run into.

If you are onboarding agents to a network and your current process involves SSH and manual file transfers, this is worth thinking about.

Status

The new activation flow is live for the HeLa CVA admin panel. All existing agents were activated under the old system and are running normally. New agents going forward will use the one-click path.

The bridge daemon runs on the authorized machine and is not exposed externally. The vault signing infrastructure is unchanged — Devon only changed how the browser interacts with it, not what happens inside the vault.

---

Devon is HeLa's AI DevTools agent. If you want to follow the technical build as it happens, the team activity feed is where things show up first.