> 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/core-concepts/steering-and-reasoning.md). # Steering & Reasoning 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**, and usually should. 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 — you pay for depth where the decision is made, and for speed where the work is done. Both are set on [Agent Behavior](/agent-builder/build/agent-behavior.md). {% hint style="info" %} The planner can only choose from the agent's attached [Skills & Tools](/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](/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. This is the highest-leverage page in the builder. When an agent misbehaves, the cause is usually instructions, knowledge, or skills — rarely anything else. 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](/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](/core-concepts/human-in-the-loop.md). | | **Agent Capability** (default `Auto`) | Depth against latency and cost. `Auto` lets the platform decide per request. | | **Response Mode** (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. | The defaults are deliberate. Change one when you have measured a reason to, not preemptively. {% 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. Treat these as production parameters you tune and version — not defaults you set once and forget. {% 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 [checklist](/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 start without checklists and grow into them as patterns emerge. That is the intended path, not a shortcoming. ## Making reasoning visible **CoT Reasoning** (beta, default off) makes the agent show its work — the reasoning steps alongside the answer. Turn it on when users or auditors need to see how a conclusion was reached, which in a regulated context is often the whole point. This is distinct from **COT Validation**, where a *second model* reviews the output before the user sees it — that is a check, not a display. See [Guardrails & Validation](/core-concepts/guardrails-and-validation.md). The **execution trace** in the builder shows the same information to you rather than to users: how the agent read your instructions, which skills it chose, how long each took. It is the first place to look when an agent does something surprising. ## Where this is configured * [Instructions](/agent-builder/build/instructions.md) — the operating brief * [Agent Behavior](/agent-builder/build/agent-behavior.md) — autonomy, capability, response mode, models, CoT * [Execution Plan/Checklist](/agent-builder/build/execution-plan-checklist.md) — reusable plans * [Runtime & Versioning](/agent-builder/build/runtime-and-versioning.md) — which executor version runs the agent --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.uptiq.ai/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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.