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

# Build on Noorle

> Extend the platform: compose an agent from capabilities you configure, and write a WASM plugin only when nothing you can configure covers the job.

Most of what you build on Noorle is composition, not engineering. You bind
capabilities to an agent or a gateway, point them at the systems you already
run, and the platform handles execution, approvals, and the audit trail.

This tab covers the part that needs code: writing a **plugin** — a
WebAssembly component that runs inside the platform sandbox and exposes its
exported functions as tools.

It also covers [packaging](/docs/build/packaging/overview) — what the platform is
responsible for when you run agents as a product for other people, and where
the commercial line falls.

## Start with what you don't have to write

Every capability an agent or gateway can call is one of three kinds:

| Kind          | What it is                                                                                                                                                                                                              | Where you set it up                                                               |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Builtin**   | First-party tools the platform ships and maintains — files, web search, HTTP client, knowledge retrieval, code runner, sandbox, computer, browser, memory, and the three authoring builders. Seeded into every account. | Bind them in the Portal — see [Built-in capabilities](/docs/run/capabilities/overview) |
| **Connector** | A REST API (importable from an OpenAPI 3.x or Swagger 2.0 document), a server from the MCP registry, or your own MCP server. Credentials encrypted at rest.                                                             | Configure in the Portal — see [Connectors](/docs/run/connectors/overview)              |
| **Plugin**    | Your own code, compiled to a WASI Preview 2 WebAssembly component and run under a strict resource and network policy.                                                                                                   | This tab                                                                          |

Reach for a plugin when the work is computation you own — a transformation, a
proprietary algorithm, or several calls collapsed into one tool — and no
builtin or connector covers it. [When to build a plugin](/docs/build/plugins/when-to-build)
walks the decision.

## Three ways to get a plugin into your account

All three end at the same place: a validated component, stored, and activated
as a version of a capability you can bind.

<CardGroup cols={3}>
  <Card title="Write it" icon="code" href="/docs/build/plugins/quickstart">
    Scaffold with the Noorle CLI, build to a component, upload the archive.
    Rust, Python, JavaScript, TypeScript, or Go.
  </Card>

  <Card title="Upload a component" icon="upload" href="/docs/build/plugins/publishing">
    Already have a `.wasm` component? Upload it directly, with an optional
    `.wit` file for tool descriptions.
  </Card>

  <Card title="Generate it" icon="sparkles" href="/docs/build/plugins/overview#generating-a-plugin">
    **Plugins → New plugin → Build with AI** in the Portal, or bind the Plugin
    Builder capability and let an agent do it. Generated plugins are Rust.
  </Card>
</CardGroup>

## The plugin section

<CardGroup cols={2}>
  <Card title="How plugins run" icon="cube" href="/docs/build/plugins/overview">
    Component Model, the `.npack` archive, admission validation, and what the
    sandbox does and does not give you.
  </Card>

  <Card title="Quickstart" icon="bolt" href="/docs/build/plugins/quickstart">
    Scaffold, build, upload, activate.
  </Card>

  <Card title="Project structure" icon="folder-tree" href="/docs/build/plugins/project-structure">
    What the scaffolded project contains and which file drives what.
  </Card>

  <Card title="Languages" icon="code" href="/docs/build/languages/rust">
    Toolchain, layout, and build command for Rust, Python, JavaScript,
    TypeScript, and Go.
  </Card>

  <Card title="noorle.yaml reference" icon="file-code" href="/docs/build/plugins/configuration">
    The keys the platform reads.
  </Card>

  <Card title="Permissions" icon="shield" href="/docs/build/plugins/permissions">
    Network hosts, storage mounts, environment variables, credentials, and
    resource limits.
  </Card>

  <Card title="Publishing and versions" icon="rocket" href="/docs/build/plugins/publishing">
    Upload paths, size limits, the dormant-then-activate model, and rollback.
  </Card>
</CardGroup>

## Once it exists

A plugin is a capability like any other. It gets a platform-assigned tool
namespace, it is bound to agents and gateways the same way builtins are, and
its calls go through the same approval gate and land in the same audit trail.

* [Attach capabilities to an agent](/docs/run/capabilities/overview)
* [Expose them through a gateway](/docs/run/platform/mcp-gateway)
* [How capabilities fit together](/docs/learn/concepts/capabilities)