As more teams experiment with AI-assisted development, one of the more interesting shifts is moving from “AI that generates code” to “AI that can safely interact with real systems.”
A pattern we’ve been working with is connecting AI tools to Ansible Automation Platform (AAP) through a Model Context Protocol (MCP) server, allowing agents to query and execute automation in a governed way.
This walkthrough from Alex Walczyk shows how to do exactly that using IBM Bob, an AI-native IDE:
What’s actually happening under the hood
At a high level, IBM Bob acts as the AI interaction layer, while AAP remains the execution and governance layer.
The MCP server exposes structured endpoints that the AI can use, such as:
- Job template discovery
- Inventory queries
- Job execution
- Result retrieval
Instead of giving an LLM direct access to infrastructure, you’re constraining it to:
- Predefined automation (playbooks, workflows)
- RBAC controls already defined in AAP
- Auditable job execution paths
So the AI is not “doing whatever it wants” — it’s selecting and parameterizing approved automation artifacts.
Why MCP is useful here
Without MCP (or a similar abstraction), integrating AI with automation typically turns into:
- Ad hoc API calls
- Custom glue code
- Limited reuse of existing automation
MCP standardizes that interaction model:
- The AI queries capabilities (what job templates exist, what inputs they take)
- It selects an action
- It executes through a controlled interface
This creates a cleaner separation:
- AI handles reasoning and interaction
- AAP handles execution, consistency, and auditability
Example flow
A typical interaction might look like:
- User provides intent in natural language
“Restart the web tier in production”
- IBM Bob (via MCP):
- Queries available job templates
- Identifies the appropriate restart workflow
- Prompts for required parameters (if needed)
- The job is launched through AAP:
- Uses existing inventories and credentials
- Follows RBAC and approval flows (if configured)
- Results are returned to the AI:
- Job status
- Output/logs
- Any follow-up actions
What this is (and isn’t)
This is:
- A way to reuse your existing Ansible investments
- A structured interface for AI → automation interaction
- A pattern for introducing AI without bypassing governance
This is not:
- Letting AI generate and run arbitrary playbooks in production
- Replacing AAP’s control plane
- Removing the need for approval, RBAC, or audit trails
Where this gets interesting
Once you have this pattern in place, you can start layering in:
- Event-driven triggers (EDA → AI → AAP workflows)
- Observability signals feeding AI reasoning
- More complex multi-step workflows coordinated by an agent
But the key point is this:
You’re not rebuilding automation for AI, you’re connecting AI to the automation you already trust.