AnsibleByExample

Ansible BYOM Providers Compared: Choosing a Backend for AAP AI Features

Beginner
2024-01-014By Luca Berton

Lesson 1 of 14 in AAP and AWX

Ansible Automation Platform and AWX — full curriculum
  1. 1. Understanding AWX and AAP Architecture
  2. 2. Installing AWX with the AWX Operator
  3. 3. Projects: Connecting Git Repositories
  4. 4. Inventories and Inventory Sources
  5. 5. Credentials and Credential Types
  6. 6. Execution Environments with ansible-builder
  7. 7. Job Templates: Running Playbooks as a Team
  8. 8. Surveys: Parameterized Self-Service Automation
  9. 9. Schedules and Notifications
  10. 10. Workflows: Chaining Automation with Approval Nodes
  11. 11. RBAC: Organizations, Teams and Roles
  12. 12. Automating the Platform: API, awx CLI and ansible.controller Collection
  13. 13. Troubleshooting Jobs and Platform Operations
  14. 14. Capstone: Production Workflow with Approval and Rollback
View path overview →

AAP 2.7 lets you Bring Your Own Model (BYOM) to power its AI features, but not every provider is wired up to both the Intelligent Assistant and the Coding Assistant yet. Red Hat laid out the full compatibility matrix at Red Hat Tech Day Netherlands 2026 in Bunnik — here it is, plus how to point each feature at a provider once it's supported.

---
# playbook: configure_byom_provider.yml
# Sets the Intelligent Assistant's model backend via the AAP Gateway API.
# Run against a host with network access to your AAP controller node.
- name: Configure BYOM provider for AAP Intelligent Assistant
  hosts: localhost
  gather_facts: false
  vars:
    aap_gateway_url: "https://aap.example.com"
    ai_provider: "azure_openai"          # red_hat_ai | openai | azure_openai
    ai_model_name: "gpt-4o-aap-assistant"
    ai_endpoint: "https://my-org.openai.azure.com"
  tasks:
    - name: Register BYOM provider credential
      ansible.builtin.uri:
        url: "{{ aap_gateway_url }}/api/gateway/v1/ai_providers/"
        method: POST
        headers:
          Authorization: "Bearer {{ aap_gateway_token }}"
        body_format: json
        body:
          name: "intelligent-assistant-{{ ai_provider }}"
          provider_type: "{{ ai_provider }}"
          endpoint: "{{ ai_endpoint }}"
          model: "{{ ai_model_name }}"
          feature: "intelligent_assistant"
        status_code: [200, 201]
      register: byom_result

    - name: Show registration result
      ansible.builtin.debug:
        var: byom_result.json

What this does

The play POSTs a BYOM provider definition to the AAP Gateway API, telling the Intelligent Assistant which external model to use and where to reach it. The provider_type and feature fields are the two values you check against the compatibility matrix below before running this against a real environment — pointing an unsupported provider/feature pair at the API will simply be rejected by the Gateway.

The compatibility matrix

As of AAP 2.7, per Red Hat Tech Day Netherlands 2026:

ProviderIntelligent Assistant (chatbot in AAP UI)Coding Assistant (Ansible VS Code extension)
Red Hat AISupported (AAP 2.6+)Supported (AAP 2.6+)
OpenAISupported (AAP 2.6+)Coming Soon
Azure OpenAISupported (AAP 2.6+)Coming Soon
IBM watsonxNot supportedSupported (AAP 2.5+)
Google Gemini / Vertex AIComing SoonSupported (AAP 2.6+)

Two things stand out. First, Red Hat AI is the only provider that already covers both features end to end — it's the safest default if you want one backend for everything. Second, watsonx and OpenAI/Azure OpenAI are currently mirror images of each other: watsonx was actually the first external provider ever supported for BYOM (Coding Assistant, AAP 2.5), but it has no Intelligent Assistant support at all, while OpenAI and Azure OpenAI cover the chatbot but not yet the IDE extension.

Notes / Gotchas

  • Check the feature, not just the provider. A provider being "BYOM-supported" in AAP doesn't mean both AI surfaces accept it — the matrix above is per-feature, and this is the most common misconfiguration.
  • Gemini/Vertex is asymmetric today. It already backs the Coding Assistant (AAP 2.6+) but is only "Coming Soon" for the Intelligent Assistant — don't wire it into chatbot configs yet.
  • Minimum AAP versions differ by pairing. watsonx's Coding Assistant support requires only AAP 2.5+; every other supported pairing requires AAP 2.6+. Verify your platform version before troubleshooting a "provider not found" error.
  • BYOK is separate from BYOM. Also announced at the same event, Bring Your Own Knowledge (Tech Preview) lets you feed the Intelligent Assistant's RAG pipeline your own change-management procedures, naming conventions, compliance requirements (PCI-DSS, HIPAA, SOC2), and runbooks — it grounds answers in your internal docs on top of whichever BYOM model you've configured, rather than changing which model answers.
  • Credentials and endpoints for each provider are still managed as standard AAP credential objects; the BYOM registration above only tells the feature which credential/model to call.

Pick Red Hat AI if you want one backend across both AI features today; otherwise match your provider choice to the specific feature you're enabling, and revisit the matrix as the "Coming Soon" entries land in future AAP releases.

References

All Tutorials