How it works · Step 3 of 4
For whoever picks the tools
Act: on the host that raised the event, inside the set your team approved
The agent that noticed the problem is the one that fixes it. No runner tier, no bastion, no automation platform to stand up first.
Where it runs
For whoever picks the tools
The fix happens where the problem lives.
One Agent sits on the host — a single service, light on system resources. It collects, and it runs. When an approved action is called for, it runs right there. Not from a console, not through a cloud provider API, not through a connection built for someone else’s job.
This is an architectural position, not a feature, so it stays true when someone else ships an integration. Between noticing and acting there are zero layers. The full connection — one outbound TCP, no inbound, credentials that stay on the host →
Nothing to assemble first
No automation platform, no job templates, no separate inventory to keep matching reality. If the Agent is installed, the host is actionable.
Any connected environment
Cloud VMs, bare metal, on-prem, hybrid. The Agent is the whole footprint, and it behaves the same everywhere. Kubernetes is on the roadmap, not in launch scope.
What it may run
For the engineer who has to approve it
A set your team approved, on hosts you assigned.
An ActionBook — commands your engineer named, in an order AI wrote, approved by your team — does not compose commands at runtime. It calls Builtin Functions only from its registered catalog: service and process control, package state, file and mount operations, host firewall rules, diagnostic dumps. The language has no shell escape and no function definitions of its own. The list of Builtin Functions an ActionBook calls is the exact extent of what it can touch. Your team can read that list before it ever runs — which “a script” never offers.
Bound to targets
Actions run only on the hosts you assigned them to. The same action can run on its own on staging and wait for approval on production — two entries, approved separately.
Reversible by design
The actions in the library can be undone. Anything that destroys state permanently is not something Virca puts on an automatic path — it comes to your team.
Nothing fits → it tells your team
If no approved action covers it, the pass stops and tells your team what it found — target host and reasoning attached, so the call is yours with the facts already in hand.
Every run attributed
Recorded with what triggered it, what ran, and what happened next.
a request from AI
your own client, or Virca's — graded before it is sent, and the grade is declared on the function itself
it runs
nothing waits on a person
it waits for a tap
from your team
it is refused
no approval opens it
And when the request comes from AI, it is graded before anything is sent. An action the catalog marks normal runs, and nothing waits on a person. One marked warning waits for a tap from your team. One that cannot be undone is refused on that path outright — no approval opens it. Nobody can switch the grade off for a busy night: it is declared on the function itself, and an ActionBook inherits the highest grade it contains, so the same rule holds whether the request came from your own AI client or from Virca’s.
Approved once means approved — not unsupervised. Your team approves in daylight, with the commands and hosts on screen. Outside that line, at runtime, it still stops and asks. How the boundary works →
What this is not
For the person carrying the pager