Agentic AI
Introduction
The Agentic AI plugin adds AI-powered capabilities to your workflows. It connects to large language models (LLMs) from providers like OpenAI, Azure OpenAI, Google Gemini, Google Vertex AI, and AWS Bedrock. The plugin includes five steps — AI Agent, Classifier, Knowledge Base, LLM, and Summarizer — that help your workflows understand text, sort information into categories, search documents, generate responses, and create summaries. Use this plugin when your workflows need to process unstructured data, make decisions based on content, or produce written output without manual effort.
Common Tab Details: LLM Setting tab
The following table explains the LLM Settings tab and its field details, which is a common configuration available across steps.
| No. | Field Name | Description |
|---|---|---|
| LLM Settings tab: | The tab allows you to configure the Large Language Model (LLM) settings right from selecting the provider and specific model which will be used for reasoning and execution. This configuration establishes the "intelligence" layer used to interpret prompts and orchestrate tool usage. This is the mandatory tab. | |
| 1 | LLM provider | Select the LLM provider from the list. The LLM platform used to interpret prompts and orchestrate tool usage. The selected provider dictates available LLM models and supported properties (such as reasoning effort or response format). Note: Changing the LLM Provider refreshes the available properties. You will need to reconfigure dependent fields to match the selected provider's schema. Available LLM providers: - OpenAI - Azure OpenAI - Google Vertex AI (Only Gemini) - Google Gemini - AWS Bedrock - Anthropic Default value: OpenAI. The field accepts variable/static values, and the field is mandatory. |
| 2 | Model | Select the model to use for reasoning and task execution. The model determines the speed, cost, and intelligence level of the agent. The field accepts variable or static values, and the field is mandatory. Notes: - The list of available models populates dynamically based on the selected LLM Provider. - The field is enabled only for- OpenAI, Google Vertex AI, Google Gemini and AWS Bedrock. - For Azure OpenAI provider, the model name should be given against the deploymentName property. |
| 3 | Test | Click Test to validate the configurations. This action initiates a connectivity check to verify authentication and API accessibility, ensuring the agent can successfully interact with the LLM provider before runtime. |
| LLM Settings table | Use the table to define specific configuration parameters (such as temperature, max_tokens top_p, top_k, and so on.) that control the model's behavior and its output. | |
| 1.a | Property | Select the configuration parameter to define. The available properties vary based on the selected LLM Provider and the model. Notes: -Default Properties: Essential properties populate automatically based on the selected provider. For details, see LLM Configuration: Default Property table - Add Properties: To configure additional parameters, select an empty cell in the Property column and choose a value from the list. For property details see LLM Configuration: Additional Properties. |
| 1.b | Value | Specify the value for the selected property. Ensure the value adheres to the data type expected by the property (for example, an integer for max_tokens or a float for temperature). The field accepts variable or static value. |
| LLM Headers tab | Use this tab to configure custom HTTP headers required for the LLM API request. This is typically used for advanced authentication schemes, routing calls through AE Gateways, ESB points, organization IDs, custom telemetry tracking, and so on. | |
| 1.a | Header Key | Specify the name of the HTTP header field (for example, X-Org-ID or Authorization). |
| 1.b | Header Value | Specify the value corresponding to the header key. |
Retry and Timeout Behavior:
When a request to the configured LLM provider fails, the system retries the request automatically. The following table lists the retry properties:
| Property | Description | Default Value |
|---|---|---|
| retryAttempts | Number of retries after the initial request | 2 |
| readTimeout | Maximum time allowed for each attempt (the initial request and every retry) | 2 seconds |
| Connection timeout | Maximum time allowed for each attempt (the initial request and every retry) | 2 seconds |
Maximum total request time:
Maximum total request time = (retryAttempts + 1) × readTimeout + total retry delay The + 1 accounts for the initial request.
Example:
If:
- retryAttempts = 2
- readTimeout = 2 seconds
- Retry delays are 1 second and 2 seconds
Then:
(2 + 1) × 2s + (1s + 2s) = 9s
Therefore, the request can take up to 9 seconds in the worst-case scenario, excluding any additional processing or network overhead outside the configured timeout.
Note: The total retry delay behaviour is different for each LLM providers so total request timeout may vary.
Retry delay by provider: Retry delay is the time waited between consecutive retry attempts. The delay may increase based on the configured backoff strategy. Retry delay behaviour differs by provider, so the maximum total request time varies.