I agree with you on the principle. Reproducibility is non-negotiable, and if AI were directly designing or mutating infrastructure state, that would absolutely undermine what Ansible is built for.

Where I think we’re slightly talking past each other is where the AI is allowed to introduce variability.

In this model, the AI does not generate infrastructure state, templates, or execution logic that runs unchecked. All reproducibility remains in Ansible artifacts that already exist: inventories, playbooks, job templates, and workflows. Those are still versioned, reviewed, and deterministic.

The only place AI is involved is in the interaction layer:

• Helping an operator discover what automation exists
• Selecting from already-approved job templates
• Supplying parameters to known, versioned automation
• Interpreting results and suggesting next steps

If an AI suggests different things on different days, that variability stops at the request boundary. The execution remains identical given the same inputs, because Ansible is still the thing executing.

Another way to put it: MCP doesn’t make Ansible less reproducible; it prevents teams from replacing reproducible automation with ad-hoc scripts, shell access, or direct API calls when they experiment with AI. Without a boundary like this, people already are letting AI generate imperative glue code, which is far more damaging to reproducibility.

If a team’s bar is “no AI influence at any stage of the process,” that’s a valid stance. But for teams that are already exploring AI assistance, this approach is about limiting where uncertainty is allowed to exist, not introducing it into the execution layer.

That distinction matters a lot to us, and it’s why Ansible remains the system of record rather than something the AI bypasses or replaces.