The local AI reads, writes, and reviews Ansible playbooks directly on the management server — in real time, with no file sync, no NFS, no SSH scripting.
The entire Ansible repository lives on a dedicated management server. Instead of writing playbooks by hand, the local AI has direct read and write access to the repository via a lightweight API server running on that machine.
From a chat interface, a request such as "add a weekly job that updates the DNS filter" results in the AI reading the existing configuration, generating the correct YAML, having a second model review the change, and writing the file — all without leaving the chat. A Git commit follows after explicit confirmation.
Every write operation is automatically forwarded to a second model for review. The two models are from different architectural families, which matters: the same architecture trained on the same data tends to share the same blind spots. Using a different model as reviewer provides a genuine second opinion rather than a rubber stamp.
The review focuses exclusively on critical issues — hardcoded secrets, automatic reboots, or configurations that would violate known infrastructure rules. Style criticism and best-practice suggestions are suppressed to avoid false positives that would block legitimate changes.
Read operations — listing files, checking status and diffs — run without review. Only writes go through the full approval flow.
A model built for code generation with native tool-calling support. Reads existing files first, shows planned changes, writes only after confirmation.
A model from a different vendor with strong reasoning capability. Only critical security violations trigger rejection — no style opinions, no false positives.
An official open-webui project provides the file access and Git API. The filesystem component is restricted to the Ansible directory only and rejects all other paths.
All sensitive variables in the Ansible repository are encrypted with Ansible Vault before the AI was given write access. The AI can see variable names in the YAML files, but the values are ciphertext. Vault passwords are stored in the job scheduler's key store and never appear in the repository or any chat output.
No new operating system users are created. No SSH keys are touched. Playbooks are committed to Git but never deployed automatically — execution always requires a manual trigger through the scheduler.
The first model tested had a tendency to enter an internal reasoning loop when tool calls were involved, consuming its entire response budget before writing a single line. Switching to a coding-specialist model with native tool-calling support resolved this immediately.
The job scheduler manages the Vault password and SSH key through its own key store and injects them at runtime. If the Ansible configuration file references these files directly, the scheduler's injected values are silently ignored and all playbook runs fail. The configuration file must contain neither reference.
The job scheduler requires a bare Git repository to pull from. A post-commit hook on the working repository updates the bare copy after every commit, so changes made by the AI are immediately visible to the scheduler without any manual step.