> For the complete documentation index, see [llms.txt](https://angoor-ai.gitbook.io/angoor-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://angoor-ai.gitbook.io/angoor-ai/basics/configuration/flows/agents-tools-and-sub-flows.md).
# Agents, Tools & Sub-Flows
Three component types let a flow reason, integrate, and reuse logic: Agent steps run AI conversation, Tool steps call external services and GPT-powered logic, and Flow steps invoke another flow as a sub-flow. This page covers all three, then explains how flows start — entry points, triggers, and the payload a flow receives when it fires.
### Agent
An Agent step runs an AI agent inside a path. The agent is a large language model configured with a primary prompt, an instruction prompt, and optional conditional prompts. It can collect input through an attached form, draw on knowledge sources, and generate a response.
You select which agent to run. The agent's form defines the inputs it needs from the user — typically the variables referenced in its primary prompt, any knowledge reference selections, and, if the agent is set to sync with a user group, a user group input.
Several configuration flags shape how the agent behaves. **Sync with user group** keeps the agent aligned to a chosen user group. **Add plugin events** lets the agent emit plugin events. **Send in multiple texts** splits a long response across several messages. **Provide auto-replies** has the agent generate auto-replies. **Restrict one question per message** limits the agent to a single question per turn.
The step outputs the generated response text, optional quick replies if a quick-reply prompt is configured, any plugin events, and the LLM token usage for the call.
### Tool
A Tool step runs a tool inside a path. A tool is either a GPT-powered tool — a large language model driven by prompts — or an API tool that makes HTTP calls to an external service. Tools take input data and return structured results.
You select the tool. For its inputs you bind the prompt variables from the tool's primary prompt, any knowledge reference selections, and custom mappings from flow or path variables to the tool's required inputs. API tools also take the form-field inputs defined in their associated forms.
GPT tools expose operating parameters: the model name and an operating mode (**Creative**, **Balanced**, **Precise**, or **Custom**), the LLM parameters (temperature, top-p, presence penalty, frequency penalty, max tokens), and session settings governing whether the tool uses or saves a cache, blocks the session, or uses conversation history.
The output varies by tool type — a GPT tool returns the model's response, an API tool returns the external service's response — and GPT tools also report token usage.
### Flow (sub-flow)
A Flow step triggers another flow as a nested execution within the current path. This is how you build a piece of logic once and reuse it everywhere, keeping your flows modular.
When the step runs, it creates a new execution context, passes in the input data you specify, runs the target flow, and returns to the parent path when the sub-flow completes.
You select the target flow and supply the input payload: the subscription representing the target flow or sub-flow trigger, and the flow-level variables and context to pass in. You can also specify which sub-flow within the target to trigger — Main Flow, On Setup, On Error, On Control, Pre Flow, or Post Flow.
The step returns whatever the triggered flow produces: its return value, its execution status and any events it generated, and any variables the target flow exports.
### Entry points and triggers
An **entry point** is a node in a flow that listens for incoming events from a specific channel or event type. When a matching event arrives, the flow starts.
An **entry trigger** is the connection between an entry point and a **subscription**. A subscription links a flow to an external channel — WhatsApp, Instagram, Slack — or to an internal event such as a scheduled task. When the subscribed event occurs, the entry trigger fires and starts the flow through the entry point.
The chain reads: **Channel → Subscription → Entry Trigger → Entry Point → Flow Execution.**
A single entry point can carry several entry triggers, one per subscription, so one entry point can respond to events arriving from different channels.
### The trigger payload
When an entry trigger fires, the flow receives a structured payload describing what happened. It contains:
* **platform** — the platform the event came from, such as `whatsapp`, `instagram`, or `slack`.
* **channel\_external\_id** — the external ID of the channel where the event originated.
* **user\_context** — who the user is: their account identifier in the system, their external identity (a phone number or email), whether they are a bot or assistant, and a payload carrying their display name and any custom metadata.
* **session\_context** — the conversation context: the triggering entry trigger's ID, the associated session ID, whether a new session should be forced, and whether this is a test run.
* **message\_payload** — the message itself: a unique message ID and the content and metadata fields, which vary by platform.
* **extra\_context** — any additional contextual data, such as form responses or routing information.
### Handles and connectors
**Handles** are the attachment points on flow nodes where connections begin and end. Each handle belongs to a single node — a step or an entry point — and is indexed so a node can carry more than one. An output handle starts a connector; an input handle receives one.
**Connectors** are the wires. Each connector links a source handle to a target handle, recording the source node, the target node, and the flow it belongs to. A connector is only treated as live once it has a flow association — connectors you draw while editing become active when you save the flow.