Skip to main content
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.

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: 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. 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. Fallback stays inside the same model family and may cross providers within it.
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.
For the current catalog and prices, see Pricing and the model routing guide.

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.

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. 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 for reaching external systems.