Testing
AI Force – Phase 0 Pilot Use-Case Demonstration
Client Presentation – Speaker Notes
Date: 11 November 2026
Slide 1 – Introduction: Pilot Use-Case Demonstration
Good morning everyone, and thank you for joining today's session.
Today, we will be showcasing the Phase 0 pilot initiatives that we have identified and developed as part of our automation journey using AI Force and RunbookAI.
The objective of this pilot is to demonstrate how we can take some of the repetitive infrastructure operations activities that are currently handled manually and move them towards standardized, automated and, wherever applicable, self-healing workflows.
We have deliberately started with a few focused use cases where the operational process is relatively well understood, the execution steps are documented, and the potential business value is measurable.
Rather than just discussing the solution theoretically, we will also walk you through actual executions on the orchestrator platform and show how the workflows interact with ServiceNow and the underlying infrastructure.
Let me first walk you through the initiatives we have shortlisted for Phase 0.
Slide 2 – Phase 0 Pilot Initiatives
For Phase 0, we have identified three primary operational use cases, along with an additional automation capability validation initiative.
The first is UNIX heartbeat failure. Here, the objective is to identify whether a server is genuinely unreachable or whether the issue is related to the monitoring agent. Based on the validation, the workflow can attempt recovery wherever applicable.
The second is Windows disk space low. This focuses on proactively addressing disk utilization issues by executing predefined cleanup activities, validating the available space, and determining whether further investigation or manual intervention is required.
The third is the daily health check report for WINTEL. This is more of a reporting automation use case, where we automate the collection of health information and generate a consolidated report instead of relying on manual checks.
And finally, automation capability validation. This is not a separate operational use case in the same sense as the other three. It demonstrates how the platform can support incident and reporting automation across different operational scenarios.
We have intentionally kept Phase 0 focused. The idea is to validate the end-to-end automation approach, execution reliability, integration capabilities and operational benefits before expanding into more complex scenarios.
Now, let's look at the operational baseline behind these selections, because this is where the business justification comes in.
Slide 3 – Phase 0 Pilot Initiatives: Business Baseline
We looked at the historical operational volumes and identified these activities based on their frequency, repeatability and potential for automation.
If you look at the numbers, UNIX heartbeat failure accounts for approximately 220 incidents per month, with an estimated 110 hours of monthly effort.
Windows disk space low contributes another 194 incidents per month, accounting for approximately 97 hours.
Additionally, the daily WINTEL health check reporting activity accounts for approximately 30 hours of monthly effort.
So, collectively, we are looking at a baseline of approximately 444 monthly occurrences and 237 hours of operational effort.
Now, these numbers represent the existing operational baseline, not a claim that all 237 hours will immediately be eliminated through automation.
The opportunity here is to reduce repetitive manual intervention, standardize execution, improve response time and allow the support teams to focus on more complex operational activities.
From here, I would like to take you through the actual workflows, starting with Windows disk cleanup.
Slide 4 – Windows Disk Cleanup: RunbookAI Workflow
Let's start with the Windows disk cleanup use case.
In a typical infrastructure environment, low disk space alerts are fairly common. When an alert comes in, the support engineer has to connect to the server, investigate which directories are consuming space, identify whether cleanup is possible, execute the cleanup and then validate whether sufficient space has been recovered.
Our objective is to automate these repetitive and predefined steps.
The workflow starts when a disk space-related incident is created in ServiceNow. The incident is routed to the Runbook Automation queue, which invokes the relevant automation workflow.
Before executing any cleanup, we perform connectivity checks, validate permissions and check the disk status.
Once the pre-checks are successful, the automation executes the predefined cleanup activities. These include approved temporary directories, Windows temporary files, recycle bin and other agreed cleanup locations.
We have also incorporated an additional validation for IIS-related content, where applicable, to archive eligible older logs rather than blindly deleting them.
After the cleanup, the workflow checks disk utilization again.
If the disk utilization falls below the configured threshold, the workflow updates the ServiceNow work notes with execution details and proceeds with automated incident resolution.
However, if sufficient space cannot be recovered, we don't forcefully close the incident. Instead, the workflow performs additional investigation, identifies the top space-consuming user profile folders and shares the findings with the support team for manual intervention.
So the important aspect here is that this is not simply a cleanup script. It is a controlled workflow with pre-checks, execution, post-validation, exception handling and ServiceNow integration.
LIVE DEMONSTRATION – WINDOWS DISK CLEANUP
Switch from PowerPoint to AI Force / RunbookAI.
Step 1 – Show the ServiceNow incident
Here we have the incident that has triggered the automation. The incident provides the context for the workflow, including the affected server and the disk utilization issue.
Step 2 – Show orchestration
Once the incident is received, the orchestrator identifies the appropriate automation workflow and routes the request to the Windows disk cleanup runbook.
Step 3 – Show execution
Now, the workflow is performing the connectivity and permission checks, followed by the approved cleanup activities. Each step is executed in a controlled sequence.
Step 4 – Show the result
Once execution is complete, we validate the available disk space again. Based on the outcome, the workflow determines whether the incident can be automatically resolved or whether further investigation is required.
Step 5 – Show ServiceNow update
Finally, the execution outcome and relevant findings are passed back to ServiceNow. This ensures that the support team has visibility into what was executed, what was recovered and whether any manual intervention is still required.
The key value here is that we are not automating only the technical command execution. We are automating the complete operational lifecycle, from incident intake through execution and validation to closure or escalation.
Slide 5 – UNIX Heartbeat Failure: Automation and Self-Healing Workflow
Moving on to the UNIX heartbeat failure use case.
This is another common operational scenario where monitoring tools generate alerts when a server stops responding or when communication with the monitoring agent is lost.
However, not every heartbeat failure necessarily indicates that the underlying server is down.
Sometimes, the server is perfectly healthy, but the monitoring agent has stopped responding or its communication has been interrupted.
Today, support teams often need to log in to the server, check the uptime, validate the monitoring agent, investigate the connectivity and, if required, restart the agent.
We have designed the automation to perform these checks systematically.
The workflow starts by validating connectivity and credentials. It then checks whether the server is reachable and evaluates the server uptime.
If the server has recently rebooted, the workflow identifies that condition separately rather than treating it as a genuine agent failure.
If the server is reachable and the uptime is beyond the defined threshold, the automation proceeds to validate the monitoring agent.
Where the agent is found to be unhealthy, the workflow attempts a controlled restart and subsequently checks whether the agent has recovered.
Based on the final result, the workflow categorizes the incident as a false positive, recent reboot, successful self-healing or an actual agent failure requiring support-team intervention.
The important point is that we are introducing validation before taking corrective action. We don't want to restart services unnecessarily when the actual issue is elsewhere.
LIVE DEMONSTRATION – UNIX HEARTBEAT FAILURE
Switch to AI Force / RunbookAI.
Step 1 – Show the ServiceNow incident
Here is the heartbeat-related incident that has triggered the workflow.
Step 2 – Show connectivity and server checks
The automation first checks whether the server is accessible and validates the basic server information, including uptime.
Step 3 – Show agent validation
Once the server is confirmed reachable, we check the monitoring agent's health and determine whether the issue is actually related to the agent.
Step 4 – Show recovery
If the agent is unhealthy, the workflow attempts a controlled restart and waits for the agent to become healthy again. It also performs subsequent validation instead of assuming that a restart means recovery.
Step 5 – Show final outcome
Depending on the result, the automation updates the incident with the appropriate outcome. If the agent recovers, we can proceed towards automated resolution. If it doesn't, the incident is routed to the UNIX support team with the diagnostic information.
This is where we start moving from traditional script-based automation towards self-healing infrastructure operations. The workflow is not just executing commands; it is evaluating the condition, choosing the appropriate action and validating the outcome.
Slide 6 – Nutanix Prism Central Health Check: Automation Workflow
The third use case is slightly different from the previous two because this is focused on proactive operational health monitoring and reporting rather than incident remediation.
In a typical Nutanix environment, infrastructure teams need to periodically log in to Prism Central and validate the health of clusters, nodes, virtual machines, storage utilization, snapshots, upgrade status and outstanding alerts.
These checks are important, but collecting and consolidating this information manually takes time.
We have automated this process through an Ansible-based health check workflow.
The execution can be triggered either on a scheduled basis through RunbookAI or on demand by the WINTEL team.
Once triggered, the orchestrator invokes the Ansible playbook, which connects to Nutanix Prism Central and collects the relevant infrastructure health information.
This includes cluster status, node count, VM information, storage utilization, uptime, snapshots, operational mode, upgrade status and unresolved alerts.
The collected information is then processed into an HTML health report, which is distributed to the WINTEL team through email.
The objective is to provide a consistent and consolidated view of the infrastructure health without requiring engineers to manually navigate multiple dashboards and compile the information.
This also creates an opportunity to identify potential issues earlier and improve operational visibility.
LIVE DEMONSTRATION – NUTANIX HEALTH CHECK
Switch to AI Force / RunbookAI.
Step 1 – Show execution trigger
Here we can see that the workflow supports both scheduled execution and on-demand execution.
Step 2 – Show Ansible invocation
The orchestrator invokes the Nutanix health check playbook, which performs the required API-based checks against Prism Central.
Step 3 – Show collected information
We are collecting information across different infrastructure components, including clusters, nodes, virtual machines and storage.
Step 4 – Show HTML report
Once the information is collected, the automation generates a structured HTML report that provides a consolidated view of the environment.
Step 5 – Show email distribution
Finally, the generated report is distributed to the WINTEL team, making the information readily available without requiring manual report preparation.
This is a good example of how automation can deliver value even without performing any corrective action. Sometimes, simply automating repetitive health checks and providing timely visibility can significantly reduce operational effort.
Slide 7 – Thank You
That brings us to the end of our Phase 0 pilot demonstration.
Across these use cases, we have demonstrated three different dimensions of infrastructure automation.
First, automated remediation through the Windows disk cleanup workflow.
Second, self-healing capabilities through the UNIX heartbeat failure workflow.
And third, operational efficiency and proactive visibility through the Nutanix health check reporting workflow.
What we wanted to establish through this pilot is that the platform can integrate with existing operational processes, interact with ServiceNow, invoke infrastructure automation and bring execution outcomes back into the operational workflow.
This Phase 0 exercise will also help us validate the approach, understand integration dependencies and identify opportunities to scale automation across additional use cases.
We would be happy to take your questions and discuss feedback, observations and potential next steps.
Thank you.
Additional Talking Points – If the Client Asks Questions
Q1. Can this work with other monitoring tools?
Yes, subject to integration availability and the required API or connectivity mechanisms. The same approach can be extended to other monitoring platforms.
Q2. What happens if automation fails?
The workflow captures the failure details and routes the request for appropriate manual intervention. We have defined exception-handling paths rather than allowing failed executions to proceed as successful.
Q3. Can we add more use cases?
Absolutely. We can follow the same assessment, SOP validation, development, testing and deployment approach for additional use cases.
Q4. Is everything autonomous?
No. Phase 0 uses controlled, predefined automation with validation and defined execution boundaries. The objective is to automate repeatable activities while retaining appropriate controls and human intervention wherever required.
Q5. How do we measure ROI?
We can measure the benefits through reduced manual effort, reduced MTTR, automation success rate, incident resolution time and the volume of activities handled without manual intervention.
Closing Message – Overall Positioning
One important message I would like the audience to take away is that this pilot is not just about three individual Ansible playbooks.
It is about establishing an end-to-end infrastructure automation capability that connects ServiceNow, orchestration, automation execution and operational outcomes.
We are demonstrating how existing operational processes can be transformed into standardized, repeatable and measurable automation workflows.
Phase 0 gives us the foundation to validate this approach and gradually expand automation coverage across additional infrastructure operations.
Comments
Post a Comment