How it works

For whoever picks the tools

The shape every tool already has — and the step that changed hands

Watch, raise an event, act. The same Agent does all three, on the host where it happened. The first two were solved a decade ago. The third has always been a person getting woken — and that is the one that changes hands.

The shape

For whoever picks the tools

Three steps. Two of them are a solved problem.

Whatever you run today — a commercial platform, an OSS stack, a handful of scripts — has the same three steps. Something observes: metrics, logs, checks, traces. A rule crosses and an event is raised. Then something has to act. Fifteen years went into making the first two excellent — nobody has trouble being told. The third step is where the shape stops.

Same shape, a different occupant in the last box. What changed in step one → And in step two →

1Today — your stack, then a person

observe

metrics, logs, checks

event

a rule crosses

a person

wakes up, types the fix again

escalates — everything past this point is a person

2With Virca — the same agent, on the host

observe

what the action needs

event

binds an ActionBook

the same agent

runs what your team approved

same service — no step crosses out

The difference is where the line falls. Today it falls between the event and the fix, and everything past it is a person at 2am. With Virca all three steps sit inside the same agent on the host that raised the event, so no step has to cross to a person.

Why it stayed human

For the engineer who has to approve it

Three reasons the third step never got automated.

  1. 1

    It needs judgment about your environment

    Restarting a service is trivial. Knowing that this one sits behind a load balancer and has to be drained first, that that process must never be killed because it holds the write lock — none of that is in a metric. Your engineer knows it.

  2. 2

    Running it carries risk, and risk needs a line

    Reading telemetry is safe, so tools got very good at reading. Once software can change a production host, someone has to agree in advance to exactly what it may change. Without that agreement, the honest move is to page a human.

  3. 3

    It was never written down anywhere

    Infrastructure code has a vast public corpus, which is why AI writes it well. What an engineer types into a terminal at 3am was never published anywhere. It exists only in people.

What “action” means here

For the person carrying the pager

An action isn’t a command. It’s four things.

This is the part most easily misread. Automating the third step does not mean firing a command when a threshold trips — that is a cron job with extra steps, and it is dangerous. An action is the whole pass a person runs at 2am, and it is not finished until the last step.

  1. 1Validate

    Is it real?

    A threshold crossing is not a problem yet. Most pages are noise, and they close here.

    How noise closes →
  2. 2Investigate

    What the alert left out

    The facts around the event, gathered on the host while it is still happening.

    What gets gathered →
  3. 3Act

    The approved action

    On the host that raised it, inside the set your team signed. Only when one fits.

    What it may run →
  4. 4Confirm

    Did it hold?

    It re-checks its own target, and calls the reverse steps its author wrote if not.

    What we don’t claim →

“Get the service back on its feet. Then find out why.”

Not every event reaches step three. Plenty close at Validate as noise. Plenty close at Investigate, with the findings waiting for your team in the morning. That is most of on-call, and it is the part that no longer wakes anybody.