Overview
An Agent is an executable component that combines model instructions, a supported LLM configuration, and tools available to it. It is appropriate for tasks in which the required tool calls depend on the request and information gathered during execution.
Unlike a Flow, an Agent does not describe each step through a predetermined graph of nodes and edges. Its execution proceeds through an iterative model-and-tool loop in which each model response determines whether the Agent returns a result or invokes a tool.
What an Agent Contains
| Agent element | Requirement | Description |
|---|---|---|
| System prompt | Required | Defines the Agent's role, task, instructions, and behavioral boundaries. |
| LLM configuration | Required | Identifies the model configuration used during model invocations. |
| Inputs and outputs | Optional | Declare the named, typed values accepted and produced by the Agent. |
| Tools | Optional | Identify the individual operations available during the model-and-tool loop. |
An Agent does not require tools. It can produce a result using only its instructions, execution input, and configured model.
How an Agent Executes
Agent execution uses a ReAct-style model-and-tool loop:
- The runtime invokes the configured model with the Agent instructions, execution input, relevant model responses and tool results from the current execution, and descriptions of the tools available to the Agent.
- The model returns either a final response or a tool call.
- For a tool call, the runtime verifies that the specified tool is available to the Agent and validates the supplied arguments.
- The Agent invokes the tool, and the runtime adds the tool result to the context for the next model round.
- Execution continues until the model produces a final response or the runtime encounters an execution limit or error.
- The final response is mapped to the Agent output contract.

Description of the illustration Agent Model Invocation and Tool-Use Loop
Advantages of an Agent
| Advantage | Description |
|---|---|
| Dynamic tool selection | The model can select from the tools available to the Agent according to the request and current context. |
| Iterative refinement | The Agent can use tool results in later model invocations to refine its response or invoke another tool. |
| Controlled autonomy | Tool availability, argument validation, database privileges, and runtime limits constrain the operations that can be executed. |
| Reusable behavior | One Agent definition can apply the same instructions, LLM configuration, and available tools to different execution inputs. |
| Model-and-tool visibility | Execution traces can record model invocations and tool activity during an Agent execution. |
These properties fit tasks in which the goal is known but the number or order of information-gathering steps depends on the request and tool results.
Agent and Flow Control
Flow and Agent represent different ways of controlling work:
| Flow | Agent |
|---|---|
| Nodes and control-flow edges define the possible execution paths. | User prompts and model responses determine whether the Agent returns a result or invokes a tool. |
| Branching follows paths declared in the graph. | Each subsequent round can depend on model responses and tool results from the current execution. |
| Tools execute at explicitly defined nodes in the graph. | The model can select from the tools available to the Agent during a model-and-tool round. |
Completion occurs through an EndNode. | Completion occurs when the final response is mapped to the Agent output contract. |
A Flow provides graph-defined orchestration. An Agent provides bounded, goal-directed model-and-tool interaction.