AI Agent model providers
Configure the LLM model provider used by the AI Agent connectors. Both the AI Agent Sub-process and AI Agent Task connectors use the same Model provider configuration.
This page documents the native provider configuration shipped with the new AI Agent element templates (Camunda 8.10+). If you are still using the legacy AI Agent element templates, see upgrade from the legacy connector to move to the new element templates and their native providers.
Choose a provider and backend
Start from where your organization already permits LLM traffic to be routed, not from a model's native wire format. Security, data residency, procurement, networking, and audit requirements often determine which backend (Amazon Bedrock, Microsoft Foundry, Google Cloud, or an internal gateway) is actually available to you. Once you know which backends are approved, pick the provider that gives that model the most capable configuration surface:
- Provider selects the wire format the AI Agent uses to talk to the LLM. For example, the Anthropic Messages API, or the OpenAI Responses/Chat Completions API. This determines which provider-specific capabilities are available, such as Anthropic's extended thinking or Gemini's thinking level.
- Backend (where more than one is available for a provider) selects which infrastructure actually serves that API: the vendor's own hosted API, a hyperscaler platform that exposes a compatible endpoint, or a custom/self-hosted endpoint.
These two choices are independent, so the same model family may be available through multiple backends. Within your approved backend, select the provider that matches the model's native wire format (for example, Anthropic for Claude models, even when hosted on Bedrock) rather than a generic hyperscaler provider: it gives you that provider's own configuration surface, such as reasoning/extended thinking and prompt caching, regardless of where the model is actually hosted.
| If your organization requires... | Start with... | Prefer instead when... |
|---|---|---|
| Traffic routed through Amazon Bedrock | AWS Bedrock Converse | Running Claude models: use Anthropic's AWS Bedrock Mantle backend instead, to keep Anthropic-specific configuration. |
| Traffic routed through Microsoft Azure | OpenAI's Microsoft Foundry (Azure) backend | No exception; Foundry is the only approved route for OpenAI models on Azure. |
| Traffic routed through Google Cloud | Google Gemini's Enterprise Agent Platform backend | No exception for Gemini models; use the direct Gemini API only if Google Cloud isn't mandated. |
| No specific cloud mandate | The provider matching the model's native wire format | N/A |
The most capable option within your organization's approved boundary is the correct choice; the native wire format alone doesn't determine it.
Supported providers
Select and configure the model Provider you want to use from the following supported providers. Each section below covers that provider's available backends, authentication, model settings, and provider-specific parameters:
- Anthropic (Claude models, directly or via AWS Bedrock Mantle).
- AWS Bedrock Converse.
- OpenAI (directly, via Microsoft Foundry/Azure, or via a custom OpenAI-compatible endpoint).
- Google Gemini (directly, or via Google Enterprise Agent Platform).
- Custom implementation (Self-Managed/Hybrid only).
Use connector secrets to store credentials and avoid exposing sensitive information directly in the process.
Anthropic
Select this provider to use an Anthropic Claude LLM model. Choose a Backend to specify how to access the Anthropic Messages API:
- Anthropic API
- AWS Bedrock Mantle
- Custom / compatible endpoint
The native, hosted Anthropic API.
| Field | Required | Description |
|---|---|---|
| Anthropic API key | Yes | Your Anthropic account API key for authorization to the Anthropic Messages API. |
Run Anthropic Claude models hosted on Amazon Bedrock while keeping access to Anthropic-specific configuration (reasoning/extended thinking, prompt caching) that the generic AWS Bedrock Converse provider doesn't expose.
| Field | Required | Description |
|---|---|---|
| AWS region | Yes | The AWS region. For example, eu-west-1. |
| Custom endpoint | No | Custom API endpoint for VPC/PrivateLink configurations or other non-standard deployments. Must be the full Bedrock Mantle base URL, including the /anthropic path segment (for example, https://your-vpce-host/anthropic). It replaces the default https://bedrock-mantle.<region>.api.aws/anthropic verbatim. |
| Authentication | Yes | Select the authentication method used to authenticate with AWS: Credentials (access key/secret key), API key, or Default Credentials Chain (Hybrid/Self-Managed only). See Amazon Bedrock connector authentication for details on each method. |
Bedrock Mantle supports a different set of models than Bedrock Runtime, and model availability also varies by AWS Region. Before selecting a model, check Amazon Bedrock endpoint availability and the linked model details for current endpoint and regional support.
Any endpoint implementing the Anthropic Messages API, such as a proxy or gateway in front of Anthropic.
| Field | Required | Description |
|---|---|---|
| API endpoint | Yes | Base URL of the Anthropic-compatible API. /v1/messages is appended automatically. |
| Authentication | No | None, or API key to send an API key with the request. |
Anthropic model and parameters
| Field | Required | Description |
|---|---|---|
| Model | Yes | The model ID to use. See the Claude models overview. |
| Effort | No | Controls how many tokens the model spends when responding, trading thoroughness against speed and cost. Not supported on all models. See the effort documentation. |
| Thinking mode | No | Extended thinking mechanism: enabled uses a manual token budget (older models), adaptive lets the model manage it (newer models), disabled turns it off. Support varies by model. |
| Thinking budget tokens | Depends | Maximum number of tokens the model may spend on extended thinking (minimum 1024). Shown only when Thinking mode is enabled. |
| Thinking display | No | Controls how extended thinking is returned when Thinking mode is adaptive: summarized includes a plain-text summary in the response, omitted leaves it out. |
| Enable prompt caching | No | Enables Anthropic's automatic prompt caching. See the prompt caching documentation. |
| Maximum tokens | No | The maximum number of tokens per request to generate before stopping. |
| Temperature | No | Primary response-variation control from 0 to 1. Lower values favor likely tokens more strongly; higher values increase variation. |
| top P | No | Advanced nucleus-sampling control from 0 to 1. Limits selection to likely tokens whose cumulative probability reaches this value. |
| top K | No | Advanced sampling control configured as a positive integer. Limits selection to this number of the most likely tokens. |
| Timeout | No | Maximum time to wait for the model API call, in ISO-8601 duration format (for example, PT60S). Defaults to three minutes; must not exceed the job worker timeout, or the job may be reassigned while the call is still in progress. Self-Managed Spring connector runtime instances can override the default via the camunda.connector.agenticai.aiagent.chat-model.api.default-timeout property. |
AWS Bedrock Converse
Select this provider to use a model provided by the Amazon Bedrock service through the generic Converse API.
This is the right choice for non-Anthropic model families available on Bedrock. For example, Amazon Nova, Meta Llama, or Mistral models. If you're running Anthropic Claude models on Bedrock, use the Anthropic provider's AWS Bedrock Mantle backend to access Anthropic-specific configuration.
| Field | Required | Description |
|---|---|---|
| AWS region | Yes | The AWS region. For example, eu-west-1. |
| Custom endpoint | No | Custom API endpoint for VPC/PrivateLink configurations or other non-standard deployments. Overrides the default Bedrock Runtime endpoint for the region. |
| Authentication | Yes | Select the authentication method used to authenticate with AWS: Credentials (access key/secret key), API key, or Default Credentials Chain (Hybrid/Self-Managed only). See Amazon Bedrock connector authentication for details on each method. |
Model availability depends on the region and model. See supported foundation models in Amazon Bedrock and access to Amazon Bedrock foundation models.
AWS Bedrock Converse model and parameters
| Field | Required | Description |
|---|---|---|
| Model | Yes | The model ID to use. See inference profile support. |
| Enable prompt caching | No | Enables Bedrock's automatic prompt caching. See the prompt caching documentation. |
| Maximum tokens | No | The maximum number of tokens per request to generate before stopping. Leave unset to use the model default. |
| Temperature | No | Primary response-variation control. Lower values favor likely tokens more strongly; higher values increase variation. Supported ranges vary by model. |
| top P | No | Advanced nucleus-sampling control from 0 to 1. Limits selection to likely tokens whose cumulative probability reaches this value. |
| Timeout | No | Maximum time to wait for the model API call, in ISO-8601 duration format (for example, PT60S). Defaults to three minutes; must not exceed the job worker timeout, or the job may be reassigned while the call is still in progress. Self-Managed Spring connector runtime instances can override the default via the camunda.connector.agenticai.aiagent.chat-model.api.default-timeout property. |
Bedrock Converse doesn't support a Reasoning/Effort configuration or a top K parameter.
OpenAI
Select this provider to use OpenAI models. Two independent choices apply:
- API: which OpenAI API family to use. Responses (default, recommended for new configurations) or Chat Completions.
- Backend: how the API is accessed.
Use Responses by default. It's OpenAI's current API and designed for newer reasoning models. Use Chat Completions if your backend doesn't support Responses, such as an older Microsoft Foundry/Azure OpenAI deployment or a self-hosted OpenAI-compatible backend serving models such as Qwen, Llama, or Mistral through Ollama.
- OpenAI API
- Microsoft Foundry (Azure)
- Custom / compatible endpoint
The native, hosted OpenAI API.
| Field | Required | Description |
|---|---|---|
| OpenAI API key | Yes | Your OpenAI account API key for authorization. |
| Organization ID | No | For members of multiple organizations, the organization ID to use for API requests. See the authentication documentation. |
| Project ID | No | For accounts with multiple projects, the project ID to use for API requests. See the authentication documentation. |
OpenAI models deployed through Microsoft Foundry or Azure OpenAI.
| Field | Required | Description |
|---|---|---|
| API endpoint | Yes | The full resource endpoint, for example https://your-resource.openai.azure.com or a Foundry endpoint such as https://your-resource.services.ai.azure.com. |
| Authentication | Yes | API key, Entra ID: Client credentials, or Entra ID: Managed identity (Hybrid/Self-Managed only). |
Authentication fields per method:
- API key: an API key for the resource, available in the Azure AI Foundry portal.
- Entra ID: Client credentials: registers an application in Microsoft Entra ID and authenticates with it.
- Client ID: the Microsoft Entra application (client) ID.
- Client secret: the application's client secret.
- Tenant ID: the Microsoft Entra tenant (directory) ID.
- Authority host: (optional) overrides the Microsoft Entra authority host, for example for sovereign clouds. Leave unset for the public cloud authority.
- Entra ID: Managed identity (Hybrid/Self-Managed only): authenticates using the environment's managed identity.
- Client ID: (optional) the client ID of a user-assigned managed identity. Leave unset to use the system-assigned managed identity.
To use an OpenAI model deployed through Azure, deploy it first in the Azure AI Foundry portal. See deploy a model in Azure OpenAI, and enter the deployment name in the Model field below.
A multi-replica connectors runtime setup means each replica also acquires and caches its own Entra ID token independently. Expect multiple, parallel credential/token requests against Entra ID under load, rather than a single shared token, and size any Entra ID application throttling limits accordingly.
Connect to any LLM that exposes an OpenAI-compatible API, including open-weight models such as Qwen, Llama, and Mistral, hosted through Ollama or any compatible inference platform.
| Field | Required | Description |
|---|---|---|
| API endpoint | Yes | Base URL of the OpenAI-compatible API. /chat/completions or /responses is appended automatically, depending on the selected API. |
| API key | Yes | The API key for authentication. |
OpenAI model and parameters
| Field | Required | Description |
|---|---|---|
| Model | Yes | The model ID to use. See the OpenAI models documentation. |
| Effort | No | Controls how many tokens the model spends when responding, trading thoroughness against speed and cost. Not supported on all models. See the Responses or Chat Completions API reference. |
| Max output tokens (Responses) / Max completion tokens (Chat Completions) | No | The maximum number of tokens per request to generate before stopping. The field name depends on the selected API. |
| Temperature | No | Primary response-variation control from 0 to 2. Lower values favor likely tokens more strongly; higher values increase variation. |
| top P | No | Advanced nucleus-sampling control from 0 to 1. Limits selection to likely tokens whose cumulative probability reaches this value. |
| Timeout | No | Maximum time to wait for the model API call, in ISO-8601 duration format (for example, PT60S). Defaults to three minutes; must not exceed the job worker timeout, or the job may be reassigned while the call is still in progress. Self-Managed Spring connector runtime instances can override the default via the camunda.connector.agenticai.aiagent.chat-model.api.default-timeout property. |
OpenAI doesn't support a top K parameter. Prompt caching is automatic when the request meets OpenAI's caching requirements and isn't user-configurable.
Google Gemini
Select this provider to use Google's Gemini models. Choose a Backend to specify how to access the API:
- Google Gemini API
- Google Enterprise Agent Platform
The direct, hosted Gemini API.
| Field | Required | Description |
|---|---|---|
| Gemini API key | Yes | Your Google AI Studio API key. |
Gemini models through Google Cloud's Enterprise Agent Platform (formerly Vertex AI).
| Field | Required | Description |
|---|---|---|
| Project ID | Yes | The Google Cloud project ID. |
| Region | Yes | The region where AI inference should take place. |
| Authentication | Yes | Service account credentials (a service account key in JSON format), or Application default credentials (Hybrid/Self-Managed only; uses the default credentials available in the environment; see setting up ADC locally). |
Google Gemini model and parameters
| Field | Required | Description |
|---|---|---|
| Model | Yes | The model ID to use. See the Gemini models documentation. |
| Thinking budget (tokens) | No | Gemini 2.5 models: token budget for extended thinking. -1 = dynamic, 0 = disabled. Mutually exclusive with Thinking level. See the thinking documentation. |
| Thinking level | No | Gemini 3.x models: qualitative thinking effort (default/minimal/low/medium/high). Mutually exclusive with Thinking budget. |
| Maximum tokens | No | The maximum number of tokens to generate before stopping. |
| Temperature | No | Primary response-variation control. Lower values favor likely tokens more strongly; higher values increase variation. Supported ranges vary by model. |
| top P | No | Advanced nucleus-sampling control from 0 to 1. Limits selection to likely tokens whose cumulative probability reaches this value. |
| top K | No | Advanced sampling control configured as a positive integer. Limits selection to this number of the most likely tokens. |
| Timeout | No | Maximum time to wait for the model API call, in ISO-8601 duration format (for example, PT60S). Defaults to three minutes; must not exceed the job worker timeout, or the job may be reassigned while the call is still in progress. Self-Managed Spring connector runtime instances can override the default via the camunda.connector.agenticai.aiagent.chat-model.api.default-timeout property. |
Prompt caching is automatic when the request meets Gemini's caching requirements and isn't user-configurable.
Custom implementation
Available in Self-Managed or hybridHybrid modeHybrid mode, or a hybrid Self-Managed distribution, allows you to run a separate instance of the connectors runtime in a Self-Managed or local fashion. This instance can be attached to either a SaaS cluster, or another Self-Managed cluster with its own connector runtime. deployments only.
Select this provider to use a custom chat model provider implementation that you've registered with the connector runtime, instead of one of the built-in providers above.
| Field | Required | Description |
|---|---|---|
| Provider type | Yes | Identifier for the custom chat model provider. Must match the identifier configured for the custom implementation. |
| Provider parameters | No | Parameters for the custom chat model provider implementation, as a FEEL context. |
| Model | Yes | Identifier of the model to use, interpreted by the custom implementation. |
| Timeout | No | Maximum time to wait for the model API call, in ISO-8601 duration format (for example, PT60S). Defaults to three minutes; must not exceed the job worker timeout, or the job may be reassigned while the call is still in progress. Self-Managed Spring connector runtime instances can override the default via the camunda.connector.agenticai.aiagent.chat-model.api.default-timeout property. |
Implementing a custom provider requires building and registering a chat model provider with your Self-Managed or hybrid connector runtime, similar to how custom conversation storage backends are registered.
Missing a field?
Most backends also provide advanced, low-level customization fields: HTTP headers, query parameters, and body properties. With these fields, you can add or override values in the outgoing HTTP request.
If you don't see these fields on the provider or backend you selected, that's expected for backends with a well-known REST-style API surface, such as the native Anthropic API, OpenAI API, and Google Gemini or Enterprise Agent Platform backends: the fields are reserved for internal or future use and aren't exposed in the properties panel there. For backends without a fixed request structure, such as AWS Bedrock Converse and custom or compatible endpoints, the fields are exposed as editable FEEL map expressions, which you can use to adapt the request to your deployment.