AI Agent connector
Use the AI Agent connector to integrate Large Language Models (LLMs) with AI agents to build solutions using agentic orchestration.
About this connector
The AI Agent connector enables AI agents to integrate with an LLM to provide interaction/reasoning capabilities. This connector is designed for use with an ad-hoc sub-process in an agent loop, providing automated tool selection.
For example, use this connector to enable an AI agent to autonomously select and execute tasks within ad-hoc sub-processes by evaluating the current process context and determining the relevant tasks and tools to use in response.
Core features include:
| Feature | Description |
|---|---|
| LLM provider support | Supports a range of model providers, such as Anthropic, AWS Bedrock, Google Gemini, and OpenAI. |
| Memory | Provides conversational/short-term memory handling to enable multi-turn conversations. For example, this allows a user to ask follow-up questions to an AI agent response. |
| Tool calling | Support for an AI agent to interact with tasks within an ad-hoc sub-process, allowing use of all Camunda features such as connectors and user tasks (human-in-the-loop). Automatic tool resolution allows an AI agent to identify the tools available in an ad-hoc sub-process. |
New to agentic orchestration?
- The Build your first AI Agent guide provides a quick introduction to agentic orchestration and how to use the AI Agent Sub-process connector using a blueprint.
- See further resources for examples of how you can use the AI Agent connector.
Prerequisites
Before using this connector, set up an account and authentication details for the LLM model provider and backend you want to use. The required credentials depend on the provider and backend.
See AI Agent model providers for more details.
Choose an implementation
The AI Agent connector family includes two connectors, each with different capabilities, suited for different use cases, and available with a dedicated element template:
AI Agent Sub-process
Recommended for most use cases. Handles tool resolution and the agent loop automatically.
AI Agent Task
Run one-shot LLM calls, or model the agent loop explicitly for full control.
The right implementation depends on your use case.
| Use case | Implementation | Description |
|---|---|---|
| Agentic workflow with automatic tool calling (most use cases) | AI Agent Sub-process | It handles tool resolution and the agent loop automatically. No explicit loop modeling is needed. You must include at least one activity/tool inside the sub-process. |
| Inference tasks that don't require tool calling | AI Agent Task without tools | A single, one-shot LLM call with no ad-hoc sub-process. |
| Intercepting tool calls, for example, to add a human approval step or run PII detection before tool execution | AI Agent Task with tools | Tools are provided by an external ad-hoc sub-process that you model explicitly, giving you full control over the agent loop. This is the most complex configuration. |
The recommended approach for most use cases is to use the AI Agent Sub-process implementation due to the simplified configuration and support for event sub-processes.
If your process models use templates from before 8.10, see upgrade AI Agent element templates to migrate to the latest version.
Compare implementations
The following table summarizes the key configuration differences between the two implementations.
| Configuration field | AI Agent Sub-process | AI Agent Task |
|---|---|---|
| Model provider | Yes | Yes |
| Model | Yes | Yes |
| System prompt | Yes | Yes |
| User prompt | Yes | Yes |
| Tools | Automatic (resolved from activities inside the sub-process) | Optional. Requires ad-hoc sub-process ID and tool call results |
| Agent context (memory) | Optional. Only needed when re-entering the agent for a response follow-up | Required. Must be aligned with the output mapping result variable |
| Limits | Yes | Yes |
| Event handling | Yes | No |
| Response | Yes | Yes |
toolCalls in output | No | Yes. Returned for routing to the ad-hoc sub-process |
| Error handling | Yes | Yes |
| Retries | Yes | Yes |
| Execution listeners | Yes | Yes |
Execution listeners behave differently between the two implementations. On the AI Agent Sub-process, they only run when entering and exiting the ad-hoc sub-process, not on every loop iteration. On the AI Agent Task, they are triggered on every job execution.
Learn the fundamentals
Understand the fundamental concepts of the AI Agent connector, configure the LLM provider, and pass documents to the model.
Execution model
Learn how the AI Agent connector runs, from prompts to responses.
Tool definitions
Understand how tools are resolved and defined for the LLM.
Model providers
Configure the LLM provider and model used by the connector.
Document support
Understand how the connector passes documents and images to the LLM.
Dive into advanced topics
Upgrade the element templates, migrate running process instances, and customize the connector in Self-Managed.
Upgrade AI Agent element templates
Upgrade AI Agent connectors from the legacy element templates to the new ones.
Process instance migration
Review which migration scenarios are supported for running AI agents.
Customize in Self-Managed
Set up an HTTP proxy and extend the connector in Self-Managed.
Explore further resources
Dive into practical resources to see the AI Agent connector in action.
- AI Agent Sub-process example: Model an agent with tool calling and a user feedback loop.
- AI Agent Task example: Model an agent loop explicitly with the AI Agent Task.
- Intelligent by design: A step-by-step guide to AI task agents in Camunda.
- AI Agent Chat Quick Start blueprint on the Camunda Marketplace.
- Working examples in the agentic AI examples GitHub repository.
- The MCP Client connector can be used in combination with the AI Agent connector to connect to tools exposed by Model Context Protocol (MCP) servers.