Skip to main content
Noorle is a platform for running agents. You compose an agent from capabilities, knowledge, and policy; Noorle runs the loop, decides which model to call, holds the memory, enforces what the agent may do on its own, and keeps a record of all of it. Two protocols reach in from outside: MCP, for handing tools to someone else’s AI, and A2A, for another system to send your agent work.

​
The two things you can build

A gateway publishes tools at its own host, mcp-{handle}.noorle.com, and waits. Somebody else’s AI does the thinking. Use it to give an external client a controlled, audited set of tools. An agent does the thinking itself. It has a system prompt, memory across turns, an autonomy policy, and a set of bound capabilities. It can be reached in the Portal, over A2A at agent-{handle}.noorle.com, from Slack, Telegram, or SMS, or on a schedule. Both draw on the same capability system.

​
The three kinds of capability

  1. Built-in — twelve, seeded into every account: Files, Web Search, HTTP Client, Knowledge Retrieval, Code Runner, Sandbox, Browser, Computer, Memory, and three construct builders.
  2. Plugins — your own code, compiled to a WebAssembly component and run in a sandbox with an explicit host allowlist and hard resource caps.
  3. Connectors — a REST API, a server from the public MCP registry, or your own MCP server. No code.
See Capabilities.

​
Who this is for

Builders packaging an agent product for their own clients — you compose the agent, your clients use it. Partners implementing, configuring, and advising on Noorle deployments.

​
What the platform gives you

One capability model

Built-ins, plugins, and connectors all become MCP tools with the same naming, the same risk classification, and the same admission path.

Autonomy you configure

Every tool call passes an admission door. What proceeds on its own, what pauses for a person, and what is refused outright is policy, not prompt engineering.

Isolation by construction

Plugins run in a WASM sandbox with no ambient authority. Connector credentials are encrypted at rest. Every resource is account-scoped.

A record of what happened

Runs, model calls, tool calls, and autonomy decisions are appended to a durable journal — the same substrate the agent’s own conversation is rebuilt from.

​
Quick vocabulary

Capability — anything an agent, gateway, or workflow can call. MCP gateway — a host that publishes bound capabilities as MCP tools, and acts as its own OAuth authorization server. Agent — a configured loop with memory, capabilities, and an autonomy policy. Tool presentation — how many tools the model actually sees: every one directly, behind discovery meta-tools, or behind a single dispatcher. Autonomy gate — the decision point every tool call passes through before it executes. Workflow — a durable graph of steps that survives restarts and can wait indefinitely for a human. Portal — the web UI where all of this is configured.

​
How the docs are organized

Learn

You are here. How the platform works and why it is shaped this way.

Run

Doing things: creating gateways, binding capabilities, connecting channels.

Build

Writing plugins and packaging them.

Reference

Endpoints, protocol details, CLI.

​
Next steps

Architecture

How requests are routed and where the agent loop actually runs.

Use cases

Shapes that compose well out of what exists.

Quick orientation

The four steps from account to a working endpoint.
Start with Architecture for the big picture.