A continuation of Learn. Prioritize. Automate. The LEAP Story
That 2 AM Engineer, One More Time
Let's check in on that 2 AM engineer one more time.
In the last chapter of the LEAP story, we left them in a better place. The incident that used to send them scrambling through old tickets now had a curated playbook waiting, resolution steps mined by LEAP from months of incident history, turned into an executable ServiceNow workflow, surfaced right in the Service Operations Workspace. The knowledge was there. The steps were clear. The execution path was open.
But here's the reality in most enterprise operations teams: automation doesn't live in one place, and it didn't start with LEAP. Long before LEAP came along, your automation engineers were already building Ansible playbooks. Hundreds of them, in many cases - job templates for restarting services, flushing caches, rotating certificates, patching nodes. A library of hard-won automation, battle-tested in production, sitting in Ansible Automation Platform and doing exactly what it was built to do.
LEAP could tell you what needed to happen. Your Ansible library already knew how to make it happen. The two just didn't talk to each other. That's the gap this integration closes.
A Quick Recap: Where LEAP Has Been
If you haven't read the first part of this story, here's the short version. LEAP clusters your historical incident data to surface automation opportunities, the patterns your team has been solving manually, over and over, without realizing it. It prioritizes those opportunities by business impact. It mines resolution steps from your past ticket closures, enriches them with external best practices, and generates playbooks and knowledge base articles that land directly in your operational workflows, executable from the Service Operations Workspace.
It's a pipeline that transforms months of incident noise into an automation strategy with evidence behind it. The January 2026 release sharpened that pipeline considerably: sub-grouping for more precise clusters, multi-source resolution mining that reaches beyond your internal data, KB article generation, and a conversational LEAP Agent that lets automation architects work through dialogue instead of forms.
What remained was a question that many customers were already asking: what about the automation we've already built?
The New Chapter: Honoring Your Existing Investment
The answer is LEAP's Ansible MCP Server integration, and the design philosophy behind it matters as much as the capability itself.
LEAP doesn't ask you to rebuild your Ansible playbooks inside ServiceNow. It doesn't ask your automation engineers to re-author what they've already perfected. Instead, it connects to your existing Ansible Automation Platform via an MCP server, discovers what's already there, and brings it into the LEAP workflow. Now when an incident arrives, your resolution is ready to execute.
One connection in the LEAP settings page. Credentials in, saved, connected. From that point, your entire Ansible job template library is available to LEAP.
Step One: AI-Driven Job Discovery
Every automation opportunity with Resolution Steps generated in LEAP now has a new action available: Map Ansible Jobs. Before an admin touches it, an AI agent has already done the groundwork. It reads the problem description of the automation opportunity, reaches out to Ansible via the MCP connection, and returns a ranked list of candidate job templates from your existing library, matched by semantic similarity to the problem description, weighted by historical success rates, and filtered by reliability.
The admin doesn't search through hundreds of templates trying to remember which one handles nginx restarts versus generic service restarts. The agent surfaces the right options from what already exists.
Step Two: Mapping Steps to Jobs
Then comes the mapping modal. Each resolution step, the same steps LEAP's mining engine already generated from your incident history, gets matched to one or more of your existing Ansible job templates. Steps that don't have a matching automation stay as manual steps. The system is honest about that, and handles it gracefully: during execution, the agent will pause at those steps and ask the human to handle them before moving on.
Save the mapping once, and it's done. From that moment forward, every time LEAP's clustering predicts that a new incident belongs to that group, your Ansible jobs are already queued and waiting.
Step Three: Execution in One Conversation
This is where the experience changes most visibly for the people actually resolving incidents at 2 AM.
When the incident arrives in the Service Operations Workspace, LEAP predicts the active group, finds the mapping, and surfaces a single button in the recommendations panel alongside the resolution steps: Execute Ansible Playbook. That button opens a conversation, not a form, not a new tab, not Ansible's own job runner in a separate application. A conversation, inside SOW, where the responder already is.
An AI execution agent takes over. It reads the step-to-job mapping and walks through the resolution sequence. For every automated step, it collects exactly the inputs it needs: survey questions, inventory parameters, credentials, and presents them all at once, in a single prompt. One confirmation. Then it launches the job against your Ansible Automation Platform via MCP.
For manual steps, it pauses, tells the responder exactly what to do, and waits for confirmation before continuing.
Step Four: Status, Summary, Done
When the job runs, the agent reports the Ansible Job ID and status. If the operator wants an update mid-flight, they ask. The agent retrieves it on demand, no polling, no tab-switching, no wondering whether the job quietly failed ten minutes ago.
When every step is done, the agent delivers a clean summary: steps processed, jobs launched, job IDs, host changes, final execution state. The operator marks it complete.
What the Full LEAP Pipeline Looks Like Now
Your incident data clusters into patterns. The patterns get prioritized by impact. Resolution steps get mined from your history and enriched from the broader industry. ServiceNow Creator workflow playbooks get published to SOW for teams who want to build net-new automation on the platform. And now, for teams with existing Ansible investments, those job templates are discovered, mapped, and executed from the same SOW experience, via the Ansible MCP Server, without rebuilding anything.
Two paths to execution. One LEAP workflow. Your choice of automation runtime.
The loop is closed.
The Deeper Benefit: Your Ansible Library Finally Has an Audience
There's a benefit here that doesn't show up in MTTR dashboards right away, but compounds over time.
Every Ansible job template your automation engineers have built over the years now has a discovery layer in front of it. LEAP finds those templates at the right moment, matches them to the right incidents, and surfaces them to the right people. Playbooks that got used only when someone remembered they existed are now active participants in your incident resolution workflow.
The institutional knowledge problem that LEAP started solving with KB article and Problem Record generation has a new dimension. It's not just that the resolution steps are documented, it's that the tools to execute them are mapped, discoverable, and connected to your existing automation estate.
With Ansible integration, we are now not just talking about which opportunity and what steps to automate, but which job template, already built and proven in your environment, to be run in which sequence, with which inputs, and to be confirmed at which checkpoints.
The intelligence was always there. Your automation was already there too. LEAP is now the bridge between them. For detailed walkthrough, refer Unlock AIOps with ServiceNow LEAP and Ansible MCP server - Solution Guide!
