> ## Documentation Index
> Fetch the complete documentation index at: https://noorle.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Agents

> What an agent is on Noorle: the loop that runs outside every sandbox, how it is specified, how it routes to models, and how it delegates

An **agent** is a configured loop: a system prompt, a model routing strategy, a set of bound capabilities, and access to memory and knowledge. You compose it; you do not engineer it.

## Where the loop runs

This matters more than it sounds. **The agent loop runs in the Noorle control plane, outside every execution sandbox.** Model routing, memory, tool dispatch, the journal, autonomy decisions, scheduling — all of it is host-side. An agent has no path back into the control plane; it requests capabilities *through* it.

Execution happens in tiers the loop calls into:

* **WebAssembly** — the built-in code runner and your plugins, under strict CPU and memory caps.
* **Sandbox** — a session-scoped ephemeral container, created and torn down with the session.
* **Computer** — a persistent machine bound to one agent, shared across that agent's sessions, alive between turns.

None of these is "the runtime". The loop picks per workload.

```mermaid theme={null}
graph TD
    Loop["Agent loop<br/>(control plane)"]

    Loop --> Ctx["Assemble context<br/>pinned memory + summary + recent messages"]
    Ctx --> Route["Route to a model"]
    Route --> Call["Model call"]
    Call --> Gate{"Tool call?"}
    Gate -->|no| Done["Respond"]
    Gate -->|yes| Adm["Admission door<br/>hardline, authority, policy"]
    Adm -->|allow| Exec["Execute in the right tier"]
    Adm -->|pause| Human["Wait for a human decision"]
    Adm -->|deny| Done
    Exec --> Call
```

## Agent vs gateway

An **MCP gateway** publishes tools and waits. It holds no conversation and makes no decisions — an outside client does the thinking.

An **agent** is the thing doing the thinking. It has a system prompt, memory, an autonomy policy, and the ability to call tools across turns.

Choose a gateway when you want to hand tools to someone else's AI. Choose an agent when the reasoning should happen on Noorle.

Note that an agent's own endpoint (`agent-{handle}.noorle.com`) speaks **A2A**, not MCP. It is not a wrapper that re-publishes the agent's tools; it is a way for another agent or application to send the agent a message and get a task back.

## What an agent is made of

Agent configuration is stored as a specification. The parts you actually set:

| Part              | What it does                                                                  |
| ----------------- | ----------------------------------------------------------------------------- |
| System prompt     | The instructions. Assembled into a larger prompt alongside platform sections. |
| Starter message   | Optional opening line. Blank means the agent waits.                           |
| Routing           | Smart or Specific. See below.                                                 |
| Capabilities      | Which built-ins, plugins, and connectors are bound.                           |
| Knowledge bases   | Attached bases are searched automatically at the start of each run.           |
| Skills            | Bound skills appear through the always-on skills surface.                     |
| Sub-agents        | Which other agents this one may delegate to.                                  |
| Channels          | Telegram, Slack, SMS.                                                         |
| Autonomy          | Level, plus auto-approve and always-ask lists.                                |
| Tool presentation | Direct, Discovery, Unified, or Adaptive.                                      |
| Generative UI     | A2UI on/off, catalog, guidance.                                               |

In the Portal, each of these is a section under the agent: General, Instructions, Model, Capabilities, Workflows, Knowledge, Delegation, Channels, Autonomy, Audit, Automations, Files, Advanced.

## Model routing

Two strategies.

### Smart

The platform picks a model per request. You may constrain it, or leave every field open.

| Field         | Values                                  | Meaning                                                               |
| ------------- | --------------------------------------- | --------------------------------------------------------------------- |
| `tier`        | `budget`, `standard`, `premium`         | Pin a cost rung. Omit to let per-request scoring choose.              |
| `model_style` | `openai`, `anthropic`, `open_source`    | Constrain the *kind* of model, not the vendor you are billed through. |
| `use_case`    | `fast`, `reasoning`, `code`, `creative` | Bias which model within the tier.                                     |

`model_style` deliberately does not expose the inference provider, the gateway, or the billing mode — those live in the model registry and never reach the agent spec.

Routing is heuristic and local. **No model call is made to decide which model to call.** Signals include input length, how many tools are bound, conversation depth, whether images are present, and remaining budget. Images set a floor at Standard; budget pressure sets a ceiling.

### Specific

Pin one model by name.

| Field                   | Meaning                                                            |
| ----------------------- | ------------------------------------------------------------------ |
| `model_name`            | The model to use                                                   |
| `route_id`              | Optional: pin a non-primary route on that model                    |
| `settings`              | Temperature, max tokens, and so on — where the model supports them |
| `budget_model`          | Optional cheaper model the platform may pick for simple requests   |
| `budget_model_settings` | Settings for the budget model                                      |
| `fallback`              | Allow fallback when the model is unavailable. Default true.        |

Fallback stays inside the same model family and may cross providers within it.

<Note>
  Not every model accepts a temperature. Several current models declare `supports_temperature = false`, and the platform omits the parameter rather than sending one that would be rejected. Reasoning effort is likewise per-model.
</Note>

For the current catalog and prices, see [Pricing](https://noorle.com/pricing/) and the [model routing guide](/docs/run/platform/model-routing).

## Memory

Agents have two kinds of memory: thread memory (the current conversation, rebuilt from the durable journal each turn) and agent memory (curated facts that persist across threads).

Two things worth knowing before you design around it:

* The recent-message window is **20 messages** and is not tunable upward.
* Curated memory is only *written* when the Memory capability is bound. It is *read* into the prompt whether or not it is bound.

See [Memory System](/docs/learn/concepts/memory-system).

## Delegation

An agent can delegate to other agents you list as sub-agents. That produces a `delegate_agent` tool.

The child **inherits the parent's pinned curated memories** and starts with an empty conversation and no summary. It does not inherit the parent's transcript.

Delegation depth is capped — the default maximum is 3 levels below the top-level agent. Past that, the tool is not offered.

## How an agent gets invoked

The same agent can be reached from several surfaces, and the surface changes what the agent is allowed to do without asking.

| Surface                | Can a tool call pause for approval?                     |
| ---------------------- | ------------------------------------------------------- |
| Portal Playground      | Yes — the approval is rendered in the chat stream       |
| AG-UI clients          | Yes — as a run interrupt, resumed on the next request   |
| A2A (`agent-{handle}`) | Yes — as a non-terminal task status the caller resolves |
| Workflow step          | No — a call that would pause is denied                  |
| Messaging channels     | No — denied                                             |
| MCP gateway            | No — denied                                             |

A surface with no live human to ask does not silently proceed; it denies. That is deliberate.

## Autonomy

Every capability call passes through an admission door before it executes. In order: a hardline floor in code, an account-level deny ledger, any recorded human decision, the invocation policy, and then the execution-policy decision tree.

The agent-level knob is a **level**:

* **ReadOnly** — Read-tier tools proceed. Act and Privileged are denied outright, without consulting any auto-approve list.
* **Supervised** — Read proceeds; anything higher needs a matching auto-approve entry, a thread-scoped approval, or it pauses for a human.
* **Full** — proceeds.

An always-ask pin overrides all of it and forces a pause even at Full.

## Common shapes

### Support agent

Knowledge Retrieval over your documentation, plus HTTP Client for order lookups. Supervised autonomy, so anything that writes needs a person. Knowledge bases attached directly so retrieval happens on every turn.

### Analysis agent

Code Runner and Files. Reasoning use-case bias. Files is `Act` tier, so writes pause under Supervised until you add them to auto-approve.

### Delegating coordinator

No capabilities of its own — just sub-agents. Each child owns one narrow surface. Remember the child starts with no conversation history, so the parent has to pass what matters in the delegation request.

***

Next: [Connectors](/docs/learn/concepts/connectors) for reaching external systems.