Virtana has introduced AI agent orchestration that puts agents from different vendors into the same incident war room. It announced Agentic Observability Enterprise Management, or AOEM, on October 28, 2026. Virtana calls it an orchestration layer. It brings agents together over MCP and the Agent2Agent protocol to work an IT incident from the first signal through to a verified fix.
Virtana says customer policies set which agents join, what they may do and when a human approves. It says customers can start with recommendations, move to approvals, and later allow autonomous fixes for incident classes they define.
Putting a team of agents on an incident is compelling, because the war room is a real problem and anyone who has sat on an incident bridge knows it all too well. Virtana’s chief product officer, Amitkumar Rathi, says agentic war rooms can do in milliseconds what takes conventional ones hours. That turnaround is worth noting, but speed is nothing without structure. Governance matters more: how you actually get this adopted, and how every agent stays within the governance and security policies you already have.
Why set up Pre-Approved Reversible Actions for Virtana AI Agent?
Before a one-person IT team lets an agent fix an incident without them, I’d require a scoped allow list of pre-approved, reversible actions tied to specific incident classes. For a defined incident, the agent may take actions A, B and C, such as rolling back a deployment or restarting a stateless service. Anything outside that list, and anything irreversible like deleting data or changing security settings, goes to a human automatically.
That limits the damage from a wrong diagnosis, matches how trust is actually built, and makes accountability clear. I wouldn’t give an important process to a bot I built yesterday, just like I wouldn’t give it to an employee who started yesterday.
The first class I’d put on that list is a regression after a deployment, with rollback as the allowed action, restricted to services without database migrations. The causal signal is strong, and a rollback is reversible by design and easy to verify. It’s also the scenario in Virtana’s own example, a database bottleneck after a recent deployment, so it’s the one the product is most likely to handle well today.
It also comes up often. DORA’s 2024 research put a quarter of respondents in a cluster where 40% of changes failed. With failures that common, every rollback the agent recommends and you approve adds to the evidence for letting it act alone.
Why Should IT Teams Stage Virtana AI Agent Autonomy by Incident Category?
We had a digital worker reviewing store assortments, half a million records a day. An assortment is a store’s ability to order an item. The first iteration only reported. It applied the business rules and told the supporting teams which master data issues needed resolving, sorted by type of issue.
Over time, we handed it the lower-risk issues with really strong business rules, one category after another, until it resolved five categories on its own. It still reported back to the team: here’s the full report, here’s what I actioned, here’s what’s left for you. Everything it did was reversible. That digital worker was actioning tens of thousands of data errors a day and making previously unavailable products orderable in stores.
Virtana’s three stages follow the same logic. Before an incident class moves from approvals to autonomy, you need evidence, and the person making the call should be able to see all of it without relying on trust or a dashboard. But if you layer in too much control and approval, you’re not getting the full benefit of the automation. For a team of one, permanent approval mode means every fix still waits on you.
Virtana’s AOEM, announced October 28, 2026, stages AI agent autonomy in three steps, and only pre-approved, reversible fixes for defined incident classes should reach the last one.
|
Virtana AOEM stage |
What the AI agent does |
What the IT team does |
Fixes suited to this stage (examples) |
|---|---|---|---|
|
Recommendation mode |
Investigates and proposes fixes for engineers to carry out |
Reviews the diagnosis and carries out the fix |
Any incident class while trust is being built |
|
Approval-based remediation |
Runs a fix only after human approval where policy requires it |
Approves or rejects each fix, building evidence for autonomy |
Deployment rollbacks and stateless service restarts while the record builds |
|
Autonomous action for defined incident classes |
Resolves incidents on its own within enterprise-defined guardrails |
Defines the allow list and reviews what the agent did |
Deployment rollback (no database migrations) or stateless service restart |
|
Any stage: out-of-policy or irreversible action |
Blocked by an execution-layer check against excessive agency, not its prompt |
Receives the action automatically and decides |
Deleting data, changing security settings, anything off the allow list |
Execution Layer Authorization Checks for Virtana AI Agent Orchestration
Virtana’s war-room scenario is an illustration, and the company doesn’t present it as a customer incident. With any staged-autonomy pitch, the difference comes down to whether the safety is enforced by the system or only shown in the demo.
So ask what stops an agent that tries an action outside the policy, and where that check runs. A real system enforces limits at the execution layer, outside the agent’s own reasoning. If the answer is that the agent is instructed not to, you’re looking at a prompt, and I wouldn’t count a prompt as a control. OWASP files this under excessive agency. Its guidance is to enforce authorization in the downstream systems instead of leaving that call to the model.
Ask that about every agent in the room. According to SiliconANGLE, outside agents that support MCP or A2A can be invited, including ones bundled with software a company already uses.
Ask about tokens, too, because agents recruiting other agents run up digital consumption. In a digital world, that consumption is your inventory, and inventory is the devil. It grows invisibly and exponentially until the cost is out of control. Virtana says it has token controls, so check that the system enforces those as well.
With unproven vendor technology, I insist on a zero-cost proof of concept before committing budget. For AOEM, that proof should include a rollback on your own systems and an out-of-policy action stopped by the system while you watch.
Defining Organization-Specific Allow Lists for Virtana AI Agents
For a team of one, the appeal is obvious: agents working the incident while you’re buried in tickets. But someone has to define the incident classes, exceptions and parameters they work within. That takes someone who knows the nuances of your four walls. The unwritten rules and edge cases that live in people’s heads are the biggest hidden trap in mid-market operations, and in a one-person IT shop, that head is yours. Writing the allow list gets those rules on paper. It also gives you a straight answer the day the CEO asks what the agent did, who approved it and what it cost.
That allow list starts with knowing which processes in your four walls are safe to hand off and which are not. That is what we map in the Discovery Workshop.