How it works

For the person who owns the headcount

How an ActionBook gets built

Your engineer knows it. AI writes it. Your team approves it. The agent takes the night. This page covers the first three.

The premise

For the person who owns the headcount

We are not selling you the knowledge. We are selling a way to run it.

Virca does not arrive claiming to understand your fleet. Your engineer already does. They keep getting woken up, reasoning it out again, typing it again — and because nothing is captured, the next incident costs exactly what the last one did.

So the action is set up once, in daylight. Your engineer names the commands that fix it. AI writes when they run and in what order. Your team reads it back and approves it — and from then on the agent runs it, at whatever hour. Configuration management builds the car; Virca is cruise control — you set the direction and it holds it, and you take the wheel whenever you want.

Three passes

For the engineer who has to approve it

Named, written, approved once.

  1. 1

    Your engineer names the commands

    The fix for tonight's page is not missing. It is in someone's head, and it has never had a way to run without them. Here it leaves that head — which commands fix it, and which must never run on this host. Nobody is asked to write automation.

  2. 2

    AI writes when they run, and in what order

    The checks before, the order between, what happens when a step fails — written against what is actually on the machine. What is installed, what is running, how the service is managed, what the last few events on this host looked like. Drain this one before restarting it. Check the replica before the primary. This mount filling is normal on Tuesdays; that one is an incident.

    It is also the fastest part. Arranging commands that already name the real hostnames is a different job from writing automation from an empty file.

    What we are trying to build is narrow enough to say out loud: the writing gets easier, the approving stays. Whatever AI ends up doing here, the boundary your team draws and the record they read afterwards are the two things it does not get to trade away.

  3. 3

    Your team approves it, in daylight

    The exact commands, the exact hosts, and what happens if the check fails — all on screen, read back by someone who can say yes, at a reasonable hour. Nothing is live until they sign it, and the functions that carry real risk still ask again at the moment they run.

Library ActionBooks ship disarmed. An action becomes runnable when someone deliberately arms it, not as a side effect of installing anything.

Where you do it

In your own AI client, or in Virca.

Virca exposes an MCP server, and that is the recommended way to work: your team builds and adjusts ActionBooks, tunes event rules and looks up history from the AI client they already have open. The same agent is reachable inside Virca too — for 2am on a phone, or for whoever doesn’t live in a terminal. Two places, same agent, one boundary — and on the AI path that boundary is graded, so a state-changing action waits for one tap and an irreversible one is refused outright.

Work on it from the client you already have open →

What to expect

For whoever owns the on-call rotation

What this costs you in time.