# Bundles

Bundles are vendor- or framework-specific component groups that appear as collapsible sections at the bottom of the Agentic Flow Builder sidebar.

## Agentic Patterns

Multi-agent orchestration components for structured collaboration and task decomposition.

### Agent Capability

Declares an agent’s capabilities for task routing in the orchestration system. Decomposers and orchestrators use these declarations to route work to the right agent.

**Use in a flow**

1. Add one **Agent Capability** node per specialist agent in your pattern.
2. Set **Agent Name**, **Capabilities** (comma-separated tags), **Description**, and **System Prompt**.
3. Select **Model Provider** and **Model ID** for the agent that will run assigned tasks.
4. Connect **Capability Info** to **Agent Capabilities** on **Task Decomposer**, **Task Orchestrator**, or **Collaboration Orchestrator**.

```
Agent Capability (Capability Info) ──► Task Decomposer
Agent Capability (Capability Info) ──► Task Orchestrator
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Agent Name | — | No | Unique name for this agent (used when assigning and reporting tasks). Required. |
| Capabilities | — | No | Comma-separated capability tags (e.g., `account_inquiry, transfers, balance`). Required. |
| Description | — | No | What this agent specializes in; shown to decomposers when planning tasks. |
| System Prompt | You are a helpful assistant. | No | Instructions used when this agent executes an assigned task. Required. |
| Model Provider | — | No | LLM provider for this agent. Refresh to load options. Required. |
| Model ID | — | No | Model used when this agent runs a task. Required. |
| Region Name | — | No | Region where the selected model is available. |
| Model Kwargs | — | Yes | Additional keyword arguments passed to the model. |

**Outputs**

| Output | Description |
| --- | --- |
| Capability Info | Data object with agent name, capability tags, description, system prompt, and model configuration for routing. |

**Limitations**

- **Tag matching** — Task `required_capability` values must align with tags on an **Agent Capability** node (or use `general` as a fallback).
- **Orchestrator dependency** — Capability nodes do not run tasks on their own; wire them into a decomposer and orchestrator to execute work.

---

### Task Decomposer

Decomposes a complex user request into a directed acyclic graph (DAG) of sub-tasks using an LLM. Each sub-task is tagged with a required agent capability and optional dependencies on other tasks.

**Use in a flow**

1. Add a **Task Decomposer** node to the canvas.
2. Wire the user request into **Input Request** (from **Input** or upstream).
3. Connect one or more **Agent Capability** nodes to **Agent Capabilities**.
4. Select **Model Provider** and configure the decomposition model.
5. Connect **Task Graph** to **Task Orchestrator** or **Task Visualization**.

```
Input ──► Task Decomposer ◄── Agent Capability (×N)
Task Decomposer (Task Graph) ──► Task Orchestrator
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Input Request | — | No | The complex request to break into sub-tasks. Required. |
| Agent Capabilities | — | No | Connected **Agent Capability** outputs used for routing tags. |
| Model Provider | Amazon Bedrock | No | LLM provider used for decomposition. Required. |
| Decomposition Prompt | built-in default | Yes | System prompt for the decomposition LLM. Supports `{capabilities}` placeholder. |

**Outputs**

| Output | Description |
| --- | --- |
| Task Graph | Data object containing a flat DAG of tasks with descriptions, capability tags, dependencies, and complexity estimates. |

**Limitations**

- **Capability tags** — Without connected **Agent Capabilities**, all tasks use `general`.
- **LLM output quality** — Invalid JSON falls back to a single task containing the full request.
- **DAG only** — Task graphs must be acyclic; cycles are auto-flattened.

---

### Task Orchestrator

Orchestrates task execution across multiple agents with dependency-aware scheduling, parallel execution, retry logic, automatic agent fallback, and targeted re-decomposition.

**Use in a flow**

1. Add a **Task Orchestrator** node to the canvas.
2. Connect **Task Graph** from **Task Decomposer**.
3. Connect **Agent Capability** nodes to **Agent Capabilities**.
4. Connect **Orchestration Result** to **Output**; optionally wire **Executed Task Graph** to **Task Visualization**.

```
Task Decomposer (Task Graph) ──► Task Orchestrator ◄── Agent Capability (×N)
Task Orchestrator (Orchestration Result) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Task Graph | — | No | Task graph output from **Task Decomposer**. Required. |
| Agent Capabilities | — | No | Connected **Agent Capability** nodes used to match and execute tasks. |
| Max Retries | 2 | Yes | Maximum retries per task before marking it failed. |
| Task Timeout (seconds) | 120 | Yes | Maximum seconds allowed per task execution. |
| Enable Parallel Execution | true | Yes | Run independent ready tasks in parallel. |
| Enable Re-decomposition | true | Yes | Split failed tasks into smaller sub-tasks instead of stopping. |

**Outputs**

| Output | Description |
| --- | --- |
| Orchestration Result | Aggregated message with per-task results, assigned agents, and completion summary. |
| Executed Task Graph | Post-execution task graph with statuses, results, and assigned agents — suitable for **Task Visualization**. |

---

### Hierarchical Decomposer

Breaks a complex user request into a hierarchical goal tree (Goals → Sub-goals → Tasks → Actions) using an LLM.

**Use in a flow**

1. Add a **Hierarchical Decomposer** node to the canvas.
2. Wire the user request into **Input Request**.
3. Connect **Agent Capability** nodes to **Agent Capabilities**.
4. Select **Model Provider** and **Model ID**.
5. Connect **Goal Tree** to **Collaboration Orchestrator**.

```
Input ──► Hierarchical Decomposer ◄── Agent Capability (×N)
Hierarchical Decomposer (Goal Tree) ──► Collaboration Orchestrator
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Input Request | — | No | The complex request to decompose. Required. |
| Agent Capabilities | — | No | Connected **Agent Capability** outputs used when assigning capabilities to leaf tasks. |
| Model Provider | — | No | LLM provider for decomposition. Required. |
| Model ID | — | No | Model used to generate the goal tree. Required. |
| Max Depth | 3 | No | Maximum hierarchy depth (`1` = flat, `4` = full goal → sub-goal → task → action). |
| Output as TaskGraph | false | Yes | When enabled, flattens the goal tree into a task graph for **Collaboration Orchestrator**. |

**Outputs**

| Output | Description |
| --- | --- |
| Goal Tree | Data containing the hierarchical goal tree (or a flat task graph when **Output as TaskGraph** is enabled). |

---

### Collaboration Orchestrator

Executes a task graph or goal tree by assigning each task to a matching agent. Supports **Supervisor** mode and **Peer To Peer** mode.

**Use in a flow**

1. Add a **Collaboration Orchestrator** node to the canvas.
2. Connect **Goal Tree** from **Hierarchical Decomposer** to **Task Graph / Goal Tree**.
3. Connect **Agent Capability** nodes to **Agent Capabilities**.
4. Choose **Collaboration Mode** and connect **Orchestration Result** to **Output**.

```
Hierarchical Decomposer (Goal Tree) ──► Collaboration Orchestrator ◄── Agent Capability (×N)
Collaboration Orchestrator (Orchestration Result) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Task Graph / Goal Tree | — | No | Task graph or goal tree from a decomposer. Required. |
| Agent Capabilities | — | No | Connected **Agent Capability** nodes used to match and run tasks. |
| Collaboration Mode | supervisor | No | `supervisor` (LLM reviews between batches) or `peer_to_peer` (shared message bus). |
| Model Provider | — | No | LLM provider for the supervisor (supervisor mode only). |
| Model ID | — | No | Supervisor model (supervisor mode only). |
| Max Retries | 2 | Yes | Retries per task before marking it failed. |
| Task Timeout (seconds) | 120 | Yes | Maximum seconds per task execution. |
| Enable Parallel Execution | true | Yes | Run independent ready tasks in parallel. |
| Max Peer Messages | 20 | Yes | Maximum messages on the shared bus (peer-to-peer mode only). |

**Outputs**

| Output | Description |
| --- | --- |
| Orchestration Result | Summary message with per-task results and completion counts. |
| Executed Task Graph | Post-execution task graph with statuses, assigned agents, and results. |

---

### Task Visualization

Renders a task graph or goal tree for inspection and monitoring. Output can be formatted as a markdown table or a Mermaid diagram.

**Use in a flow**

1. Add a **Task Visualization** node to the canvas.
2. Connect task graph or goal tree data to **Task Graph**.
3. Choose **Output Format** (`markdown` or `mermaid`).
4. Connect **Visualization** to **Output**.

```
Task Orchestrator (Executed Task Graph) ──► Task Visualization ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Task Graph | — | No | Task graph or goal tree data to visualize. Required. |
| Output Format | markdown | No | `markdown` (table or indented tree) or `mermaid` (flowchart diagram). |

**Outputs**

| Output | Description |
| --- | --- |
| Visualization | Rendered graph as a message. Includes task statuses and per-task result blocks. |

---

## Memories

Memory components provide persistent conversation history storage for agents across sessions.

### PostgreSQL Chat Memory

Stores and retrieves conversation history from a PostgreSQL database for persistent memory across sessions.

**Use in a flow**

1. Add a **PostgreSQL Chat Memory** node to the canvas.
2. Set **Session ID** to scope history to a conversation.
3. Connect **Memory** to an **Agent** memory input or **Message History**.

```
Input (Session ID) ──► PostgreSQL Chat Memory (Memory) ──► Agent
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Table Name | message_history | Yes | PostgreSQL table used to store messages. Created automatically if it does not exist. |
| Session ID | — | Yes | Conversation session key. Falls back to `default` when empty. |
| Enable Retry | false | Yes | Retry database connection failures. |
| Max Retries | 3 | Yes | Maximum retry attempts. |

**Outputs**

| Output | Description |
| --- | --- |
| Memory | A chat message history backed by PostgreSQL. Downstream components use this to load prior turns and persist new messages. |

---

### AWS AgentCore Memory

Stores and retrieves long-term and short-term memory using the AWS AgentCore Memory service.

**Use in a flow**

1. Add an **AWS AgentCore Memory** node to the canvas.
2. Enter **Memory ID** and **Memory Strategy ID** from your AgentCore Memory resource.
3. Select **Region** and **Memory Type**.
4. Connect **AgentCore Memory** to an **Agent** memory input.

```
AWS AgentCore Memory (AgentCore Memory) ──► Agent
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Memory ID | — | No | AgentCore Memory resource ID (e.g., `mem-xxxxxxxxxxxx`). Required. |
| Memory Strategy ID | — | No | Strategy ID for namespace scoping. Required. |
| Region | us-east-1 | No | AWS region (`us-east-1`, `us-west-2`, `eu-west-1`, `ap-northeast-1`, `ap-southeast-1`). |
| Memory Type | Both | No | `Long-term Only`, `Short-term Only`, or `Both`. |
| Actor ID | — | No | Actor scope for memory. Defaults to flow ID when empty. |
| Max Results | 10 | Yes | Maximum records or events to retrieve. |

**Outputs**

| Output | Description |
| --- | --- |
| AgentCore Memory | Memory client wired into an **Agent** for storing and retrieving conversation context. |

---

## Amazon / AWS

AWS components connect to Amazon Bedrock and AWS services for embeddings, document parsing, image generation, code execution, and storage.

### Amazon Bedrock Embeddings

Generates text embeddings using workspace-enabled Amazon Bedrock embedding models.

**Use in a flow**

1. Add an **Amazon Bedrock Embeddings** node to the canvas.
2. Select **Model Provider** and **Model ID**.
3. Connect **Embeddings** to a consumer (e.g., **OpenSearch** or **Knowledge Retrieval**).

```
Input ──► Amazon Bedrock Embeddings (Embeddings) ──► OpenSearch / Knowledge Retrieval
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Input Message | — | No | Upstream message that triggers embedding generation. |
| Model Provider | — | No | Embedding model provider. Refresh to load options. Required. |
| Model ID | — | No | Embedding model to use. Required. |
| Region Name | — | No | Region where the selected model is available. |

**Outputs**

| Output | Description |
| --- | --- |
| Embeddings | An embeddings model instance for vectorizing text in downstream components. |

---

### Amazon Intelligent Document Parser

Extracts structured data from documents and images using Amazon Bedrock Data Automation (BDA). Input files must already exist in S3.

**Use in a flow**

1. Add an **Amazon Intelligent Document Parser** node to the canvas.
2. Connect an **Input Message** with S3 file paths.
3. Select **AWS Bedrock BDA Region Name**.
4. Connect **Parsed Content** downstream.

```
Input (files in S3) ──► Amazon Intelligent Document Parser ──► Agent / Split Text
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Input Message | — | No | Message with S3 file paths to parse. |
| AWS Bedrock BDA Region Name | us-east-1 | No | AWS region for Bedrock Data Automation (`us-east-1` or `us-west-2`). |
| Wait for Completion | true | No | When enabled, waits for BDA to finish before returning. |
| Polling Interval | 5 | Yes | Seconds between status checks while waiting. |
| Max Wait Time | 300 | Yes | Maximum seconds to wait before timing out. |

**Outputs**

| Output | Description |
| --- | --- |
| Parsed Content | Extracted text as Data (combined markdown across pages or image summaries). |

---

### AWS AgentCore Code Interpreter

Executes code using the AWS AgentCore managed code interpreter service. Run Python, JavaScript, or TypeScript in a secure sandbox.

**Use in a flow**

1. Add an **AWS AgentCore Code Interpreter** node to the canvas.
2. Choose **Security** (`sandbox` or `public`).
3. Fill the fields for the action you need (**Code Input**, **Command**, file paths, etc.).
4. Connect the matching output (e.g., **Execute Code**).

```
Input ──► AWS AgentCore Code Interpreter (Execute Code) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Security | sandbox | No | `sandbox` (isolated) or `public` (shared environment). |
| Code Input | — | No | Code to run synchronously or in the background. |
| Language | python | No | `python`, `javascript`, or `typescript`. |
| Auto Manage Session | true | Yes | Automatically start and reuse a session. |

**Outputs**

| Output | Description |
| --- | --- |
| Execute Code | Run **Code Input** synchronously and return stdout/stderr. |
| Execute Command | Run a shell **Command** synchronously. |
| Write / Read / List / Remove Files | File management operations within the sandbox. |
| Start Background Code / Command | Run code or a command as a background task; returns a `task_id`. |
| Get Task / Stop Task | Check status of or cancel a background task. |

---

### AWS Nova Image Generation

Generates images using Amazon Nova (and compatible Titan) models via Amazon Bedrock.

**Use in a flow**

1. Add an **AWS Nova Image Generation** node to the canvas.
2. Write a **Prompt** describing the image.
3. Select **Model Provider** and **Model ID**.
4. Connect **Message** to **Output** or downstream steps.

```
Prompt / Input ──► AWS Nova Image Generation (Message) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Prompt | — | No | Text description of the image to generate. Required. |
| Model Provider | — | No | Image model provider. Required. |
| Model ID | — | No | Nova or Titan image model. Required. |
| Width | 1024 | No | Image width: `512` or `1024` pixels. |
| Height | 1024 | No | Image height: `512` or `1024` pixels. |
| Number of Images | 1 | Yes | How many images to generate (1–5). |
| CFG Scale | 8.0 | Yes | Prompt adherence (1.0–20.0). |

**Outputs**

| Output | Description |
| --- | --- |
| Message | Result message with generated image file paths attached. |

---

### AWS Stability Image Generation

Generates images using Stability AI models via Amazon Bedrock.

**Use in a flow**

1. Add an **AWS Stability Image Generation** node to the canvas.
2. Write a **Prompt**, select **Model Provider** and **Model ID**, set **Aspect Ratio**.
3. Connect **Message** to **Output** or downstream steps.

```
Prompt / Input ──► AWS Stability Image Generation (Message) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Prompt | — | No | Text description of the image to generate. Required. |
| Model Provider | — | No | Image model provider. Required. |
| Model ID | — | No | Stability image model. Required. |
| Aspect Ratio | 1:1 | No | `1:1`, `16:9`, or `9:16`. |
| Output Format | png | Yes | `png` or `jpeg`. |

**Outputs**

| Output | Description |
| --- | --- |
| Message | Result message with generated image file paths attached. |

---

### S3 Bucket Uploader

Uploads files to a specified Amazon S3 bucket.

**Use in a flow**

1. Add an **S3 Bucket Uploader** node to the canvas.
2. Enter **AWS Access Key ID**, **AWS Secret Key**, and **Bucket Name**.
3. Choose a **Strategy for file upload**.
4. Connect **Data Inputs** from upstream file or data components.

```
File ──► S3 Bucket Uploader (Writes to AWS Bucket) ──► Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| AWS Access Key ID | — | No | AWS access key for the target bucket. Required. |
| AWS Secret Key | — | No | AWS secret key for the target bucket. Required. |
| Bucket Name | — | No | Destination S3 bucket name. Required. |
| Strategy for file upload | Store Data | No | `Store Data` (upload parsed text) or `Store Original File` (upload binary file). Required. |
| Data Inputs | — | No | One or more Data objects with file paths and content. Required. |

**Outputs**

| Output | Description |
| --- | --- |
| Writes to AWS Bucket | Completes the upload operation. |

---

## LangChain

LangChain components provide character-based text splitting, natural-language CSV and SQL querying, database connections, and tool-calling agent patterns.

### CharacterTextSplitter

Splits text into chunks using a character-based splitter.

**Use in a flow**

1. Add a **CharacterTextSplitter** node to the canvas.
2. Connect text or document data to **Input**.
3. Set **Chunk Size**, **Chunk Overlap**, and optionally **Separator**.
4. Connect the **Data** output to a vector store or embedding component.

```
File / Document Loader ──► CharacterTextSplitter ──► Embeddings / Vector Store
```

**Parameters**

| Parameter | Default | Description |
| --- | --- | --- |
| Chunk Size | 1000 | Maximum length of each chunk in characters. |
| Chunk Overlap | 200 | Number of overlapping characters between consecutive chunks. |
| Input | — | The text or documents to split. |
| Separator | \n\n | Characters to split on. |

**Outputs**

| Output | Description |
| --- | --- |
| Data | The split text chunks as data objects. |

---

### CSV Agent

A LangChain agent that reads and queries CSV files using natural language.

**Use in a flow**

1. Add a **CSV Agent** node to the canvas.
2. Connect a **Language Model** to the agent.
3. Provide a **File Path** (upload a CSV or connect a path).
4. Enter your question in **Text**.
5. Connect **Response** to **Chat Output** or the next step.

```
Language Model ──► CSV Agent ──► Chat Output
CSV file ──► CSV Agent (File Path)
```

**Parameters**

| Parameter | Required | Description |
| --- | --- | --- |
| Language Model | Yes | The LLM used to interpret questions and query the CSV. |
| File Path | Yes | The CSV file to analyze. |
| Text | Yes | The natural-language question to ask about the CSV data. |

**Outputs**

| Output | Description |
| --- | --- |
| Response | The agent’s answer as a message. |

---

### SQL Agent

A LangChain agent that queries a SQL database using natural language.

**Use in a flow**

1. Add a **SQL Agent** node to the canvas.
2. Connect a **Language Model** to the agent.
3. Enter the **Database URI**.
4. Provide your question via **Input**.
5. Connect **Response** to **Chat Output** or the next step.

```
Language Model ──► SQL Agent ──► Chat Output
Chat Input ──► SQL Agent (Input)
```

**Parameters**

| Parameter | Required | Description |
| --- | --- | --- |
| Language Model | Yes | The LLM used to interpret questions and generate SQL. |
| Database URI | Yes | Connection string for the SQL database (e.g., `postgresql://user:pass@host:5432/dbname`). |
| Input | Yes | The natural-language question to ask about the database. |

**Outputs**

| Output | Description |
| --- | --- |
| Response | The agent’s answer as a message. |

---

### SQLDatabase

Connects to a SQL database and exposes it as a connection object for LangChain components.

> **Note**
>
> **SQL Agent vs SQLDatabase** — **SQL Agent** takes a **Database URI** string directly. Use **SQLDatabase** only when another component expects a SQLDatabase connection object.

**Parameters**

| Parameter | Description |
| --- | --- |
| URI | The database connection string. Must be a valid SQLAlchemy-compatible URI. Required. |

**Outputs**

| Output | Description |
| --- | --- |
| SQLDatabase | A LangChain SQL database connection object. |

---

### Tool Calling Agent

A LangChain agent that uses tool-calling capable language models to reason and act.

**Use in a flow**

1. Add a **Tool Calling Agent** node to the canvas.
2. Connect a **Language Model** that supports native tool calling.
3. Connect tool sources (e.g., **MCP Client**) to **Tools**.
4. Provide the user’s message via **Input**.
5. Connect **Response** to **Chat Output** or the next step.

```
Chat Input ──► Tool Calling Agent ──► Chat Output
Language Model ──► Tool Calling Agent
MCP Client (Tools) ──► Tool Calling Agent
```

**Parameters**

| Parameter | Required | Description |
| --- | --- | --- |
| Language Model | Yes | The LLM the agent uses. Must support native tool calling. |
| Tools | No | Tools the agent can call. |
| Input | Yes | The user’s message for the agent to process. |
| System Prompt | No | Instructions that guide the agent’s behavior. |

**Outputs**

| Output | Description |
| --- | --- |
| Response | The agent’s final answer as a message. |

---

### XML Agent *(Beta)*

A LangChain-based agent that processes XML-structured inputs and tool responses.

**Use in a flow**

1. Add an **XML Agent** node to the canvas.
2. Connect a **Language Model** to the agent.
3. Connect tool sources to **Tools**.
4. Provide the user’s message via **Input**.
5. Connect **Response** to **Chat Output** or the next step.

```
Chat Input ──► XML Agent ──► Chat Output
Language Model ──► XML Agent
```

**Parameters**

| Parameter | Required | Description |
| --- | --- | --- |
| Language Model | Yes | The LLM the agent uses for reasoning and responses. |
| Tools | No | Tools the agent can call. |
| Input | Yes | The user’s message for the agent to process. |
| System Prompt | No | Instructions including `{tools}`, `{input}`, and `{agent_scratchpad}` placeholders. |
| Prompt | No | The user-message template. Must include `{input}`. |

**Outputs**

| Output | Description |
| --- | --- |
| Response | The agent’s final answer as a message. |

**Limitations**

- **Beta** — Behavior and fields may change.
- **XML tool format** — The model must follow the XML tag pattern in the system prompt for reliable tool use.

---

## MCP

MCP bundle components connect the flow to MCP (Model Context Protocol) servers. These are the same components as in the main Integrations category, listed here for sidebar discoverability.

- [MCP Client](integrations.html#mcp-client) — Connects to an MCP server configured in your workspace.
- [Public MCP Client](integrations.html#public-mcp-client) — Connects to any publicly accessible MCP server by URL.

See [Integrations](integrations.html) for full parameter reference.

---

## Red Hat

### Red-Hat OpenAI Chat

Calls a Red Hat–hosted OpenAI-compatible chat endpoint and returns the response.

**Use in a flow**

1. Add a **Red-Hat OpenAI Chat** node to the canvas.
2. Fill in **Endpoint URL**, **Bearer Token**, and **Model**.
3. Provide **Message Content** directly or connect from upstream.
4. Connect **Response** to **Chat Output** or the next step.

```
Chat Input / Prompt ──► Red-Hat OpenAI Chat ──► Chat Output
```

**Parameters**

| Parameter | Default | Hidden | Description |
| --- | --- | --- | --- |
| Endpoint URL | — | No | The chat completions URL for your Red Hat OpenShift AI deployment. Required. |
| Bearer Token | — | No | Authentication token. Enter the token only — do not include the `Bearer` prefix. Required. |
| Model | gpt-oss-20b | No | The model name to use for the chat request. Required. |
| Message Content | — | No | The user message to send to the model. Required. |
| System Message | You are a helpful assistant | Yes | Instructions that set the assistant’s behavior. |
| Stream | false | Yes | When enabled, the response is streamed back incrementally. |
| Timeout | 200 | Yes | How long to wait for a response, in seconds. |

**Outputs**

| Output | Description |
| --- | --- |
| Response | The model’s reply as a message. |

**Limitations**

- **Red Hat endpoint required** — You must have a valid OpenShift AI endpoint URL and bearer token.
- **OpenAI-compatible API** — The endpoint must support the standard chat completions request format.