> 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/human-in-the-loop.md).

# Human-in-the-Loop

An agent that acts on its own is the point. An agent that acts on its own *where it shouldn't* is the risk. In a bank, the difference is usually not whether the agent is capable — it's whether a person is standing in the right place when it commits to something.

Qore's controls fall into two families, and it's worth being precise about which is which:

* **Automated controls** — [guardrails](/core-concepts/guardrails-and-validation.md), COT validation, PII tokenization. A machine checks the agent. Fast, consistent, and always on.
* **Human controls** — the subject of this page. A person checks the agent. Slower, and reserved for decisions worth a person's time.

Automated controls scale. Human controls are what you reach for when being wrong is expensive.

## Where a person can stand

### Before the agent commits: Autonomy

[Autonomy](/agent-builder/build/agent-behavior.md#autonomy) is a slider — `Low`, `Med`, `High`, defaulting to `Med`. It sets how independently the agent acts without checking back.

* **High** — the agent commits to multi-step plans on its own. Right for well-scoped automations you have tested thoroughly.
* **Low** — the agent confirms more steps before proceeding. Right for new agents whose behavior you want to keep visible.

This is the most direct human-in-the-loop control the platform has, and it's a dial rather than a switch. A new agent starts at Low while you learn what it does; it earns its way to High.

### Before the agent learns: learning-case approval

The agent can improve from its own production history — but nothing enters its memory without a person approving it.

{% hint style="warning" %}
**Auto-approval is intentionally disabled.** An agent that learns automatically from its traffic can be taught the wrong thing — by an unusual case, or by someone who works out that it learns. Manual approval is what makes memory safe to write to.
{% endhint %}

See [Memory & Learning](/core-concepts/memory-and-learning.md) and [Reinforcement Learnings](/agent-builder/monitor/reinforcement-learnings.md).

### Before code exists: plan review

In the [App Builder](/app-builder/app-builder.md), **Plan Mode** presents a proposed architecture — features, logic, extra ideas — and waits. You click **Start building** to commit, or **Revise plan** to iterate. Nothing is generated until you agree.

This is the same principle applied earlier: the review happens when changing course is still cheap. See [Plan](/app-builder/plan.md).

## Seeing enough to intervene

A person can only stay in the loop if they can see what the agent did. Three mechanisms make behavior legible:

* **CoT Reasoning** (beta, default off) — the agent shows its reasoning alongside its answer, so users or auditors can see how it reached a conclusion. Worth turning on for high-stakes or compliance-sensitive work.
* **The execution trace** — in the builder, the full record of how the agent read your instructions, which skills it chose, and how long each took. For builders, not end users.
* [**Monitoring**](broken://pages/cD46XWa7ZwMLNvtnC3yG) **and** [**Online-Eval**](/agent-builder/monitor/online-eval.md) — what the agent actually did in production, scored.

Transparency is not approval. But an approval you can't inform is a rubber stamp, so these are what make the human controls above worth having.

## Choosing where the human stands

Every human checkpoint costs latency and someone's attention. Spend them where being wrong is expensive and hard to reverse.

| Situation                                                     | Where to put the person                                                               |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| New agent, behavior not yet understood                        | **Autonomy: Low** — watch what it does                                                |
| Well-tested automation, high volume                           | **Autonomy: High**, rely on [guardrails](/core-concepts/guardrails-and-validation.md) |
| Agent changes its own future behavior                         | **Always** — learning-case approval, no exceptions                                    |
| Wrong answer is expensive but a person can't review every one | **COT Validation** — a second model instead of a person                               |
| Building something with real architectural consequences       | **Plan Mode** — review before code exists                                             |

The pattern: use a person where judgment is needed and the cost of being wrong is high; use a machine where consistency matters more than judgment; and never let the agent rewrite its own memory unsupervised.

## Where this is configured

* [Agent Behavior](/agent-builder/build/agent-behavior.md) — Autonomy, CoT Reasoning
* [Reinforcement Learnings](/agent-builder/monitor/reinforcement-learnings.md) — learning-case approval
* [Plan](/app-builder/plan.md) — Plan Mode review, in the App Builder
* [Guardrails & Validation](/core-concepts/guardrails-and-validation.md) — the automated counterpart


---

# 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/human-in-the-loop.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.