Ansible AI-Driven Automation Architecture: 4 Entry Points for GenAI, API, EDA, and MCP

Red Hat Ansible Automation Platform serves as the trusted execution layer for AI-driven IT operations, providing four distinct entry points for AI-powered automation — each with different levels of human oversight and autonomy.

The 4 Entry Points

┌──────────────┬──────────────┬──────────────┬──────────────┐
│  GenAI       │  Custom AI   │ Observability│  MCP-native  │
│  automation  │  agents      │  tooling     │  assistants  │
│  content     │  Programmatic│  AIOps       │  + agents    │
│              │  LLM tools   │  platforms   │              │
├──────────────┼──────────────┼──────────────┼──────────────┤
│  Web UI      │  API         │  EDA         │  MCP         │
│              │              │              │              │
│  Human in    │  Reason      │  Human in    │  Reason      │
│  loop        │  Act         │  loop        │  Act         │
│              │  Verify      │  Observe     │  Verify      │
│              │              │  Act         │              │
└──────┬───────┴──────┬───────┴──────┬───────┴──────┬───────┘
       │              │              │              │
       └──────────────┴──────────────┴──────────────┘
                              │
              Red Hat Ansible Automation Platform
              Trusted execution across IT infrastructure

1. GenAI-Developed Automation Content (Web UI)

Interface: Web UI Oversight: Human in the loop

The Ansible Lightspeed intelligent assistant in the AAP web interface. Operators use natural language to generate automation content, review it, and approve execution.

Use cases: • Generate playbooks from natural language descriptions • Troubleshoot failed jobs with AI assistance • Platform administration queries

2. Custom AI Agents (API)

Interface: Programmatic API Pattern: Reason → Act → Verify

Custom AI agents and LLM tools interact with AAP programmatically. The agent reasons about what automation to run, executes via the API, and verifies the outcome.

Use cases: • ChatOps bots that trigger automation • CI/CD pipeline AI decision-making • Custom LLM agents with AAP as the execution layer

# Example: AI agent calling AAP API
import requests
response = requests.post(
    "https://aap.example.com/api/v2/job_templates/42/launch/",
    json={"extra_vars": {"target_host": "web-01"}},
    headers={"Authorization": f"Bearer {token}"}
)

3. Observability Tooling / AIOps (EDA)

Interface: Event-Driven Ansible Pattern: Human in the loop → Observe → Act

AIOps platforms (IBM Instana, ServiceNow, Splunk) send events to EDA. The system observes conditions, optionally involves a human for approval, then acts.

Use cases: • Auto-remediation from monitoring alerts • ServiceNow incident → automated response • Splunk ITSI threshold → corrective playbook

# EDA rulebook for AIOps
- name: Auto-remediate high CPU
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: CPU alert from monitoring
      condition: event.payload.alert_type == "high_cpu"
      action:
        run_job_template:
          name: "Remediate High CPU"
          organization: "IT Operations"

4. MCP-Native Assistants + Agents (MCP)

Interface: Model Context Protocol Pattern: Reason → Act → Verify

AI coding assistants (Claude Code, Cursor, Copilot, Gemini CLI, Windsurf, IBM Bob) connect to AAP via MCP servers. The assistant reasons about what to build, uses Ansible dev tools (scaffold, lint, test), and verifies the result.

Use cases: • AI-assisted playbook development in any IDE • Automated content scaffolding and testing • Multi-tool AI workflows with Ansible as execution backend

See also: Ansible Solution Guides: AIOps Partner Walkthroughs for Splunk, ServiceNow, Instana, and EDB

Trust Model

AAP acts as the trusted execution layer — regardless of which entry point triggers automation, the execution happens within AAP's governance framework:

| Guarantee | Description | |---|---| | RBAC enforcement | Every action respects role-based access controls | | Audit trail | All executions are logged with who/what/when | | Credential isolation | Secrets never leave the platform | | Approval workflows | Human approval gates when configured | | Execution environments | Consistent, isolated runtime containers |

Choosing the Right Entry Point

| Scenario | Entry Point | Why | |---|---|---| | Operator building playbooks | Web UI (GenAI) | Interactive, human-reviewed | | CI/CD automation decisions | API | Programmatic, pipeline-integrated | | Monitoring alert response | EDA | Event-driven, real-time | | Developer writing Ansible code | MCP | IDE-native, AI-assisted | | ServiceNow ticket remediation | EDA | Event → automation mapping | | Custom chatbot | API | Flexible, any LLM framework |

See also: Enhanced Kafka Integration for Event-Driven Ansible in AAP 2.6

FAQ

Can I use multiple entry points simultaneously?

Yes. A typical enterprise uses all four: operators in the Web UI, CI/CD via API, monitoring via EDA, and developers via MCP — all executing through the same AAP instance with unified RBAC and audit.

Is "human in the loop" required?

It depends on the entry point and configuration. Web UI and EDA support human approval gates. API and MCP can operate autonomously but can be configured with approval workflows in AAP.

What AIOps platforms are supported with EDA?

AAP provides solution guides for IBM Instana, ServiceNow, and Splunk. Any platform that can send webhooks or events can integrate with EDA.

How does this relate to the MCP server?

The MCP entry point uses the Ansible Dev Tools MCP server (VS Code extension) for development workflows, and the AAP MCP server for platform operations. Both are part of the same architecture.

Related Articles

• Red Hat Ansible Automation Platform 2.7: What's New • Ansible MCP Server Guide • Ansible Dev Tools MCP Server • Ansible Lightspeed AI Provider Compatibility • Red Hat Summit 2026 Highlights