> ## 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.

# Welcome to Noorle

> Noorle runs agents you compose rather than engineer — capabilities, memory, autonomy, and durable Program Workflows behind MCP and A2A

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.

```mermaid theme={"dark"}
graph TD
    subgraph Callers["Callers"]
        C1["MCP clients"]
        C2["A2A callers"]
        C3["Messaging channels"]
    end

    subgraph Plane["Noorle control plane"]
        GW["MCP gateway"]
        AGW["Agent gateway"]
        AG["Agent loop"]
        WF["Workflows"]
    end

    subgraph Cap["Capabilities"]
        BI["Built-in"]
        PL["Plugins (WASM)"]
        CO["Connectors"]
    end

    C1 --> GW
    C2 --> AGW
    C3 --> AG
    AGW --> AG
    GW --> Cap
    AG --> Cap
    AG --> WF
```

## The two things you can build

**A gateway** publishes tools at its own host, `mcp-{handle}.noorle.cloud`, 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.cloud`, from Slack, Telegram, or SMS, or on a schedule.

Both draw on the same capability system.

## The three kinds of capability

1. **Built-in** — eleven, seeded into every account: Files, Web Search, HTTP Client, Knowledge Retrieval, Code Runner, Sandbox, Browser, Computer, Memory, and two 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](/docs/learn/concepts/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

<CardGroup cols={2}>
  <Card title="One capability model" icon="layer-group">
    Built-ins, plugins, and connectors all become MCP tools with the same naming, the same risk classification, and the same admission path.
  </Card>

  <Card title="Autonomy you configure" icon="shield-halved">
    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.
  </Card>

  <Card title="Isolation by construction" icon="lock">
    Plugins run in a WASM sandbox with no ambient authority. Connector credentials are encrypted at rest. Every resource is account-scoped.
  </Card>

  <Card title="A record of what happened" icon="scroll">
    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.
  </Card>
</CardGroup>

## 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** — an immutable, versioned Program that runs durably and can wait for a timer, person, signal, callback, or child Workflow.

**Portal** — the web UI where all of this is configured.

## How the docs are organized

<CardGroup cols={2}>
  <Card title="Learn" icon="book">
    **You are here.** How the platform works and why it is shaped this way.
  </Card>

  <Card title="Run" icon="play">
    Doing things: creating gateways, binding capabilities, connecting channels.
  </Card>

  <Card title="Build" icon="hammer">
    Writing plugins and packaging them.
  </Card>

  <Card title="Reference" icon="code">
    Endpoints, protocol details, CLI.
  </Card>
</CardGroup>

## Next steps

<CardGroup cols={3}>
  <Card title="Architecture" icon="diagram-project" href="/docs/learn/architecture">
    How requests are routed and where the agent loop actually runs.
  </Card>

  <Card title="Use cases" icon="lightbulb" href="/docs/learn/use-cases">
    Shapes that compose well out of what exists.
  </Card>

  <Card title="Quick orientation" icon="rocket" href="/docs/learn/quickstart">
    The four steps from account to a working endpoint.
  </Card>
</CardGroup>

***

Start with [Architecture](/docs/learn/architecture) for the big picture.