AAP Guides
Edit on GitHub

LogicMonitor + Ansible Automation Platform: AIOps Solution Guide

Work in Progress – this guide is actively being developed.

From Alert Noise to Governed Remediation

Organizations invest heavily in observability, yet most still rely on humans to translate monitoring insights into remediation actions. LogicMonitor and Edwin AI provide the intelligence to detect, analyze, and recommend. Ansible Automation Platform provides the trust layer to govern, execute, and report. Together, they deliver closed-loop AIOps that is safe enough for 3 AM and auditable enough for Monday morning.

This guide follows a crawl-walk-run maturity progression for BGP network remediation. Crawl uses LogicMonitor Envision to map approved playbooks for operator-led execution; Walk uses Event-Driven Ansible (EDA) and rule-based triggers; Run uses Edwin AI chat and autonomous agents. The same pattern applies to any infrastructure domain that LogicMonitor monitors -- servers, storage, cloud, and hybrid IT environments.

   
Operational Impact Clear operator guidance and repeatable manual execution (Crawl), reduced response time through rule-based automation for proven scenarios (Walk), and faster diagnosis with autonomous diagnostics and remediation recommendations, with human-approved execution (Run)
Business Value Drivers Reduced MTTR, lower on-call escalation volume, faster incident resolution without increasing headcount
Technical Value Drivers Envision playbook mapping, Event-Driven Ansible (EDA) rule-based triggers, Edwin AI chat and agentic diagnostics, governed execution with RBAC, approvals, and audit trails

Contents

Background

The AIOps Gap: Detection Without Action

Alert fatigue is the symptom. The root cause is a gap between intelligence and execution.

Monitoring platforms excel at detecting problems. AI layers excel at correlating signals and recommending fixes. But without a governed execution layer, those recommendations become Slack messages, tickets, and pages to an on-call engineer who may or may not act on them in time.

The fundamental question is this: if your AI makes a recommendation at 3 AM, what prevents a bad recommendation from reaching production?

Manual review does not scale. Blind automation introduces unacceptable risk. The answer lies in combining AI intelligence with governed automation.

LogicMonitor and Edwin AI: The Intelligence Layer

LogicMonitor is a hosted full-stack infrastructure monitoring platform with particular strength in network monitoring. It provides agentless discovery, anomaly detection, and comprehensive alerting across hybrid infrastructure.

Edwin AI is LogicMonitor’s AI-powered ITOps layer. It goes beyond simple threshold-based alerting to proactively detect, diagnose, and recommend remediation actions through:

Ansible Automation Platform: The Trust Layer

Red Hat Ansible Automation Platform provides the governance framework that makes AI-recommended automation safe for production:

LogicMonitor and Edwin AI provide the intelligence. AAP provides the trust layer. Neither platform can deliver closed-loop AIOps alone.

Solution

Components

Component Role Details
LogicMonitor Detection and monitoring Full-stack infrastructure monitoring, webhook-based alerting
Edwin AI Analysis and recommendation Alert correlation, root cause analysis, remediation recommendations
AAP Automation Controller Governed execution Job templates, workflow templates, RBAC, audit logging
AAP EDA Controller Event-driven automation Rulebook activations, event stream processing, webhook ingestion
MCP integration Agentic AI interface Connects Edwin AI to AAP APIs for approved automation discovery and execution within configured authorization and approval boundaries.
Network infrastructure Target infrastructure Network devices monitored by LogicMonitor (examples in this guide use Arista EOS)

Personas

Persona Challenge What They Gain
Network Operations Manual triage of BGP alerts; slow MTTR; alert fatigue from repetitive incidents Known issues resolve in seconds. Ambiguous failures are triaged by AI. On-call engineers handle only truly novel problems.
Platform Engineering Remediation logic lives in tribal knowledge; no governed way to encode decision trees Every action runs through pre-tested job templates with RBAC. Workflow templates encode decision logic. Patterns promote from ad-hoc to governed.
Security and Compliance No audit trail for manual remediation; AI actions bypass governance Every alert, decision, and action is logged. Policy as Code enforces boundaries. Human approval gates at any point in the chain.

Prerequisites

Requirement Version / Details
Ansible Automation Platform 2.6 (Automation Controller + EDA Controller)
LogicMonitor Active account with API access and webhook configuration
Edwin AI Portal with API credentials (access_id, access_key)
MCP integration Connects Edwin AI to AAP APIs through MCP; configure the AAP connection and authorization controls.
Network devices Devices monitored by LogicMonitor with BGP peering (examples use Arista EOS)

Collections

Collection Purpose
logicmonitor.integration LM device management (devices, collectors, alert rules, device groups)
logicmonitor.edwin_ai Edwin AI query API for alert correlation and insights
arista.eos Network device automation (substitute your platform’s collection as needed)
ansible.eda Event-Driven Ansible webhook source plugin, Event Stream management
ansible.controller AAP Controller object management (bootstrap automation)

Integration Architecture

AIOps Value Chain

The integration maps cleanly across the AIOps value chain, with LogicMonitor and Edwin AI owning the left side (intelligence) and AAP owning the right side (execution):

  LogicMonitor / Edwin AI                 AAP
  +------------------------------+  +------------------------------+
  | DETECT -> ANALYZE -> RECOMMEND |  | GOVERN -> EXECUTE -> REPORT  |
  |                                |  |                              |
  | LM monitors infrastructure    |  | RBAC, Policy as Code         |
  | Edwin AI correlates alerts     |  | Pre-tested job templates     |
  | Edwin AI recommends actions    |  | Workflow orchestration       |
  |                                |  | Audit trails                 |
  +------------------------------+  +------------------------------+

Overall Architecture

+---------------------------------------------------------------------+
|                        LOGICMONITOR                                   |
|  +----------+    +----------+    +------------------------------+    |
|  | Detection |-->| Analysis |-->| Edwin AI (Recommendations)    |    |
|  | Engine    |   | (AI/ML)  |   |                                |   |
|  +----------+    +----------+    +------+--------------+---------+   |
|                                         |              |             |
+-----------------------------------------|--------------|-------------+
                                          |              |
                        Webhook (alerts)  |              | MCP (chat and agentic)
                                          |              |
+-----------------------------------------|--------------|-------------+
|                  ANSIBLE AUTOMATION PLATFORM                         |
|                                         |              |             |
|  +------------------+    +--------------v--+   +-------v--------+   |
|  | EDA Controller   |    | Automation      |   | MCP integration |   |
|  |                  |    | Controller      |   |                |   |
|  | Event Streams    |--->| Job Templates   |<--| AAP API access |   |
|  | Rulebook         |    | Workflows       |   | Authorization and approvals  |   |
|  | Activations      |    | RBAC / PaC      |   | Human approval |   |
|  +------------------+    | Audit Logging   |   +----------------+   |
|                          +--------+--------+                        |
|                                   |                                 |
|                    +--------------v--------------+                  |
|                    | Content Collections          |                  |
|                    | logicmonitor.integration     |                  |
|                    | logicmonitor.edwin_ai        |                  |
|                    | arista.eos                   |                  |
|                    +--------------+--------------+                  |
|                                   |                                 |
+-----------------------------------|---------------------------------+
                                    |
                    +---------------v---------------+
                    |    TARGET INFRASTRUCTURE       |
                    |  Network devices monitored     |
                    |  by LogicMonitor                |
                    +-------------------------------+

Integration Surfaces

Four integration surfaces are used across the three maturity stages:

Surface Component Stage Role
EDA Event Stream AAP Event Streams (AAP 2.5+) All Configured endpoint that receives events and routes them to rulebook activations.
EDA webhook source ansible.eda.webhook source plugin All EDA rulebook activation that evaluates events received through the configured Event Stream.
LM device management logicmonitor.integration collection All Manages LM devices, collectors, alert rules, device groups
Edwin AI query logicmonitor.edwin_ai.query_api module Run Queries Edwin AI for correlated alerts, events, insights
MCP integration MCP connection to AAP APIs Run Connects Edwin AI to AAP APIs for approved automation discovery and execution.

Integration Patterns

Each maturity stage uses a different integration pattern with AAP. The patterns differ in how they are triggered, how tightly they couple the partner platform to AAP, and how governance is enforced:

  Envision (Crawl) EDA (Walk) Edwin AI Chat + MCP (Run)
Trigger Operator-selected mapped playbooks Edwin events and EDA rules Natural-language chat and agent tools
Coupling Guided (operator-led, mapped) Rule-based (event-driven) Agentic (chat and tool-mediated)
Primary user NOC / platform operators Operations and platform teams Operators using Edwin AI chat and agents
Governance RBAC, approval, and audit controls Rulebook conditions, service accounts, and AAP policy RBAC, approvals, and MCP action boundaries
Response model Human-initiated and auditable Event-driven Conversational, AI-assisted

The crawl-walk-run progression starts with Envision mapping and operator-led execution, adds EDA rule-based triggering for repeatable patterns, and then adds Edwin AI chat and agentic diagnostics. AAP governance applies at every stage.

Stage 1 -- Crawl: Envision Playbook Mapping and Manual Execution

Crawl establishes the shared operational vocabulary before automation is delegated to events or agents. LogicMonitor Envision statically maps monitored conditions and recommended actions to approved AAP job templates. Operators use that mapping to review the alert context, select the appropriate playbook, and execute it manually through LogicMonitor Envision with AAP RBAC, approvals, and auditability.

##

Flow

LogicMonitor detects a condition and surfaces its context in Envision
-> LogicMonitor presents the mapped, approved AAP job template
-> Operator reviews the diagnostic context and available actions
-> Operator manually execute the AAP job from the LogicMonitor Envision UI
-> AAP enforces access controls and any required approval
-> Results are recorded and used to identify candidates for Walk-stage triggers

##

Setup

Stage 2 -- Walk: Event-Driven Network Remediation

The Walk stage combines LogicMonitor detection with Edwin AI correlation and rule-based action mapping. Edwin identifies the likely root cause, then configured Rules and Actions select an approved AAP job template and send the relevant payload to Event-Driven Ansible for governed AAP execution. This creates a repeatable, root-cause-informed path from alert to action.

Flow

LogicMonitor detects a BGP alert on a network device
  -> LogicMonitor sends alert context to Edwin AI
    -> Edwin AI correlates signals and identifies the likely root cause
      -> Edwin Rules and Actions select the mapped AAP job template
        -> Edwin uses Post Ansible EDA Event to send the mapped payload to the configured Event Stream URL
          -> The EDA rulebook evaluates the payload and invokes the approved AAP job template
            -> AAP executes the job, records the execution ID, and validates the outcome
              -> Edwin checks status using the execution ID and receives the result and output

Setup

  1. Connect Edwin AI to AAP. In the Edwin AI integration, configure the AAP Base URL, OAuth token, AAP API path prefix, and AAP EDA API path prefix. Use a Relay Agent only when direct HTTPS/API connectivity is unavailable. Verify that Edwin can retrieve the approved AAP job templates and workflows that will be available as actions.

  2. Confirm the LogicMonitor signal path. Ensure the relevant alerts, device metrics, logs, and topology context are available to Edwin AI so it can correlate the event and identify the likely root cause.

  3. Configure Edwin Rules and Actions. For direct execution, map a condition to an approved AAP job or workflow template ID. For EDA, use Post Ansible EDA Event with the configured Event Stream URL. Map the affected resource and incident context into valid JSON extra variables expected by the target template.

  1. Define safe execution boundaries. Use approved AAP templates, appropriate credentials and permissions, and approval gates for write-based remediation where policy requires. Rule-based actions run only within the configured integration credential or service-account and AAP RBAC boundaries. Capture the execution ID, check status after launch, and review output in Edwin; synchronize to ITSM only when configured.

  1. Create the job template. Using the AAP bootstrap playbook at lab-automation/aap_bootstrap_lm_aiops.yml, or manually, create the “Reset BGP Session” job template:
Field Value
Name Reset BGP Session
Job Type Run
Organization Network Ops
Project LM AIOps Solution Guide
Playbook playbooks/reset_bgp_session.yml
Inventory Network Inventory
Credentials Machine Credential
Ask Variables on Launch Yes
Extra Variables {"affected_host":"<host>","alert_id":"<alert_id>"} (valid JSON supplied by the Edwin action payload)

Use Case: BGP Peer Down -- Reset Session

A BGP neighbor relationship drops to IDLE state on one router, causing a network segment to become unreachable. LogicMonitor detects the state change, fires a critical alert, and sends the alert context to Edwin AI for correlation and action selection.

Edwin uses Post Ansible EDA Event to send the mapped payload to the configured Event Stream URL, where an EDA rulebook evaluates it and launches the approved job template:

# --- WALK: Known alerts, deterministic remediation ---
- name: BGP peer down - reset session
  condition: event.payload.type == "bgp_peer_down"
  action:
    run_job_template:
      name: "Reset BGP Session"
      organization: "Network Ops"
      job_args:
        extra_vars:
          affected_host: ""
          alert_id: ""

The “Reset BGP Session” job template (playbooks/reset_bgp_session.yml) targets the affected device, clears all BGP sessions, waits for peers to re-establish, and validates the recovery. On success, it reports the remediation result back to LogicMonitor via playbooks/report_to_logicmonitor.yml, which acknowledges and annotates the alert:

# Note: The logicmonitor.integration collection does not yet include an alert
# acknowledgment module. This task uses ansible.builtin.uri as a placeholder
# until native module support is available.
- name: Acknowledge alert in LogicMonitor
  ansible.builtin.uri:
    url: "https://.logicmonitor.com/santaba/rest/alert/alerts//ack"
    method: POST
    headers:
      Authorization: "Bearer "
      Content-Type: "application/json"
    body_format: json
    body:
      ackComment: >-
        Automated remediation by AAP: 
        on host .
    status_code: [200, 202]

Validation

Once configured, trigger a real or test BGP peer down alert in LogicMonitor. Verify in the AAP Controller that the “Reset BGP Session” job launches targeting the correct host.

Expected result in Edwin AI chat:

PLAY [Reset BGP session on affected device] ************************************

TASK [Assert BGP peers are established] ****************************************
ok: [affected-device] => {
    "changed": false,
    "msg": "BGP peers successfully re-established"
}

PLAY RECAP *********************************************************************
affected-device            : ok=6    changed=0    unreachable=0    failed=0

For hands-on testing with a lab environment, see the Demo Guide.

Components

Component Details
LogicMonitor Detects alerts and sends operational context to Edwin AI
Edwin AI Correlates signals and identifies the likely root cause
Edwin Rules and Actions Maps the identified condition to an approved Ansible job template and builds the execution payload
Event Stream Configured Event Stream URL that receives the mapped payload from Edwin’s Post Ansible EDA Event action
EDA source EDA rulebook activation configured for the Event Stream
Rulebook Evaluates the mapped payload, conditions, and guardrails; invokes the selected approved job template
Job Template "Reset BGP Session"
Playbook playbooks/reset_bgp_session.yml
Collections arista.eos, ansible.eda

Stage 3 -- Run: AI-Driven Chat and Agentic Operations

The Run stage is a conversational, AI-assisted operations experience. Edwin AI correlates alerts into an Insight, identifies the likely root cause, and recommends existing approved AAP job or workflow templates for diagnostics or remediation. Operators interact with Edwin AI chat to review the rationale, ask follow-up questions, and initiate eligible execution. Edwin communicates with AAP through MCP and returns execution status and results to the conversation. Configured AAP authorization and approval controls govern which templates and actions are permitted. Read-only diagnostics may be autonomous where policy permits; write-based remediation remains human-approved.

Flow

LogicMonitor alerts contribute to an Edwin AI Insight
  -> Edwin AI correlates alerts from LogicMonitor
    -> Edwin AI correlates signals and identifies the likely root cause
      -> LogicMonitor alerts provide the operational context
        -> Edwin AI correlates related alerts into an Insight
          -> Edwin summarizes the Insight, impact, and likely root cause
            -> Edwin recommends approved diagnostic or remediation job and workflow templates
                -> Operator opens Edwin AI chat and reviews recommendations
          |
                  -> Operator asks follow-up questions or selects a recommendation
                    -> Edwin AI chat connects to AAP through MCP
          |
                      -> MCP calls AAP APIs to retrieve eligible job and workflow templates
                        -> Edwin presents the selected diagnostic or remediation option
          |
                          -> Operator approves and starts the selected template or workflow from chat
                            -> AAP executes the approved job template
          |
                              -> Execution status and output return through MCP
                                -> AAP records the execution and audit trail
          |
                                  -> Edwin keeps the rationale and actions visible
                                    -> Operator can continue the investigation in chat

Setup

  1. Configure the AAP connection in Edwin with the Base URL, OAuth token, AAP API path prefix, and AAP EDA API path prefix. Make validated AAP job and workflow templates available to chat. Use a Relay Agent only when direct connectivity is constrained. Ensure configured AAP authorization and approval policies limit template actions. Keep human approval for write-based actions; allow autonomous read-only diagnostics only where policy permits.

  2. Prepare approved AAP job templates. The following templates are examples of diagnostic and remediation options that Edwin can recommend from chat:

Field Enrich with Edwin AI Bounce Interface Restart Routing Rollback Config
Job Type Run Run Run Run
Organization Network Ops Network Ops Network Ops Network Ops
Project LM AIOps Solution Guide LM AIOps Solution Guide LM AIOps Solution Guide LM AIOps Solution Guide
Playbook playbooks/enrich_with_edwin_ai.yml playbooks/bounce_interface.yml playbooks/restart_routing.yml playbooks/rollback_config.yml
Inventory Network Inventory Network Inventory Network Inventory Network Inventory
Credentials Edwin AI API, Machine Credential Machine Credential Machine Credential Machine Credential
Ask Variables on Launch Yes Yes Yes Yes
  1. Optionally define reusable workflow templates. A workflow can be one of the approved assets recommended from chat, but it is not required to drive the conversational Run flow:
                +----------------------+
                | Enrich with Edwin AI |
                | (query_api)          |
                +---------+------+-----+
                          |      |
                       success  failure
                          |      |
          +-------+-------+      |
          |       |       |      |
          v       v       v      v
     +---------+ +-----+ +------+ +-------------+
     | Bounce  | | Re- | | Roll-| | Default BGP |
     | Iface   | |start| | back | | Reset       |
     +----+----+ |Rout.| |Config| +------+------+
          |      +--+--+ +--+---+        |
          |         |       |            |
          +---------+-------+------------+
                    |
                    v
           +------------------+
           | Report to        |
           | LogicMonitor     |
           +------------------+

This optional workflow illustrates how AAP can package a multi-step remediation. In the Run stage, Edwin performs correlation and recommendation in chat; an operator selects or approves an eligible AAP job or workflow template, and results return to that conversation.

Use Case: BGP Flapping -- Conversational Investigation and Recommendations

BGP sessions are flapping on a router. Edwin correlates the BGP alert with related operational signals, identifies the likely cause, and presents relevant approved AAP job or workflow templates in chat. The operator can ask follow-up questions, run a read-only diagnostic, or approve a write-based remediation. The examples below illustrate how Edwin can connect findings to recommended automation:

Edwin AI Insight finds Root cause Recommended AAP job or workflow template
BGP flapping + interface error counters spiking Bad link or cable Bounce the interface (playbooks/bounce_interface.yml)
BGP flapping + CPU at 98% on the device Resource exhaustion Restart routing process (playbooks/restart_routing.yml)
BGP flapping + config change event 5 minutes ago Config drift Roll back to last known good config (playbooks/rollback_config.yml)
Only BGP flapping, no correlated alerts Unknown / transient Recommend a read-only BGP and interface diagnostic before any remediation

For the chat-driven Run flow, Edwin uses its correlated Insight directly to recommend relevant AAP job or workflow templates. The enrichment playbook below is an optional asset for organizations that also maintain reusable AAP workflows; it is not required for chat-based correlation or recommendation.

- name: Query Edwin AI for correlated alerts
  logicmonitor.edwin_ai.query_api:
    portal: ""
    access_id: ""
    access_key: ""
    record_type: alerts
    limit: 20
    lookback_window: ""
  register: __edwin_alerts

In the chat-driven Run path, Edwin performs correlation directly as part of the Insight and uses it to explain the recommendation. The following workflow example is optional reusable AAP automation, not the core decisioning path:

- name: Set workflow artifacts for downstream nodes
  ansible.builtin.set_stats:
    data:
      root_cause: ""
      correlated_alert_count: ""
      affected_host: ""
      alert_id: ""

Optional: retain an EDA handoff only for a proven, repeatable pattern promoted to Walk. It is not part of the core chat-driven Run flow:

# --- WALK: rule-based automation promoted from a proven Run pattern ---
- name: BGP flapping - smart remediation
  condition: event.payload.type == "bgp_flapping"
  action:
    run_workflow_template:
      name: "BGP Smart Remediation"
      organization: "Network Ops"
      job_args:
        extra_vars:
          affected_host: ""
          alert_id: ""
          alert_context: ""

Relationship to Walk

When a Run-stage recommendation becomes sufficiently repeatable, promote it to Walk only after its conditions, approval requirements, and rollback path are proven. In Walk, Edwin Rules and Actions and EDA can route that defined scenario to approved automation without a conversational decision.

Validation

From an Edwin AI Insight, open chat and verify that correlated alerts, the likely root cause, and relevant approved AAP job or workflow templates are visible. Start an eligible job template or workflow, then verify that execution status and output return to the same conversation.

Expected result in Edwin AI chat:

Chat recommendation -- an approved diagnostic or remediation job or workflow template

Operator selects the recommended action and confirms execution
Configured AAP authorization and approval policies permit the selected template.

AAP job template -- Status: Successful
Execution status and output return to the Edwin AI chat

Edwin AI chat summarizes the result and recommends next steps

For hands-on testing with a lab environment, see the Demo Guide.

Components

Component Details
LogicMonitor Supplies alerts and operational context for Edwin Insights
Edwin AI Insights Correlates related alerts, identifies the likely root cause, and generates recommendations
Edwin AI chat Conversational experience for investigation, recommendations, execution, and results
MCP integration Connects Edwin chat to AAP APIs for approved job and workflow template discovery and execution
Approved AAP job and workflow templates Existing diagnostic and remediation job and workflow templates made available to chat
AAP RBAC Configured AAP authorization and approval policies limit execution
AAP execution results Execution status and output returned through MCP and summarized in chat
Optional workflow templates Reusable multi-step automation that chat can recommend when appropriate

Validation

From an Edwin AI Insight, open chat and verify that the agent can use MCP to retrieve eligible templates, recommend an action, and return execution results to the conversation.

Expected result in Edwin AI chat:

From an Edwin AI Insight, the agent uses MCP to discover eligible templates, recommends an appropriate diagnostic or remediation action, and returns results to chat.

For hands-on testing with a lab environment, see the Demo Guide.

Components

Component Details
Event Stream Optional EDA handoff for a pattern promoted to Walk
EDA source Optional EDA rulebook activation for the promoted Walk pattern
Rulebook Not required for the core Run chat flow
Job Template No automatic escalation template required
Optional implementation pattern Use only if an organization chooses to build a separate integration handoff; it is not required for Run.
MCP integration MCP connection to AAP APIs
MCP capabilities Approved job and workflow template discovery, execution, and status checks
Optional Optional: use approved LogicMonitor integrations for additional exploration where available
Collections logicmonitor.integration, logicmonitor.edwin_ai

Validation and Troubleshooting

Per-Stage Validation Checklist

Stage Validation step Expected result
Walk BGP peer down alert fires in LogicMonitor Edwin Post Ansible EDA Event reaches the configured Event Stream URL
Walk EDA rulebook evaluates alert “Reset BGP Session” job launches targeting correct host
Walk Check LM alert after remediation Alert acknowledged with AAP annotation
Run BGP flapping alert fires in LogicMonitor Edwin AI chat presents an eligible job or workflow recommendation
Run Approve and start an eligible action from chat AAP returns the execution status and output to the same chat conversation
Run Edwin AI Insight and chat show correlated alerts and the likely root cause Edwin recommends an approved diagnostic or remediation template
Run Open an Edwin AI Insight for a complex or ambiguous alert Edwin chat presents the insight, recommendations, and available actions
Run Verify the MCP connection to AAP APIs MCP returns eligible job or workflow templates and execution status
Run Check AAP audit log Chat-initiated and rule-based automation actions are logged in AAP.

Common Issues

Issue Cause Resolution
EDA event not reaching the configured Event Stream Network reachability, incorrect Event Stream URL, invalid action configuration, or activation not running Verify the Event Stream URL and activation in EDA Controller; validate the Edwin action configuration and network reachability.
BGP not re-establishing after reset Hold timer not expired, or underlying link still down Increase wait timeout in playbooks/reset_bgp_session.yml; verify link connectivity on affected device
Edwin AI query returns empty results Incorrect credentials, wrong portal name, or no alerts in lookback window Verify Edwin AI credential type is attached to the job template; check edwin_lookback_window value
Edwin AI timeout during enrichment Network latency or Edwin AI portal outage Review the optional workflow failure path; do not automatically trigger a write-based remediation without the required approval.
MCP connection to AAP APIs cannot reach the configured AAP instance Invalid AAP Base URL, OAuth token, API path prefix, or unavailable Relay Agent Verify the AAP connection settings and OAuth token; confirm API paths and Relay Agent reachability when used
Optional workflow selects an unexpected remediation branch Optional workflow logic does not match the intended root-cause response Review the optional workflow and its data mapping against the expected Edwin AI response structure
Walk rule fires for a scenario that should be handled differently Rulebook rule ordering issue Review rule conditions and ordering; ensure only proven repeatable scenarios are routed through Walk rules.

Maturity Path Summary

Progression

  CRAWL                    WALK                     RUN
  Static mapping,          Repeatable event,        Complex or novel alert,
  manual execution         rule-based trigger        chat and agentic diagnostics

  Envision --> AAP         EDA --> AAP               Edwin AI chat --> AAP
                           (explicit rules)          (via MCP)

  Operator-led             Rule-based execution      Autonomous read-only diagnostics
  Controlled learning      Fast repeatable response  Faster investigation with approval gates

              <--- Pattern promotion over time ---
              Successful Run patterns become Walk rules
              Successful Walk patterns become Crawl mappings

When to Advance

From Crawl to Walk: Advance when operators repeatedly select the same approved playbook for a well-defined LogicMonitor event and the rule, guardrails, and rollback path are understood. The Walk stage promotes that procedure into an EDA rule-based trigger.

From Walk to Run: Advance when an alert needs contextual investigation, conversational analysis, or agentic tool use beyond explicit event rules. Begin with autonomous read-only diagnostics, and retain human approval for every write-based remediation.

The Promotion Pattern

The crawl-walk-run framework is not just an adoption path -- it is an ongoing operational pattern. As the Run stage handles novel alerts and the team observes which patterns recur:

  1. A recurring Run pattern that yields a repeatable, approved action can be promoted to a Walk rule with explicit event conditions and guardrails.
  2. A recurring Walk procedure can be retained as a Crawl mapping for operator-led execution when manual oversight remains the preferred operating model.
  3. The need for agentic escalation narrows as repeatable patterns gain explicit Walk rules, while Crawl preserves the operator-led procedures that should remain human-directed.

ROI Recap

MTTR Reduction

Alert Noise Reduction

Edwin AI’s alert correlation reduces the volume of events that reach the on-call team. Combined with EDA’s event-driven processing, most alerts are handled without human intervention. The team’s attention is focused on high-value work rather than repetitive remediation.

Governance and Audit Readiness

Every remediation action -- whether manually launched from a Crawl mapping, triggered by a Walk rule, or initiated from Run-stage chat through MCP -- flows through AAP’s governance framework. This means:

Suggested Metrics

Track these metrics to quantify the value of each stage:

Metric What it measures Target
MTTR by stage Time from mapped recommendation to execution (Crawl), event to execution (Walk), and investigation to approved action (Run) Set a baseline for Crawl; target a measurable reduction for Walk; track diagnostic and approval time for Run
Remediation success rate Percentage of automated remediations that resolve the issue Track operator-validated Crawl outcomes and success rate for Walk rules
On-call escalation reduction Change in pages to on-call engineers 30-50% reduction after Walk, 50-70% after Run
Alert noise reduction Volume of alerts reaching human operators Measurable decrease as Walk rules expand without sacrificing approval controls
Pattern promotion rate Number of Run patterns promoted to Walk rules or documented as Crawl mappings per quarter Indicates system maturity growth

Extending to Hybrid IT

This guide uses BGP network remediation as the reference scenario because network alerts are concrete, easy to simulate, and immediately relatable to operations teams. However, the crawl-walk-run pattern and every integration surface described here apply to any infrastructure domain that LogicMonitor monitors.

Domain Crawl example Walk example Run example
Server / OS Disk usage alert -> Envision-mapped playbook, manually reviewed and launched High memory alert -> EDA rule triggers an approved diagnostic or remediation workflow Unknown performance degradation -> Edwin AI chat and agents investigate; MCP provides governed access to approved automation
Cloud Cloud budget threshold -> Envision-mapped rightsizing playbook, manually reviewed and launched Latency spike + deployment event -> EDA rules trigger an approved workflow Novel cloud service alert -> Edwin AI chat and agentic investigation
Storage Array health alert -> Envision-mapped diagnostic playbook, manually reviewed and launched I/O latency + firmware event correlation -> EDA rule triggers an approved workflow Cascading storage alerts -> Edwin AI chat and agents triage across arrays

The architecture remains the same: LogicMonitor detects, Edwin AI analyzes, and AAP governs execution. Only the content collections and remediation playbooks change per domain. Teams that start with network can expand to additional domains by adding new rulebook rules, job templates, and the appropriate content collections.

Demos and Labs

Resource Status Description
Demo Guide Available Step-by-step lab setup with ContainerLab, Arista cEOS, incident simulation playbooks, and validation scripts
Video walkthrough Planned Recorded demo showing the crawl-walk-run progression end-to-end
Live demo environment Planned Pre-configured environment with LogicMonitor, AAP 2.6, and all three stages ready to run

Sources and Next Steps

Resources

Resource Link
logicmonitor.integration collection Automation Hub
logicmonitor.edwin_ai collection Automation Hub
MCP integration Configured through Edwin AI
Optional LogicMonitor API integration Available separately
Solution Guides ansible-tmm.github.io/solution-guides

Next Steps

  1. Start with Crawl. In LogicMonitor Envision, map a small set of well-understood network conditions to tested AAP job templates. Have operators review context and launch the mapped automation manually, using RBAC and approvals to establish confidence and collect outcomes.

  2. Expand to Walk. Promote high-confidence Crawl mappings into EDA rules. Configure the Edwin Post Ansible EDA Event action and Event Stream URL, then start with a single repeatable alert type and expand only after validating its governance, outcomes, and rollback path.

  3. Explore Run. Enable Edwin AI chat and agentic diagnostics for conditions that require investigation. Permit autonomous read-only discovery where appropriate, and keep human approval for all write-based remediation initiated through chat or its recommendations via MCP.

The crawl-walk-run progression is designed to meet teams where they are. Each stage delivers immediate value while building the foundation for the next.