Virca isAgenticOps
noun
AI agents that take the action — not just the analysis. AgenticOps brings AI agents into IT operations — not just to analyze problems, but to investigate, act, and verify outcomes.
Your engineer knows it. AI writes it. Your team approves it. The agent takes the night.
What AgenticOps means
Four beats, and which two are yours
- Your engineer
Knows it.
The fix for the thing that pages you tonight is not missing. Your engineer knows what has to happen and which commands do it — that part was never the gap.
- AI
Writes it.
AI takes those commands and writes when they run and in what order — the checks before, the order between, what happens when a step fails.
- Your team
Approves it.
Your team reads the draft back — the commands, the order, the hosts it may touch — and signs it. Nothing is live until they do.
- The Agent
Takes the night.
On the host that raised the event, at whatever hour it happens. It runs what your team signed, and it stops at the edge of it.
Two of the four are human, and they are the two where anything is decided. The other two are the writing and the running — and the vocabulary underneath is human as well: an action can only call functions someone on your team installed, and the ones that carry risk do not run without an approval, no matter what asked for them.
The agent is one thing — the service your team talks to, and the process on the host where the event fired. The thing that notices and the thing that acts were never two systems here.
humansoftware
AgenticOps at 2:14am
Nobody is woken for this.
The fix for tonight's page already exists — it is in someone's head, and it has never had a way to run without them. This is that way.
That doesn't mean nobody decided — the deciding happened in daylight, on a screen showing the exact commands and the exact hosts, and the actions that carry real risk still ask before they run.
One service on the host. The agent that raises the event is the agent that runs the fix.
- 01Validatestill above threshold after 60sreal
- 02Investigatejava pid 4121 · memory climbingfindings
- 03Actservice_restart · approved setran
- 04Confirm/health 200 · memory back downheld
Memory leak on app-server-02. Service process restarted, confirmed answering again. No one woke up.
Illustrative example
First · Nights and weekends
For whoever owns the rotation
It starts with the hours nobody wants.
A memory leak at 2:14am Tuesday and the same leak at 11pm Friday are the same incident. The only difference is how long it sits before a person sees it — and that difference is the whole cost.
Events tonight
1Nights
Most events close before anyone is called
Noise closes at the first step. Events with no approved action close with the findings waiting for the morning.
nobody was paged for any of it
Fri 11pm → Mon 8am
2Weekends
A weekend is just a longer night
Friday 11pm to Monday 8am, the same approved actions are on duty — and your team reads what happened when it is actually morning.
the same actions, three days longer
To your team chat
Nothing approved fits — handing this to your team.
- checks already run
- facts already gathered
I'll take itOpen findings
3Escalation
When it can't, it stops early and says so
Nothing approved fits, so it goes to your team — checks already run, facts already gathered, one tap to answer.
an escalation, not a page
Not every event ends in an action, and that is the point. The ones that do are the ones your team has answered a hundred times.
What it changes
For the team, and for whoever funds it
Two clocks run between the alert and the fix.
One of them is your engineer's — woken, reasoning it out, typing it again. The other is the service's, still broken for every minute that takes. Neither one shows up on an invoice, and both of them run every time it happens.
- hour, spent once, in daylight
- The engineer's clock runs while the action is written and approved, with everyone awake — not again at 2am.
- minutes spent waiting for a person
- An approved action starts when the event fires. The service is not still broken while someone finds their laptop.
- steps, then a record
- Validate, investigate, act, confirm — and every run on the record, including the ones it was not permitted to take.
1
0
4
On-call is the part of this job people leave over. This is the part of it that never needed a person.
How it works
Four steps, one pass, on the host that raised it.
Most events stop at the first step. That is the pass deciding nobody needs to know. The ones that keep going carry what the earlier steps found with them, so the action runs against facts gathered seconds ago rather than a threshold that fired.
- 02:14:07 event memory above threshold
- 02:14:07 validate re-read memory on host
- 02:15:07 validate still above after 60s
- 02:15:07 ✓ real — continue
Most events end here. A spike that settles on its own closes on this card, and nobody hears about it.
- 02:15:08 investigate top processes by memory
- java pid 4121 · climbing since 23:40
- 02:15:09 investigate service status · recent restarts
- no restart in 9 days · no deploy since
- 02:15:09 ✓ findings attached — kept for the morning
Findings, even when nothing runs. If no approved action fits, this is what your team reads in the morning.
- 02:15:10 act event → approved ActionBook
- service_restart · target app-server-02
- ✓ inside the set your team signed
- 02:15:14 act service restarted
No fit, no action. Anything outside the approved set stops and goes to your team.
- 02:15:44 confirm GET /health → 200
- 02:15:44 confirm memory back down
- 02:15:45 ✓ held — posted to #on-call
- if not: the reverse steps its author wrote are called
The pass closes itself, either way. Every run lands on the record.
Illustrative example. All four, or it isn't an action.
On the host
For whoever counts the moving parts
Your team's part happens once. The agent's happens every night.
In daylight, once
- 1
Your engineer names the commands
The ones that fix it — and the ones that must never run here.
- 2
AI writes when they run, and in what order
The checks before, the order between, what happens if a step fails.
- 3
Your team reads it back and approves it
Exact commands, exact hosts, on screen. Nothing is live until they sign.
An approved ActionBookregistered to the event that triggers it
At 2:14am, every time
Your host
the service that broke
the event, raised right here
the fix, run right here
Virca Agent
one service — it sees it, and it runs it
Posted to your channel, already closed
AI wrote the book. Your team approved it. All four then run in the agent, on the machine that raised the event — calling only functions your team installed, inside the set they signed.
Start here
Six things worth knowing. One page each.
The argument, the mechanism and the caveats — one page each, so this one stays short.
1The problem
The 2am tax
What the night costs, and who it keeps landing on.
2Why now
Your telemetry has a new reader
Monitoring asked is it alive? Observability asked why did it break? AgenticOps asks what to do about it — and then does it.
3What it fixes
Ten real nights, and where each one stopped
It fixes it, asks first, or just flags it.
4How it works
Validate, investigate, act, confirm
One pass, and why the third step stayed human until now.
5Is it safe
The boundary and the record
The catalog a person installs, the approvals that still fire at run time, and every run recorded — including what the agent was not permitted to take.
6Versus what you have
Six things to set up, not twenty-five
Who wrote the action, whose data it runs on, how much sits in between.
Tonight's page is one your team has answered before.
Write it down once, approve it in daylight, and let the agent take the night. We are also taking a small number of design partners — our engineers in the room for your first ActionBooks, and a direct line for everything you find wrong. ask@virca.ai
Be a design partner — ask@virca.ai