Every agent has an Execution Mode that determines how it handles each request. You choose it when you create the 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:
- Orchestrate — an LLM planner reviews the request, the agent’s state, and the available capabilities, then picks the next action.
- Act — the chosen capability runs: an API call, LLM call, workflow, webhook registration, or sub-agent delegation.
- Process — the result is distilled into a rolling summary, findings, and state updates.
- 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.
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.
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 → 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.
These optional request-time flags tune how an agent executes without changing what it can do. See 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
