The questions people ask before they trust an AI with production

AgenticOps for the hosts you run — an agent that takes the night. Every monitoring tool observes and raises an event. Then a person acts — checks the alert is real, digs up what it left out, brings the service back, checks it held. Virca gives that last part a way to run without them.

The pass lives in an ActionBook: your engineer names the commands, AI writes when they run and in what order against live host state, and your team reads it back and signs it. From then on the agent runs it on the host that raised the event.

An ActionBook can only call Builtin Functions — commands from its registered catalog, each one type-checked and graded before it is ever called. Nothing else.

No. The selectivity starts before anything fires: alerts, ActionBooks and Builtin Functions go on the metrics that are real issues for your stack — not on everything the Agent can see.

Inside that set, an action is four steps, and it can stop at any of them.

Plenty of events validate as noise and close there — recorded with what was checked, and nobody is called. Plenty more are real but have no approved action, so your team gets the facts already gathered and makes the call. Neither ending changed anything on a host, and both are the design, not a shortfall.

The pass a senior engineer runs, written down: the checks that decide whether it is real, the read-only commands that gather context, the action, and the check that decides whether it held. The fix is one of four parts, not the whole of it.

It calls only Builtin Functions from its registered catalog — each a type-checked wrapper around one command, never raw shell. The language has no shell escape and no function definitions of its own. So the list of Builtin Functions an ActionBook calls is the exact extent of what it can touch, and a person can review that list in a way they never could a shell script.

It is not one rigid script forced through every case. Partway through, an ActionBook can chain to a more specific one for the same event — same host, still graded normal, warning or critical before it runs, still waiting for a tap if it needs one. The next ActionBook picks up where the first one stopped.

No. Keep your dashboards, your retention and your alerting where they are. Virca brings the data its own actions need, so there is nothing to assemble on our side — and nothing to migrate on yours.

Virca observes, raises the event and acts — all three, in the same Agent.

Yes, in one specific sense: an approved action runs without waking anyone. Every action runs inside a set your team approved in advance, and the approval happens before anything can run — in daylight, with the exact commands and target hosts on screen.

Approved once means approved — not unsupervised. Nobody is woken; that does not mean nobody decided. Anything outside the set still stops at runtime.

No new team, and no queue to staff. Your team approves once, when the action is written — the exact commands and target hosts on screen — and signs it.

After that, what is inside the boundary runs on its own. Anything outside it lands as a one-tap request in your team chat (Slack, Microsoft Teams) — where your team already works incidents, not a separate console. What grows with your fleet is the action set, not a function to run it.

It stops and tells your team — the host and the facts it already gathered attached, so whoever picks it up does not start cold.

That is a different ending from approval. An action that is approved but marked as needing a tap for that target arrives as a one-tap request, evidence attached. Both stop; one escalates, one asks.

The action re-checks its own target. If that check fails, it reverses the steps that have a defined reverse. The event stays open, and anything that could not be undone is named in the record.

The limit, plainly: Virca confirms the check the action’s author wrote. It does not yet measure the outcome — no before-and-after score, no efficacy history per action. If a vendor tells you their loop is closed end to end, ask what the criterion was, who wrote it, and where the number is stored.

Actions are bound to the targets you assign. The same action can run automatically on staging and be approval-only on production, because your team approved those as two separate entries. Every approval is recorded with the identity of whoever answered it.

Library actions also ship disarmed. Someone has to arm one deliberately — installing anything never does it.

No. Virca acts on the machine: services and processes, files and mounts, packages, host firewall rules, diagnostic dumps. It does not resize an autoscaling group, drain a load-balancer target, or move traffic between regions.

When an incident genuinely needs that, the honest ending is a stabilizing host-level action plus a recommendation escalated to a person — usually what your on-call would have done at 2am anyway.

It didn’t. It reads live host state at setup time rather than recalling a memorized runbook. Your engineer supplies what was only ever in their head — drain this one first, never touch that process, this mount filling is routine and that one is an incident — and AI writes when the commands run and in what order.

That conversation happens once, in daylight — not at 3am. Your team already knows the fix; Virca gives it a way to run.

No. Virca takes the toil: the 2am pages for known incident types, the alert triage, the remediation steps your team has typed a hundred times.

It does not take the judgment work SREs actually want — designing for reliability, improving architecture, writing the ActionBooks for new failure modes, running post-mortems, deciding what Virca may do. The teams using Virca well aren’t smaller. They get their nights back for the work that needs a human.

The general patterns — disk filling, service down, endpoint unresponsive, runaway process — need very little input. The ones specific to how your stack is put together need an engineer in the room for a first pass.

We would rather say that than promise five-minute onboarding and hand you an action set nobody trusts enough to arm. The work happens once per pattern, not once per incident — it pays back on the repeats, not the first one.

Yes. Virca exposes an MCP server, so your team can build and adjust ActionBooks, tune event rules and look up history from the AI client it already works in. Virca’s own conversation surface covers the phone, the team chat and the 2am path.

Both reach the same agent, inside the same approval boundary. On the AI path that boundary is graded — a read-only check runs, a state-changing one waits for one tap, and an irreversible action is refused outright.

One Agent per host — a single service, kept to a low system-resource load. It collects, and it executes. It opens a single outbound TCP connection to Virca and everything travels on that. Nothing listens for inbound traffic, and there is no VPN tunnel to stand up.

Credentials stay on your hosts. They are never held on our servers.

Nobody we can name yet. Assume the vendors who can name someone are further along on that one axis. Virca is new — you can create an account and install the Agent today — and a wall of logos you cannot verify would be worth less than this sentence.

So the offer runs the other way. We are taking a small number of design partners: your engineers build the first few ActionBooks for your fleet with ours in the room, arm them on your terms, and tell us where we are wrong. You get attention that stops being available once a company gets busy, and a say in the order things get built. We get a product shaped by a fleet we did not invent. ask@virca.ai — tell us what wakes your team up.

The architecture — one outbound connection, credentials that never leave your hosts, an approval boundary agreed before anything runs, and a record of what each execution did, including the actions that were proposed and not permitted.

Infrastructure and hosts: cloud VMs and bare metal. Integrations extend that to the checks around them — URL, Port and Process. Ask where a specific one stands if it matters to your decision.