> 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/start-here/how-an-agent-works.md).

# How Agents Work

An AI agent is a software-based digital worker that understands goals, makes decisions, and takes actions to complete tasks. Unlike a chatbot, which mainly generates responses, an agent reasons through problems, reads knowledge you give it, uses tools and integrations, and interacts with external systems — databases, APIs, enterprise applications — with minimal human intervention, while still allowing human oversight where you want it.

This page walks through building one, in the order you actually do it. Each step links to the concept behind it and the screen that configures it.

## 1. Describe what you want the agent to do

Start with a plain-language description of the task. Be specific about what the agent should accomplish — the more context you give, the less manual configuration you'll do afterwards. You don't need to know which settings to use yet.

{% hint style="info" %}
**What Qore does:** The Agent Builder analyses your prompt to pre-fill the agent's name, output format, and an initial skill set. Treat it as a first draft you'll review, not a finished agent.
{% endhint %}

## 2. Confirm how the agent identifies and responds

Review the suggested name and description, and choose the **Agent Output Format** that matches who — or what — receives the responses: `Markdown` for humans reading in a UI, `Json` when your application parses the output.

{% hint style="info" %}
**What Qore does:** Name and description are metadata for builders; they don't change how the agent behaves. Output format is a contract with whatever consumes the response.
{% endhint %}

→ [Basic Details](/agent-builder/build/basic-details.md)

## 3. Choose the runtime version

New agents are pinned to the latest executor version your tenant supports. Existing agents stay on the version they were created with unless you change it deliberately — the platform won't force an upgrade. Move to a newer version when you want a capability it introduces.

{% hint style="info" %}
**What Qore does:** The executor changes over time — new versions add capabilities, fix issues, and sometimes deprecate older behaviors. Switching versions can change agent behavior and the set of features available, so re-test after you do.
{% endhint %}

→ [Runtime & Versioning](/agent-builder/build/runtime-and-versioning.md)

## 4. Set how the agent thinks

Three levers, all on one screen, all with sensible defaults:

* **Agent Capability** (default `Auto`) — how deeply the agent thinks about each request. `Auto` lets the platform decide per request, which is right for most agents.
* **Response Mode** (default `Advanced`) — the speed-versus-quality trade-off.
* **Execution Model** and **Planning Model** — which model runs the agent, and which one plans its work. They can differ.

{% hint style="info" %}
**What Qore does:** Planning happens once per request; execution may run many tool calls. That's why the two models are separate — a common pattern is a heavier model for planning and a lighter one for execution.
{% endhint %}

→ [Steering & Reasoning](/core-concepts/steering-and-reasoning.md) · [Agent Behavior](/agent-builder/build/agent-behavior.md)

## 5. Decide what the agent remembers

**Memory** (default off) lets the agent remember what an individual user has asked about, preferred, or corrected, across conversations. Turn it on for assistant-style agents in a chat UI where users log in. Leave it off for headless agents called by API with no persistent user identity — there it adds noise without benefit.

**FAQ memory** (default on) lets the agent reuse a stored answer when a question matches a known FAQ.

{% hint style="info" %}
**Confirm the scope before enabling memory on an agent handling sensitive material.** Who can see what a user told which agent is worth answering explicitly in a regulated environment — check with your platform administrator.
{% endhint %}

→ [Memory & Learning](/core-concepts/memory-and-learning.md) · [Agent Behavior](/agent-builder/build/agent-behavior.md#memory)

## 6. Remove capabilities the agent doesn't need

The platform attaches a set of skills to every agent by default. Read that list and disable anything your agent won't use — keeping unused skills active widens the range of things the agent can do wrong.

{% hint style="info" %}
**What Qore does:** Platform-supplied skills are attached automatically and can be individually disabled without affecting the ones that remain.
{% endhint %}

→ [Skills & Tools](/core-concepts/skills-and-tools.md) · [Skills & Capabilities](/agent-builder/build/skills-and-capabilities.md)

## 7. Connect the tools and data the agent needs

For each external system the agent must reach, attach the right kind of skill: an **API call** for REST endpoints, an **MCP server** for tool platforms, a **RAG container** for document search. Configure endpoints, authentication, and schemas for each.

→ [Adding a Skill to the Agent](/agent-builder/build/adding-a-skill-to-the-agent.md) · [MCP Tools](/agent-builder/build/mcp-tools.md) · [Knowledge & Context](/core-concepts/knowledge-and-context.md)

## 8. Decide how much scrutiny the agent applies to itself

Enable **COT Validation** (LLM Judge) when a wrong answer has real consequences — approving a document, triggering a payment, anything hard to reverse. Skip it for conversational or high-volume cases where speed matters.

{% hint style="warning" %}
**What Qore does:** COT Validation uses a second, different model to review the output before the user sees it — so every response waits for two models instead of one. Disabled by default.
{% endhint %}

**Guardrails** are the broader mechanism: validators that inspect content at four points — the inbound request, each tool call before it runs, each tool result, and the final response.

→ [Guardrails & Validation](/core-concepts/guardrails-and-validation.md) · [Guardrails (Beta)](broken://pages/OUgN2cy5TI1ktkNgAcjr)

## 9. Test whether it behaves as intended

Use **Try Agent** to run sample inputs that represent real usage. Open the **execution trace** to see how the agent interpreted your instructions, which skills it called, and how long each step took. If something's off — wrong skill, unexpected output — adjust and re-test before moving on.

{% hint style="info" %}
**What Qore does:** The execution trace is for builders. End users see only the final response.
{% endhint %}

→ [Test](/agent-builder/test.md) · [Evals](/agent-builder/test/evals.md)

## 10. Go live, and keep it improving

Once the agent performs on your test cases, deploy it. Then review what it actually does in production: approve corrections that represent genuine improvements, reject anything incorrect or exploitable, and iterate as edge cases emerge.

{% hint style="warning" %}
**What Qore does:** Learning cases require manual approval before they enter agent memory. Auto-approval is intentionally disabled, so a malicious or mistaken input cannot quietly corrupt the agent's behavior.
{% endhint %}

→ [Deploy](/agent-builder/deploy.md) · [Monitor](/agent-builder/monitor.md) · [Human-in-the-Loop](/core-concepts/human-in-the-loop.md)

***

The loop closes: what you learn in step 10 becomes a change in steps 4 through 7. For the ideas behind each step, see [Agent Foundations](/start-here/core-concepts.md).


---

# 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/start-here/how-an-agent-works.md?ask=<question>&goal=<endgoal>
```

`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.