> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trymaitai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Execution Mode
> How your agent processes each request: full reasoning loop or single-step routing
Every agent has an **Execution Mode** that determines how it handles each request. You choose it when you [create the agent](/build/agents/create_agent), and you can change it at any time from the agent's **Configuration** tab in the Portal.
Execution mode is part of the agent's identity. It is **not** set per-request. The `AgentRequest` no longer accepts an `execution_mode` parameter; if you were passing it from code, remove it and configure the mode on the agent instead.
## Reasoning: multi-step loop (default)
The agent runs the full reasoning loop, powered by Cortex, Maitai's event-driven orchestration engine:
1. **Orchestrate**: an LLM planner reviews the request, the agent's [state](/build/agents/agent_state), and the available capabilities, then picks the next action.
2. **Act**: the chosen capability runs: an API call, LLM call, workflow, webhook registration, or sub-agent delegation.
3. **Process**: the result is distilled into a rolling summary, findings, and state updates.
4. **Repeat or respond**: the loop continues until the agent has what it needs, then it composes the final response.
Every LLM step in this loop is visible and configurable on the Configuration tab, see [Agent Flow Steps](/build/agents/agent_flow).
Choose `reasoning` when:
* Requests take **multiple actions** to complete (gather data, act on it, synthesize an answer)
* The agent **delegates to sub-agents**
* The agent needs to **pause on webhooks** and resume when an external system calls back
* Task completion matters more than minimal latency
## Route: single-step routing
The agent sends each request **directly to a single capability** and returns that capability's result. There is no planning loop: one routing decision, one action, one response.
To keep responses fast without giving up context gathering, the router can also select **one background action** to run in parallel with the routed capability. Background results are never shown to the user; they enrich session state for later turns. See [Invocation Mode](/build/agents/capabilities/api_action#invocation-mode).
Choose `route` when:
* Each request maps cleanly to one capability
* **Latency matters**: route mode skips the orchestration loop entirely and streams the routed capability's output straight back
* You want **predictable, auditable behavior**, especially with rules-based routing
## Choosing a mode
| | `reasoning` | `route` |
| -------------------- | ------------------------------- | -------------------------------------- |
| Capability selection | Iterative LLM planning | One-shot: rules or LLM |
| Actions per request | As many as the task needs | One foreground (+ optional background) |
| Latency | Higher, multiple LLM steps | Lowest |
| Sub-agents | Full delegation inside the loop | Can be the routing target |
| Webhook waits | Supported | Supported |
| Best for | Complex, multi-step tasks | High-volume request-to-action mapping |
## Routing strategy (route mode)
When an agent is in `route` mode, the Configuration tab exposes **how** the routing decision is made:
* **LLM Routing** (default): a routing model selects the best capability using the conversation, the agent's current state, and each capability's name, description, and usage guidance. Well-written descriptions and **When to use / When not to use** guidance directly improve routing accuracy.
* **Rules-Based Routing**: an ordered list of deterministic rules, first match wins.
* Conditions evaluate the **request** content or **state** fields.
* Operators include equality and numeric comparisons, pattern matching (`like`, regex), and **semantic matching** against a reference phrase.
* Each rule routes to a specific **action**, a **sub-agent**, or falls through to **LLM routing**.
* A **default route** handles requests that match no rule.
## Flow configuration (reasoning mode)
When the agent is in `reasoning` mode, the Configuration tab shows the **Agent Flow** pipeline instead: every step of the loop, each with its own prompt and model configuration. See [Agent Flow Steps](/build/agents/agent_flow).
## Performance options
These optional request-time flags tune how an agent executes without changing what it can do. See [Agent Call](/sdk/agent_call) for the full parameter reference.
| Parameter | Default | Description |
| ------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `high_performance` | `false` | Flattens sub-agent capabilities into the root agent and runs everything in-process. Eliminates inter-process overhead for agents with sub-agent hierarchies. |
| `max_iterations` | `100` | Caps reasoning-loop iterations. A safety limit for runaway loops in `reasoning` mode. |
## Next
* Configure the reasoning pipeline: [Agent Flow Steps](/build/agents/agent_flow)
* Define structured session state: [Agent State](/build/agents/agent_state)
* Full walkthrough: [Build an Agent](/examples/build_agent)