> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/ai-workbench-qore/core-concepts/steering-and-reasoning.md).
# Steering & Reasoning
How the agent decides what to do.
An agent is not a chatbot with a script. Given a request, it decides what to do — which actions to take, in what order, and when it has done enough. **Steering** is how you influence that decision without writing the decision yourself.
Four things shape it: what you told the agent to do, how much rope you gave it, how hard it thinks, and whether it has done this before.
## The planner and the executor
Every request goes through two stages.
The **planner** reads your instructions and the user's input, then decides which skills to call and in what order. The **executor** runs that plan, calling each skill and feeding results forward.
They can run on **different models**. Planning happens once per request; execution may run many tool calls. A common pattern is a heavier model for planning and a lighter one for execution. Both are set on [Agent Behavior](/ai-workbench-qore/console/agent-builder/build/agent-behavior.md), from the models [AI Gateway](/ai-workbench-qore/control-center/ai-gateway.md) serves for your organization. Every model request an agent makes passes through AI Gateway.
{% hint style="info" %}
The planner can only choose from the agent's attached [Skills & Tools](/ai-workbench-qore/core-concepts/skills-and-tools.md). A skill that isn't attached cannot be used, no matter what your instructions say.
{% endhint %}
## Instructions: the one that matters most
[Instructions](/ai-workbench-qore/console/agent-builder/build/instructions.md) are the agent's operating brief. The platform feeds them to the model on every turn, so the rules, tone, examples, and procedures you write there shape every response.
A vague or self-contradicting brief produces an agent that fails in ways that are hard to debug, because nothing is technically broken.
## The levers
These sit on [Agent Behavior](/ai-workbench-qore/console/agent-builder/build/agent-behavior.md). Each trades something away.
| Lever | What it trades |
| ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Autonomy** (`Low` / `Med` / `High`, default `Med`) | Independence against visibility. High lets the agent commit to multi-step plans alone; Low makes it confirm more steps. See [Human-in-the-Loop](/ai-workbench-qore/core-concepts/human-in-the-loop.md). |
| **Agent Capability** (`Auto` / `Intelligent Planner` / `Next Best Step` / `Fast`, default `Auto`) | Depth against latency and cost. `Auto` lets the platform decide per request. `Fast` lowers latency by leaving out persona memory, FAQ memory, CoT validation, and learning cases. |
| **Response Mode** (`Advanced` / `Balanced` / `Flash`, default `Advanced`) | Quality against speed. `Advanced` is slower and better; faster modes process more shallowly. |
| **Execution / Planning Model** | Cost against reasoning quality — independently, per stage. **Model Family** filters both lists. Both models are chosen in `Advanced` mode, and the Planning Model only with a capability that plans (`Auto`, `Intelligent Planner`, or `Fast`). |
{% hint style="warning" %}
Behavior settings change the agent's **character**, not just its performance. The same instructions run by two different models produce two different agents.
{% endhint %}
## Planning fresh, or following a checklist
By default the planner builds a plan for every request from scratch. That is flexible and handles anything, but two runs of the same request may plan differently.
A [Execution Plan/Checklist](/ai-workbench-qore/console/agent-builder/build/execution-plan-checklist.md) is a reusable execution plan — a known-good sequence of skill calls. The agent derives them from its own successful runs: recurring patterns become reusable plans. When a request matches one, the planner follows it instead of improvising.
The trade is flexibility against predictability.
* **Checklists suit** repeated requests, multi-step workflows with a known order, and anything you need to review, explain, or audit.
* **Dynamic planning suits** varied requests, new agents whose usage patterns you don't know yet, and workflows that keep changing.
Most agents initially operate without checklists, and gain them as repeated execution patterns emerge.
## Making reasoning visible
The **execution trace** in the builder shows you how the agent read your instructions, which skills it chose, and how long each took. It is the first place to look when an agent does something surprising.
{% hint style="info" %}
**CoT Reasoning (beta) is deprecated.** It can no longer be turned on. An agent that already has it on can turn it off on Agent Behaviour, but once it is off it can't be turned on again.
{% endhint %}
## Where this is configured
* [Instructions](/ai-workbench-qore/console/agent-builder/build/instructions.md) — the operating brief
* [Agent Behavior](/ai-workbench-qore/console/agent-builder/build/agent-behavior.md) — autonomy, capability, response mode, model family, models
* [Execution Plan/Checklist](/ai-workbench-qore/console/agent-builder/build/execution-plan-checklist.md) — reusable plans
* [Runtime & Versioning](/ai-workbench-qore/console/agent-builder/build/runtime-and-versioning.md) — which executor version runs the agent
***
{% columns %}
{% column width="83.33333333333334%" %}
Maintained by Abhishek Paul
AI-assisted, human-approved
{% endcolumn %}
{% column width="16.666666666666664%" %}
{% endcolumn %}
{% endcolumns %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.uptiq.ai/ai-workbench-qore/core-concepts/steering-and-reasoning.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
