Rocannon and the Ansible AI ecosystem
Several AI-assisted Ansible tools exist. Rocannon doesn't compete with any of them. Each fills a different role at a different point in the automation lifecycle.
| Tool | What it does | Relationship to Rocannon |
|---|---|---|
| Red Hat Ansible Lightspeed | Generates Ansible task suggestions and playbook drafts from natural language inside IDEs | Writes automation. Rocannon runs it interactively. The two chain together. |
| Ansible Automation Platform (AAP) | Enterprise job scheduling, approval workflows, RBAC, credential management | Runs automation at scale and on a schedule. Rocannon is for exploration and diagnosis before automation is formalized. |
| AAP MCP server | MCP server that triggers AAP job templates | Triggers predefined jobs. Rocannon exposes individual module tools. Both are MCP servers at different layers. |
| IBM Ansible Lightspeed for Z | Lightspeed variant tuned for IBM Z collections and z/OS-specific content | Generates z/OS Ansible content. Rocannon runs it against a real system. |
| IBM Watson Code Assistant for Z (WCA4Z) | AI for COBOL, PL/I, and application modernization on z/OS | Application layer. Rocannon is infrastructure layer. No overlap. |
Red Hat Ansible Lightspeed
Lightspeed generates Ansible content: task suggestions, playbook drafts, and role templates from natural language inside VS Code and other supported editors. It writes automation; it doesn't run it against a live inventory.
The two tools chain naturally. Lightspeed generates candidate tasks for a given goal. Rocannon runs them against a real inventory to verify the result, with check mode to preview what would change before applying anything. Once a session works, commit_session packages the successful steps into a standard playbook.
Ansible Automation Platform (AAP)
AAP is Red Hat's enterprise automation platform: job scheduling, approval gates, RBAC, credential vaulting, audit trails. It's built for production automation that runs on a schedule or gets triggered by a pipeline.
Rocannon's role is earlier in that workflow. You use it to explore, diagnose, and prototype. Once a session works reliably, commit_session writes a standard ansible-playbook-compatible YAML file. That file goes into AAP as a job template. Rocannon is not in the loop for subsequent runs.
The AAP MCP server
The open-source ansible/aap-mcp-server lets MCP clients trigger AAP job templates. It's the right tool for "run job template X against inventory group Y"; it talks to AAP's API rather than to Ansible modules directly.
Both are MCP servers, but they operate at different layers. Rocannon exposes individual module-level tools against a live inventory. The AAP MCP server triggers predefined jobs registered in AAP. Running them side by side makes sense: use Rocannon to prototype and diagnose, then use the AAP MCP server to trigger the formalized job template from the same agent session.
IBM Ansible Lightspeed for Z
IBM's Lightspeed variant, tuned for IBM Z collections and z/OS-specific automation tasks. Like the Red Hat version, it generates Ansible content rather than executing it. Rocannon provides the execution layer for what it generates, with typed module tools against a real z/OS inventory.
IBM Watson Code Assistant for Z (WCA4Z)
WCA4Z targets the application layer: COBOL modernization, PL/I explanation, and application transformation for z/OS workloads. Rocannon targets the infrastructure layer: data set management, job submission, and system configuration through ibm.ibm_zos_core. The two address different problems and don't overlap.
The gap none of these fill
None of the tools above let an LLM call an individual Ansible module against a live inventory as a typed MCP tool, see the structured result, and incorporate it into the next step of the same session. That's what Rocannon does: the interactive exploration and diagnosis layer, before automation gets committed to a formal pipeline.
The intended position in a mature setup: Lightspeed writes playbook drafts, Rocannon explores and verifies interactively, commit_session promotes the working session to a playbook, AAP runs it at scale, and the AAP MCP server triggers it from agent sessions. These aren't competing positions in the stack.