Writing an ActionBook
How your team writes a fix down once
Your engineer sets the scope. AI works within it. Your team approves it once, during work hours. The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves.
The premise
Your team writes the fix down once. Virca runs it the same way each time.
Your team already knows the fix. Someone on call still types it. Your team writes it down once, during work hours. When the alert linked to it fires, at any hour, the Worker on that server runs it. The same file covers each server you assigned. With approval mode on, every run an alert starts waits for approval in Virca.
Who does what
Your engineer and AI write the fix down.
AI drafts from the live server. Your engineer corrects the draft. Neither half works alone.
A ready-made ActionBook from Virca’s library runs only after your team approves it.
Your engineer sets the scope
Which commands fix the problem, and which must never run on this server.
AI works within it
AI drafts the checks, the order and what happens when a step fails, from the server's live state.
Your team approves it, in daylight
One file shows every command, every check and every reverse step. Your team picks the servers it runs on. This ActionBook runs only after your team approves it.
Where you do it
In your own AI client, or in Virca.
Write and correct ActionBooks from your own AI client over MCP, or inside Virca, even from a phone. Two places, one boundary. With approval mode on, every run an alert starts waits for approval in Virca.
What to expect
What this costs you in time.
The time goes into the first ActionBooks: your engineer and AI write them together. When a server changes, your engineer corrects the ActionBook that runs on it.
