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.cloud) 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.
Every model you can route to is listed in the model catalog, alongside the tier, style, and category each one declares. For prices, see Pricing.

​
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. Messaging channels and MCP gateways have no live human to ask, so a call that would have paused is denied rather than left to proceed unattended. That is deliberate. A Workflow call is the deliberate exception. The Agent’s autonomy level and its approval flow do not apply to a bound call inside an authored Workflow — the Program was reviewed ahead of time, so the call proceeds once it clears the hardline floor and the account’s deny ledger. Put business review in the Program with await_approval. See Workflows.

​
Autonomy

Every capability call passes through an admission door before it executes. In order: a hardline floor in code, the account’s 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 the level even at Full: a pause on a surface that can ask a human, a deny on one that cannot. Workflow steps are the exception described above.

​
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 splits by tool: ls, read, stat, and exists are Read tier and proceed; every other Files tool is Act, 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.