AAP BYOM Provider Comparison 2026: Red Hat AI vs OpenAI vs Azure vs watsonx vs Gemini

Bring Your Own Model (BYOM) is one of the more consequential architectural decisions Red Hat has made for the AI features inside Ansible Automation Platform. Rather than locking customers into a single hosted model, AAP lets platform teams point its AI capabilities at the large language model provider they already trust, already have a contract with, or already run inside their own data center boundary. At Red Hat Tech Day Netherlands 2026 in Bunnik (3 June 2026), Red Hat walked through the current BYOM provider compatibility matrix for AAP 2.7 — and the picture is more nuanced than "pick any model, anywhere." Support differs meaningfully depending on which AI feature you're talking about.

This guide breaks down exactly which providers work with which feature, why the matrix looks the way it does, and how to plan a rollout that doesn't get blocked by a provider gap you didn't know existed.

Two Different AI Features, Two Different Matrices

AAP ships two distinct AI-powered surfaces, and it's a common mistake to assume provider support is uniform across both:

• Intelligent Assistant — the conversational chatbot embedded directly in the AAP web UI. It answers operational questions, helps troubleshoot job failures, and (with BYOK, covered below) can be grounded in your own internal documentation.
• Coding Assistant — the AI pair-programmer built into the Ansible VS Code extension, used while authors are actually writing playbooks, roles, and collections.

See also: Connect the AAP Intelligent Assistant to Azure OpenAI: Setup Guide

The Full BYOM Compatibility Matrix

Red Hat AI is the only provider with full, current support across both features — unsurprising, since it's Red Hat's own model integration and gets first access to every new AI surface as it ships.

IBM watsonx tells the opposite story on each feature. It has zero support in the Intelligent Assistant, yet it was the very first external (non-Red Hat) provider ever supported in the Coding Assistant, arriving back in AAP 2.5 — a full generation ahead of OpenAI and Azure OpenAI, which only reached the Intelligent Assistant in 2.6 and still haven't landed in the Coding Assistant at all.

Google Gemini/Vertex AI is also asymmetric, but flipped versus watsonx: it's already live in the Coding Assistant as of AAP 2.6, while Intelligent Assistant support is still marked Coming Soon.

Why the Matrix Is Asymmetric

None of this is arbitrary. The Coding Assistant and Intelligent Assistant have different integration surfaces, different latency and context requirements, and different certification paths through Red Hat's partner ecosystem. IBM's early Coding Assistant support reflects a close, longstanding IBM/Red Hat product relationship dating to before the AAP 2.5 release. OpenAI and Azure OpenAI, by contrast, prioritized the higher-visibility Intelligent Assistant chatbot experience first, with Coding Assistant support tracked as a near-term roadmap item rather than a current capability. Gemini's path runs the other direction again — VS Code tooling integration landed before the in-UI chatbot connector was finished.

The practical takeaway: don't assume that "supported for AAP AI" means supported everywhere in AAP. Always check the specific feature you're deploying against.

See also: Connect the AAP Intelligent Assistant to Red Hat AI: Setup Guide

Planning a BYOM Rollout

If your organization is standardizing on a specific model provider for compliance, procurement, or data-residency reasons, use this matrix as a gating check before you commit:

• Standardizing on watsonx? You get Coding Assistant support today, but your Intelligent Assistant chatbot will need to run on a different provider (or wait) — watsonx isn't on that roadmap yet as of this matrix.
• Standardizing on OpenAI or Azure OpenAI? Intelligent Assistant is fully ready now. Hold off on Coding Assistant plans until "Coming Soon" resolves to general availability.
• Standardizing on Gemini/Vertex? Coding Assistant is ready now; Intelligent Assistant is not yet.
• Want one provider for everything today? Red Hat AI is currently the only entry in the matrix with both boxes checked.

---
- name: Configure Coding Assistant BYOM endpoint for the VS Code extension
  hosts: localhost
  gather_facts: false
  vars:
    aap_ai_provider: watsonx
    aap_ai_model_endpoint: "https://us-south.ml.cloud.ibm.com/ml/v1"
    aap_ai_project_id: "{{ vault_watsonx_project_id }}"
  tasks:
    - name: Apply Coding Assistant model provider configuration
      ansible.controller.settings:
        settings:
          ANSIBLE_AI_MODEL_MESH_API_TYPE: "{{ aap_ai_provider }}"
          ANSIBLE_AI_MODEL_MESH_API_URL: "{{ aap_ai_model_endpoint }}"
          ANSIBLE_AI_MODEL_MESH_API_KEY: "{{ vault_watsonx_api_key }}"
        controller_host: "{{ aap_controller_host }}"
        controller_username: "{{ aap_controller_username }}"
        controller_password: "{{ vault_controller_password }}"
      no_log: true

Treat provider credentials the way you'd treat any other automation secret: store them in Ansible Vault or your external secrets manager, and never commit them in plaintext to a playbook repository.

BYOK: Grounding the Intelligent Assistant in Your Own Knowledge

Alongside the BYOM matrix, Red Hat also used Tech Day Netherlands 2026 to announce BYOK ("Bring Your Own Knowledge"), currently in Tech Preview. BYOK lets organizations feed their own internal documentation directly into the Intelligent Assistant's retrieval-augmented generation (RAG) pipeline. Instead of the chatbot only knowing generic public Ansible documentation, it can be grounded in your organization's own change-management procedures, network naming conventions, compliance requirements — think PCI-DSS, HIPAA, SOC2 — and internal runbooks.

This matters a great deal for regulated industries: an Intelligent Assistant answer about "how do I roll back this change" becomes far more useful when it reflects your actual change-approval workflow rather than a generic best practice. Because BYOK is Tech Preview, treat it as evaluation-only for now — not something to depend on for production compliance guidance until it reaches general availability.

See also: Ansible azure.azcollection Guide: Machine Learning, App Configuration, and Front Door in AAP 2.7

Key Takeaways

• The Intelligent Assistant and Coding Assistant have separate, non-identical BYOM provider matrices — always verify support per feature, not per provider name alone.
• Red Hat AI is the only provider fully supported (AAP 2.6+) across both features today.
• IBM watsonx was the first external provider supported anywhere in AAP's AI stack (Coding Assistant, AAP 2.5+), but has no Intelligent Assistant support.
• OpenAI and Azure OpenAI are Intelligent Assistant-ready (AAP 2.6+) but Coding Assistant support is still Coming Soon.
• Google Gemini/Vertex AI is Coding Assistant-ready (AAP 2.6+) while Intelligent Assistant support is still Coming Soon.
• BYOK (Tech Preview) lets you ground Intelligent Assistant answers in your own internal policies and runbooks rather than generic documentation alone.