Capabilities
Add one production behavior at a time without giving up ownership of providers, data, or infrastructure.
A Noir capability is an optional, self-hosted module that adds tools, services, routes, policy, or lifecycle work to an agent. Importing one does not connect to a provider or start background work. You supply its dependencies and add it to the agent explicitly.
Choose by outcome
| You need | Start here |
|---|---|
| recurring work, signed alerts, or change detection | Autonomous work |
| durable delegation or a specialized sub-agent | Tasks and specialists |
| debounce, interruption, contacts, opt-out, or escalation | Conversation control |
| typed records, learned facts, skills, or reviewed capability versions | Knowledge and state |
| attachments, images, cards, browser handoff, or public-web research | Media, browser, and web |
| per-user OAuth, OpenAPI, MCP, secrets, or API keys | Connections and access |
| traces, budgets, cancellation, evals, quality review, or rollback | Operations and quality |
Memory and sandbox are first-class resources on noir({ memory, sandbox }). Provider integrations that add a named tool group belong under connectors. Cross-cutting behavior belongs in plugins. The distinction keeps the agent file readable.
export default noir({
id: 'operator',
model,
channels: { slack: slack() },
database,
memory,
sandbox,
connectors: { analytics, github },
plugins: [schedules, tasks, observability],
})What every capability must preserve
- Ownership: installation, actor, conversation, and resource scope come from verified runtime context.
- Bounds: input, output, time, retries, concurrency, pages, and stored records have explicit limits.
- Replay safety: a retried effect reuses a receipt or stable idempotency key instead of repeating blindly.
- Truthful outcomes: queued, pending, delivered, failed, and canceled are different states.
- No ambient authority: provider URLs, tokens, owners, and operation allowlists are host configuration, not model arguments.
- Explicit lifecycle: migrations, workers, cleanup, and shutdown are application-owned.
Add a capability
- Import the narrow package subpath.
- Choose a memory store for local development or the matching Postgres store for durable production work.
- Run the store’s idempotent migration during a controlled release.
- Configure exact ownership, limits, and policy.
- Add the capability to the agent.
- Start any documented runner from application lifecycle.
- Test duplicate delivery, process restart, denial, timeout, and provider failure.
Do not enable a capability because it sounds useful. Add it when the product has a concrete workflow and an owner for its operational state.
Package map
The package exports reference lists every stable import path. Each capability page explains the smaller set that belongs to one operational concern.