# OpenClaw — full corpus
# LLM Wiki
An open-source template for building LLM-powered knowledge bases, following [Andrej Karpathy's "LLM Wiki" pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f).
You provide raw sources. The LLM reads them, writes structured wiki pages, cross-links everything, and maintains it over time. You never edit the wiki directly — you curate sources and ask questions.
## How It Works
The system has three layers:
```
raw/ Sources you collect (articles, transcripts, notes, PDFs)
wiki/ LLM-written & maintained pages (summaries, concepts, entities, syntheses)
CLAUDE.md Schema that tells the LLM how to structure everything
```
Three operations drive the workflow:
| Operation | Trigger | What happens |
|-----------|---------|--------------|
| **Ingest** | "ingest raw/my-source.txt" | LLM reads the source, creates a summary page, creates/updates concept and entity pages, adds cross-links, updates the index and log |
| **Query** | Ask any question | LLM searches the wiki, synthesizes an answer with citations, optionally creates a synthesis page for novel insights |
| **Lint** | "lint" or "health check" | LLM audits all pages for orphans, contradictions, missing links, incomplete sections, and low-confidence claims — fixes what it can, reports the rest |
## Quick Start
1. **Clone this repo**
```bash
git clone https://github.com/YOUR_USERNAME/llm-wiki.git my-knowledge-base
cd my-knowledge-base
```
2. **Customize CLAUDE.md** for your domain
- Update the Purpose section with your topic
- Replace the placeholder tagging taxonomy with your own categories
- Adjust confidence level descriptions if needed
- Everything else (workflows, page formats, linking rules) works as-is
3. **Drop sources into `raw/`**
- Text files, transcripts, articles, notes — any plain text
- These are immutable once added; the LLM never modifies them
4. **Tell the LLM to ingest**
```
ingest raw/my-first-source.txt
```
The LLM will create summary pages, concept pages, entity pages, cross-links, and update the index.
5. **Ask questions**
```
What are the key differences between X and Y?
```
The LLM answers from the wiki, citing specific pages.
6. **Run health checks**
```
lint
```
The LLM audits the wiki and fixes issues.
## Directory Structure
```
.
├── CLAUDE.md # Schema — the LLM's instructions
├── raw/ # Your source documents (immutable)
└── wiki/
├── index.md # Master catalog of all pages
├── log.md # Append-only activity log
├── dashboard.md # Dataview dashboard (Obsidian)
├── analytics.md # Charts View analytics (Obsidian)
├── flashcards.md # Spaced repetition cards
├── summaries/ # One page per source document
├── concepts/ # Concept and framework pages
├── entities/ # People, tools, organizations, etc.
├── syntheses/ # Cross-cutting analyses and comparisons
├── journal/ # Research/session journal entries
│ └── template.md # Journal entry template
└── presentations/ # Marp slide decks
```
## Enhancements
This template includes several extras beyond the core wiki pattern:
### Dataview Dashboard (`wiki/dashboard.md`)
Live queries that surface low-confidence pages, recent updates, concepts by tag, and pages with the most sources. Requires the [Dataview](https://github.com/blacksmithgu/obsidian-dataview) Obsidian plugin.
### Charts View Analytics (`wiki/analytics.md`)
Visual analytics with pie charts, bar charts, and word clouds. Requires the [Charts View](https://github.com/caronchen/obsidian-chartsview-plugin) Obsidian plugin.
### Mermaid Diagrams
Use Mermaid code blocks in any wiki page to create flowcharts, sequence diagrams, or concept maps. Native support in Obsidian and GitHub.
### Marp Slides (`wiki/presentations/`)
Create slide decks from markdown using [Marp](https://marp.app/). Drop presentation files in this directory.
### Research Journal (`wiki/journal/`)
Track your research sessions, experiments, or applied work with the included template. The LLM can reference journal entries when answering queries.
### Spaced Repetition (`wiki/flashcards.md`)
Flashcards in the format used by the [Spaced Repetition](https://github.com/st3v3nmw/obsidian-spaced-repetition) Obsidian plugin. Ask the LLM to generate flashcards from any wiki page.
### MCP Server
This repo works with Claude Code's MCP server capabilities. Point an MCP-compatible client at this repo and the LLM can read/write the wiki programmatically.
## Customizing for Your Domain
The schema in `CLAUDE.md` is domain-agnostic. To adapt it:
1. **Purpose** — Describe your knowledge domain in one paragraph
2. **Tagging taxonomy** — Replace placeholder categories with your own (e.g., for a cooking KB: `cuisine`, `technique`, `ingredient`, `equipment`)
3. **Confidence levels** — Adjust the descriptions to match your domain's evidence standards
4. **Entity types** — Update the entity page description to match what entities mean in your domain (people, tools, companies, etc.)
5. **Journal template** — Customize `wiki/journal/template.md` for your workflow
Everything else — page format, linking conventions, workflows, rules — is universal and works across domains.
## Example Domains
This template works for any knowledge-intensive topic:
- **Research notes** — papers, experiments, methodologies
- **Book analysis** — themes, characters, author techniques
- **Competitive analysis** — companies, products, market trends
- **Course notes** — lectures, readings, key concepts
- **Personal development** — frameworks, habits, book summaries
- **Technical documentation** — APIs, architectures, design patterns
- **Hobby deep-dives** — any subject you want to master
## License
MIT
---
title: "Knowledge Base Index"
type: index
updated: 2026-06-19
---
# Knowledge Base Index
Master catalog of all wiki pages. Every page in the wiki must have an entry here.
## Concepts
| Page | Tags | Confidence | Updated |
|------|------|------------|---------|
| [what-is-openclaw](concepts/what-is-openclaw.md) | openclaw, overview, gateway | high | 2026-06-19 |
| [gateway-architecture](concepts/gateway-architecture.md) | gateway, websocket, control-plane | high | 2026-06-19 |
| [the-agent-loop](concepts/the-agent-loop.md) | agent-loop, sessions, lifecycle | high | 2026-06-19 |
| [agent-runtime](concepts/agent-runtime.md) | runtime, agent-core, tools | high | 2026-06-19 |
| [channels](concepts/channels.md) | channels, messaging | high | 2026-06-19 |
| [channel-routing-and-docking](concepts/channel-routing-and-docking.md) | routing, groups, docking | high | 2026-06-19 |
| [configuration](concepts/configuration.md) | configuration, json5 | high | 2026-06-19 |
| [model-providers](concepts/model-providers.md) | providers, auth, models | high | 2026-06-19 |
| [context-and-memory](concepts/context-and-memory.md) | context-engine, memory, dreaming | high | 2026-06-19 |
| [automation](concepts/automation.md) | cron, hooks, tasks, taskflow | high | 2026-06-19 |
| [standing-orders](concepts/standing-orders.md) | standing-orders, autonomy | high | 2026-06-19 |
| [plugins-and-extensions](concepts/plugins-and-extensions.md) | plugins, capabilities, tools | high | 2026-06-19 |
| [installation-and-deployment](concepts/installation-and-deployment.md) | install, docker, vps | high | 2026-06-19 |
| [delegate-and-multi-agent](concepts/delegate-and-multi-agent.md) | delegate, multi-agent, org | high | 2026-06-19 |
| [security](concepts/security.md) | security, threat-model, atlas | high | 2026-06-19 |
## Entities
| Page | Tags | Updated |
|------|------|---------|
| [openclaw-cli](entities/openclaw-cli.md) | cli, control-plane | 2026-06-19 |
## Summaries
| Page | Source | Key Topics | Created |
|------|--------|------------|---------|
| [docs-catalog](summaries/docs-catalog.md) | openclaw/openclaw docs | area map + redirect notes | 2026-06-19 |
## Syntheses
| Page | Pages Compared | Created |
|------|----------------|---------|
| [build-your-assistant](syntheses/build-your-assistant.md) | end-to-end setup + safety | 2026-06-19 |
## Statistics
- **Total pages**: 18
- **Concepts**: 15
- **Entities**: 1
- **Summaries**: 1
- **Syntheses**: 1
- **Sources ingested**: 123 openclaw/openclaw docs pages (concepts, gateway, channels, automation, providers, install, plugins, cli, security) + README/VISION
- **High confidence**: 18
---
title: "Agent Runtime"
type: concept
tags: [runtime, agent-core, sessions, tools, extensions]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-agent-runtime-architecture-md.md, raw/github_doc-docs-openclaw-agent-runtime-md.md, raw/github_doc-docs-concepts-agent-runtimes-md.md]
---
# Agent Runtime
OpenClaw owns a **built-in agent runtime** directly — it's not just a wrapper around an external agent CLI (though it can also use those; see [model-providers](model-providers.md)).
## Structure
- **`src/agents/embedded-agent-runner/`** — the built-in agent attempt loop: provider stream adapters, compaction, model selection, and session wiring.
- **`src/agents/sessions/`** — session persistence, extension loading, resource discovery, **skills, prompts, themes**, and TUI-backed tool renderers.
- **`packages/agent-core/`** — the reusable agent core: harness types, messages, compaction helpers, prompt templates, and tool/session contracts.
- **`src/llm/`** — model/provider helpers.
## Runtime choices
OpenClaw supports its **built-in runtime** and can also drive **external agent runtimes/CLI backends** (e.g. reusing a Claude Code login on the host — [model-providers](model-providers.md)). The runtime abstraction lets a session run on whichever backend is configured, with the same channel/automation surface around it.
## What the runtime provides
- **Provider stream adapters** — normalize streaming across model providers.
- **Compaction & model selection** — keep context within limits and pick the right model ([context-and-memory](context-and-memory.md)).
- **Tools & skills** — the agent's capabilities, extensible via [plugins](plugins-and-extensions.md).
- **Sessions** — persisted, lock-guarded conversation state ([the-agent-loop](the-agent-loop.md)).
This is the engine the [Gateway](gateway-architecture.md) runs for every conversation.
---
title: "Automation: Cron, Hooks, Tasks, Task Flow"
type: concept
tags: [automation, cron, hooks, tasks, taskflow]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-automation-index-md.md, raw/github_doc-docs-automation-cron-jobs-md.md, raw/github_doc-docs-automation-hooks-md.md, raw/github_doc-docs-automation-taskflow-md.md, raw/github_doc-docs-automation-tasks-md.md]
---
# Automation: Cron, Hooks, Tasks, Task Flow
OpenClaw can act on its own, not just when you message it. The automation mechanisms:
## Scheduled tasks (cron)
**Scheduled jobs** run the agent on a cron schedule. Triggers also include **webhooks** and **Gmail PubSub** (act when an email arrives). Use for recurring check-ins, reports, monitoring, and time-based workflows.
## Hooks
**Hooks** are event-driven automation for **commands and lifecycle events** — run logic when something happens in the system (a message, a session event, a command), the event-driven complement to schedule-driven cron.
## Background tasks
**Background tasks** track long-running work: ACP runs, **subagents**, isolated cron jobs, and CLI operations. The agent can kick off work that outlives a single [loop](the-agent-loop.md) and report back when done — surfaced as tracked tasks rather than blocking the chat.
## Task Flow
**Task Flow** is an orchestration layer *above* background tasks — coordinating multi-step/multi-task agent work (the renamed "ClawFlow"). Use it when a goal needs several coordinated tasks rather than one.
## Standing orders
The authority layer that governs what autonomous automation may do without asking is [standing-orders](standing-orders.md) — pair it with automation so scheduled/triggered runs have clear, bounded permission. Many older automation sub-pages are redirects consolidating into these mechanisms (see [docs-catalog](../summaries/docs-catalog.md)).
---
title: "Channel Routing, Groups & Docking"
type: concept
tags: [routing, groups, docking, access-groups]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-channels-channel-routing-md.md, raw/github_doc-docs-channels-groups-md.md, raw/github_doc-docs-concepts-channel-docking-md.md, raw/github_doc-docs-channels-access-groups-md.md]
---
# Channel Routing, Groups & Docking
How OpenClaw decides where messages go and who can talk to the agent across multiple [channels](channels.md).
## Routing
**Channel routing** maps inbound messages to sessions and outbound replies to the right surface. With many channels connected to one [Gateway](gateway-architecture.md), routing rules determine which channel/identity a conversation belongs to and where replies are delivered.
## Groups & access
- **Group messages** — in group/room channels, **group policy** controls when the agent responds (e.g. only on mention/reply), with bot-loop protection to avoid agent-to-agent loops.
- **Access groups** — gate *who* may interact with the agent (allowlists of users/identities). Essential when the agent has real authority ([standing-orders](standing-orders.md)) — you don't want arbitrary group members commanding it.
- **Broadcast groups** — send to multiple recipients.
## Identity links & docking
- **Identity links** (`session.identityLinks`) connect a user's identities across channels so a cross-channel DM maps to one person.
- **Channel docking** (`/dock`) moves an active session's **reply route** from one linked channel to another — e.g. start on Telegram, then have replies continue on Discord/Slack/Mattermost. Requires the sender to be linked and an active session to exist (the common `/dock` errors).
## Why it matters
Routing + access groups are the security and UX backbone for multi-channel use: the agent reaches you wherever you are, but only authorized identities can drive it. Pair with [security](security.md) and [delegate-and-multi-agent](delegate-and-multi-agent.md) for org deployments.
---
title: "Channels"
type: concept
tags: [channels, messaging, discord, telegram, whatsapp, imessage]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-channels-index-md.md, raw/github_doc-docs-channels-discord-md.md, raw/github_doc-docs-channels-imessage-md.md]
---
# Channels
**Channels** are the chat apps OpenClaw talks to you on. Each connects through the [Gateway](gateway-architecture.md); you message the agent on whatever app you already use.
## Supported channels
Built-in and bundled-plugin channels include **WhatsApp** (via Baileys), **Telegram** (via grammY), **Slack**, **Discord**, **Signal**, **iMessage**, **Matrix**, **Microsoft Teams**, **Google Chat**, **Zalo**, **IRC**, **LINE**, **Feishu**, plus **WebChat** and mobile **nodes**. New channels are added as plugins.
## Capabilities vary by channel
- **Text is supported everywhere**; media and reactions vary by channel.
- Channel-specific adaptations exist — e.g. Telegram replies containing markdown image syntax are converted into media replies on the outbound path; Slack multi-person DMs route as group chats (so group policy/mention rules apply).
## Channel concepts
- **Direct vs group** — DMs vs group/room messages; group behavior is governed by group policy and mention rules ([channel-routing-and-docking](channel-routing-and-docking.md)).
- **iMessage** — uses the bundled iMessage plugin with `imsg` (BlueBubbles support was removed).
- **Ambient room events** and **bot-loop protection** keep group behavior sane (avoiding bots replying to bots).
## Setup
Each channel has its own connection/auth (e.g. WhatsApp QR pairing, Telegram bot token, Slack app). Configure which channels are active in [configuration](configuration.md). Routing messages between channels and moving a live session's replies across channels is [channel-routing-and-docking](channel-routing-and-docking.md).
---
title: "Configuration"
type: concept
tags: [configuration, json5, config-file, setup]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-gateway-configuration-md.md, raw/github_doc-docs-gateway-configuration-reference-md.md]
---
# Configuration
OpenClaw reads an optional **JSON5** config from **`~/.openclaw/openclaw.json`** (JSON5 supports comments and trailing commas).
## The config file
- The active config path must be a **regular file** — symlinked `openclaw.json` layouts are unsupported for OpenClaw-owned writes (an atomic write may replace the path rather than preserve the symlink).
- OpenClaw may write to the config itself (e.g. onboarding, credential storage), using atomic writes.
- An onboarding **wizard** generates a starting config interactively.
## What it configures
- **Channels** — which [channels](channels.md) are active and their connection settings (`config-channels`).
- **Agents** — agent definitions, runtime/model selection (`config-agents`).
- **Tools** — which [tools/plugins](plugins-and-extensions.md) are enabled (`config-tools`).
- **Providers & auth** — [model provider](model-providers.md) keys/OAuth.
- **Automation** — [cron, hooks, standing orders](automation.md).
- **Gateway** — bind host/port, background-process behavior, discovery.
## Reference
The **configuration reference** documents every key; **configuration examples** show common setups. Because config can contain secrets (provider keys, channel tokens), protect the file and prefer environment-based secrets where supported ([security](security.md)). Validate with `doctor`/diagnostics ([gateway-architecture](gateway-architecture.md)) after changes.
---
title: "Context Engine & Memory"
type: concept
tags: [context-engine, memory, compaction, dreaming, commitments]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-concepts-context-engine-md.md, raw/github_doc-docs-concepts-compaction-md.md, raw/github_doc-docs-concepts-dreaming-md.md, raw/github_doc-docs-concepts-active-memory-md.md, raw/github_doc-docs-concepts-commitments-md.md]
---
# Context Engine & Memory
How OpenClaw decides what the model sees, and how it remembers across time — a distinctive part of the project.
## Context engine
A **context engine** controls how OpenClaw builds model context for each run: which messages to include, how to summarize older history, and how to manage the context window. It's **pluggable** — you can switch between the legacy engine and a plugin engine — and also manages subagent lifecycle. This is the component invoked at the "context assembly" stage of [the agent loop](the-agent-loop.md).
## Compaction
**Compaction** keeps long conversations within the model's context limit by summarizing/condensing older history rather than dropping it blindly — the runtime's mechanism for indefinite sessions without losing the thread.
## Active memory
**Active memory** is an optional, plugin-owned **blocking memory sub-agent** that runs during interactive chat to inject relevant memories into the session. You can enable it per-agent and tune its behavior without turning it on everywhere.
## Dreaming (background consolidation)
**Dreaming** is the background memory-consolidation system (in `memory-core`) that moves strong short-term signals into durable long-term memory, with **light, deep, and REM phases**. It keeps machine state in `memory/.dreams/` and writes human-readable output to `DREAMS.md` (a "Dream Diary") and dated phase reports. This is how the assistant "gets better the more you use it" without bloating live context.
## Commitments
**Commitments** are short-lived **inferred follow-up memories** — when enabled, OpenClaw notices a conversation created a future check-in opportunity and remembers to follow up, distinct from exact user-set reminders ([automation](automation.md)).
Together these make OpenClaw stateful and proactive rather than a stateless chatbot.
---
title: "Delegate & Multi-Agent (Organizations)"
type: concept
tags: [delegate, multi-agent, organization, identity, routing]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-concepts-delegate-architecture-md.md]
---
# Delegate & Multi-Agent (Organizations)
OpenClaw scales from a personal assistant to an **organizational delegate** — an agent with its own identity that acts *on behalf of* people, not as them.
## Delegate architecture
The goal is to run OpenClaw as a **named delegate**: an agent with its **own identity** that acts "on behalf of" humans in an organization. Crucially, the agent **never impersonates a human** — it's a distinct actor with its own name and authority, so actions are attributable and auditable.
This extends **multi-agent routing** from personal use into organizational deployments: multiple agents/identities, each with defined scope, reachable across [channels](channels.md).
## Why it matters
- **Attribution** — a delegate's actions are clearly the agent's, not a person's, which matters for trust, audit, and accountability.
- **Bounded authority** — the delegate's powers are defined by [standing orders](standing-orders.md) and gated by [access groups](channel-routing-and-docking.md).
- **Org reach** — team members in shared channels (Slack/Teams/etc.) interact with the same delegate, with routing deciding sessions and identity links connecting people across surfaces.
## Building toward it
Start from personal multi-agent routing, add **access groups** (who can command the delegate), **standing orders** (what it may do alone), distinct **auth profiles/credentials** per identity ([model-providers](model-providers.md)), and the [security](security.md) model. The delegate pattern is how OpenClaw becomes a coworker-like presence in an org rather than one person's tool.
---
title: "Gateway Architecture"
type: concept
tags: [gateway, architecture, websocket, control-plane]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-concepts-architecture-md.md, raw/github_doc-docs-gateway-background-process-md.md]
---
# Gateway Architecture
OpenClaw's runtime is built around **one long-lived Gateway** process.
## The Gateway
A single **Gateway** owns all messaging surfaces — WhatsApp (via Baileys), Telegram (via grammY), Slack, Discord, Signal, iMessage, WebChat, and bundled channel plugins ([channels](channels.md)). Centralizing them in one process means consistent session state, routing, and policy across every channel.
## Control plane (WebSocket)
Control-plane clients connect to the Gateway over **WebSocket** on a configured bind host (default local):
- the **macOS app**, the **CLI** ([openclaw-cli](../entities/openclaw-cli.md)), and a **web UI**,
- **automations** ([automation](automation.md)),
- **mobile nodes** and WebChat.
These send commands and receive streamed agent output; the Gateway is the single source of truth they all attach to. Connection authentication (who may attach to the Gateway) is distinct from model-provider auth ([model-providers](model-providers.md)).
## Background process & lifecycle
The Gateway runs as a persistent background service (daemon) so it's always reachable; it can be installed, started/stopped, and health-checked (`doctor`/diagnostics). Because it's always on, **API keys are usually the most predictable** provider-auth choice for the Gateway host. Discovery (Bonjour) lets local clients find it.
## Where the agent runs
Inside the Gateway, the [agent runtime](agent-runtime.md) executes [the agent loop](the-agent-loop.md) per session. Configuration for the whole thing is one JSON5 file ([configuration](configuration.md)).
---
title: "Installation & Deployment"
type: concept
tags: [install, deployment, docker, vps, self-hosting]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-install-docker-md.md, raw/github_doc-docs-install-fly-md.md, raw/github_doc-docs-install-digitalocean-md.md, raw/github_doc-docs-install-azure-md.md, raw/github_doc-docs-install-ansible-md.md, raw/github_doc-docs-install-bun-md.md, raw/github_doc-docs-gateway-background-process-md.md]
---
# Installation & Deployment
OpenClaw is self-hosted: you run the [Gateway](gateway-architecture.md) somewhere it can stay online and reach your [channels](channels.md).
## Where to run it
- **Local machine** — simplest; the Gateway runs as a [background process](gateway-architecture.md) on your own computer (good for personal use, but only available when the machine is on).
- **VPS / cloud** — for an always-on assistant: **DigitalOcean**, **Fly.io**, **Azure**, and generic VPS guides exist, as does **Ansible** for repeatable provisioning.
- **Docker** — the containerized path (`install-docker`, Docker VM runtime, `clawdock`), the most portable deployment; `docker-compose.yml` ships in the repo.
- **Bun** runtime for direct execution.
## Always-on considerations
- Run the Gateway as a **persistent service/daemon** so it survives reboots and is always reachable.
- Prefer **API keys** for provider auth on always-on hosts (predictable vs OAuth refresh) ([model-providers](model-providers.md)).
- Keep the config file and secrets protected ([configuration](configuration.md), [security](security.md)).
- Use `doctor`/diagnostics to verify health after deploy.
## Getting started
The onboarding **wizard** walks first-time setup (channels, provider, config). After install: connect a [channel](channels.md), pick a [provider](model-providers.md), then message your agent. End-to-end in [build-your-assistant](../syntheses/build-your-assistant.md). Keep your deployment current for fixes and improvements (see the project's releases).
---
title: "Model Providers & Authentication"
type: concept
tags: [providers, models, authentication, oauth, api-keys]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-gateway-authentication-md.md, raw/github_doc-docs-providers-anthropic-md.md, raw/github_doc-docs-providers-bedrock-md.md, raw/github_doc-docs-providers-cerebras-md.md, raw/github_doc-docs-providers-cohere-md.md, raw/github_doc-docs-providers-alibaba-md.md, raw/github_doc-docs-providers-cloudflare-ai-gateway-md.md, raw/github_doc-docs-providers-chutes-md.md, raw/github_doc-docs-providers-arcee-md.md, raw/github_doc-docs-auth-credential-semantics-md.md]
---
# Model Providers & Authentication
OpenClaw runs the [agent](agent-runtime.md) against pluggable **model providers** — you choose which LLM(s) back your assistant.
## Providers
A broad set is supported, each with its own page: **Anthropic** (Claude), **AWS Bedrock**, **Cerebras**, **Cohere**, **Alibaba**, **Cloudflare AI Gateway**, **Chutes**, **Arcee**, and more (plus speech/TTS providers like Azure Speech). Models are referenced by `provider/model` (e.g. `anthropic/*`).
## Authentication routes
For model providers OpenClaw supports:
- **API keys** — direct provider access with usage-based billing. For **always-on Gateway hosts, API keys are usually the most predictable** option.
- **OAuth / subscription** — sign-in flows for providers that offer them.
- **CLI reuse** — reuse an existing **Claude CLI / Claude Code** login on the same host (the agent drives that CLI), and Anthropic **setup-token**.
## Credential semantics
OpenClaw has canonical rules for **credential eligibility and resolution** across **auth profiles** — which credential applies to a given request, and how profiles resolve when several are configured. This matters when you mix API keys, OAuth, and CLI reuse, or run multiple agents/delegates with different identities ([delegate-and-multi-agent](delegate-and-multi-agent.md)).
## Note on naming
Provider/model authentication (above) is **separate** from **gateway connection** authentication (who may attach to the [Gateway](gateway-architecture.md) over WebSocket). Keep the two distinct when configuring.
---
title: "Plugins & Extensions"
type: concept
tags: [plugins, extensions, capabilities, agent-tools]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-plugins-architecture-md.md, raw/github_doc-docs-plugins-building-plugins-md.md, raw/github_doc-docs-plugins-agent-tools-md.md, raw/github_doc-docs-plugins-adding-capabilities-md.md]
---
# Plugins & Extensions
OpenClaw is extended through a **plugin system** with a defined capability model and ownership boundaries — most non-core functionality (channels, tools, memory features) is a plugin.
## What plugins can add
- **Agent tools** — new capabilities the [agent](agent-runtime.md) can call during [the loop](the-agent-loop.md).
- **Channels** — new messaging surfaces ([channels](channels.md)).
- **CLI backends** — alternative agent runtimes.
- **Memory/context engines** — e.g. active memory, plugin context engines ([context-and-memory](context-and-memory.md)).
- **HTTP/RPC admin** surfaces and bundles (groups of plugins).
## The capability model
The plugin architecture defines **ownership boundaries** — what a plugin owns vs what the core owns — and **contracts** plugins implement, loaded through a defined **load pipeline** with runtime helpers. This isolation is also a security boundary: a plugin's authority is scoped.
## Building a plugin
- Start with the practical "**adding capabilities**" / "**building plugins**" guides for the end-to-end flow (manifest, registration, contracts).
- Use the **agent-tools** API to expose new tools to the agent.
- The deep **architecture-internals** reference covers the capability model, ownership, and load pipeline for advanced work.
- **Bundles** package related plugins together.
## Why it matters
The plugin system is how OpenClaw stays a small core while supporting a huge surface (many channels, providers, tools). When you need a capability the core lacks, a plugin is the path — and the community ecosystem (ClawHub) distributes them. Security implications of third-party plugins are covered in [security](security.md).
---
title: "Security"
type: concept
tags: [security, threat-model, atlas, incident-response]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-security-threat-model-atlas-md.md, raw/github_doc-docs-security-incident-response-md.md, raw/github_doc-docs-security-network-proxy-md.md]
---
# Security
An always-on, tool-wielding, autonomous agent with access to your messaging accounts is a serious security surface — OpenClaw documents its model explicitly.
## Threat model (MITRE ATLAS)
OpenClaw's threat model is built on **MITRE ATLAS** (Adversarial Threat Landscape for AI Systems), the industry framework for documenting adversarial threats to AI/ML systems. It's a living, community-maintained document mapping concrete attack techniques (prompt injection, tool abuse, data exfiltration, model manipulation) to the ATLAS taxonomy and to OpenClaw's mitigations. There's also a formal-verification effort for parts of the system.
## Key risk areas (and controls)
- **Prompt injection via channels** — untrusted message content (and content the agent fetches) can try to hijack the agent. Controls: bounded authority via [standing orders](standing-orders.md), [access groups](channel-routing-and-docking.md), and approvals before high-stakes actions.
- **Credential exposure** — provider keys and channel tokens live in [config](configuration.md); protect the file, scope credentials per [auth profile](model-providers.md).
- **Plugin trust** — third-party [plugins](plugins-and-extensions.md) run with scoped capability; vet what you install.
- **Network** — a **network proxy** option controls/observes the agent's outbound traffic (egress control).
## Incident response
A documented **incident-response** process covers what to do if a key leaks or the agent is compromised: rotate credentials, revoke channel access, review transcripts/dream state, and update standing orders/access. Treat the Gateway host like any internet-exposed service.
## Operating posture
Least-privilege standing orders, strict access groups, approvals for destructive/outward actions, protected secrets, vetted plugins, and keeping OpenClaw **updated** (apply releases promptly; see [installation-and-deployment](installation-and-deployment.md)).
---
title: "Standing Orders"
type: concept
tags: [standing-orders, autonomy, authority, approvals]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-automation-standing-orders-md.md]
---
# Standing Orders
**Standing orders** grant your agent **permanent operating authority** for defined programs — the heart of running OpenClaw autonomously and safely.
## The idea
Instead of giving individual task instructions each time, you define **programs**: durable descriptions of what the agent is authorized to do on its own. This shifts the model from "command per task" to "delegate a standing responsibility."
## What they define
- **Autonomous scope** — what the agent may do **independently**, without per-task prompting.
- **Approval boundaries** — what still **needs human approval** before acting (the escalation line).
- **Multi-program structure** — several programs with clear boundaries and escalation rules, so different responsibilities don't bleed together.
## Why it matters
An always-on assistant that can act ([automation](automation.md)) needs explicit limits. Standing orders are how you say "you may triage and reply to routine messages, schedule things, and run these reports on your own — but ask me before spending money / sending to new people / taking destructive actions." They turn autonomy from a risk into a controllable contract.
## Pair with
- **Access groups** so only authorized people can interact ([channel-routing-and-docking](channel-routing-and-docking.md)).
- **Approvals** (the CLI/loop approval mechanism) for in-the-moment confirmations.
- **Delegate identities** for organizational deployments ([delegate-and-multi-agent](delegate-and-multi-agent.md)).
- The [security](security.md) model, since standing orders define real authority.
---
title: "The Agent Loop"
type: concept
tags: [agent-loop, sessions, lifecycle, tools]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-concepts-agent-loop-md.md, raw/github_doc-docs-concepts-agent-md.md]
---
# The Agent Loop
The **agentic loop** is the authoritative path that turns an incoming message into actions and a final reply while keeping session state consistent.
## The stages
1. **Intake** — a message arrives from a [channel](channels.md) and is routed to a session.
2. **Context assembly** — the [context engine](context-and-memory.md) builds what the model sees: which messages to include, how to summarize older history, injected memory.
3. **Model inference** — the chosen [provider](model-providers.md) streams a response.
4. **Tool execution** — the agent calls tools (and may spawn subagents); results feed back into the loop.
5. **Streaming replies** — partial output streams back to the channel as it's produced.
6. **Persistence** — the transcript and session state are written durably.
## Sessions
Each conversation is a **session** with persisted transcript and state. The runtime enforces a **session write lock** and **queueing** so concurrent messages to the same session don't corrupt state — a message that arrives mid-run is queued rather than racing the in-flight loop.
## Why it matters
Understanding the loop matters when you change session queueing, transcript writes, or lifecycle behavior, and when reasoning about how a single user message can produce many tool calls, subagent runs, and streamed updates before the final reply. The loop is implemented by the [agent runtime](agent-runtime.md); long-running work it kicks off is tracked as [background tasks](automation.md).
---
title: "What is OpenClaw"
type: concept
tags: [openclaw, overview, gateway, ai-agent]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-index-md.md, raw/github_doc-readme-md.md, raw/github_doc-vision-md.md]
---
# What is OpenClaw
**OpenClaw** is an open-source, self-hosted **gateway for AI agents** that runs on any OS. You run one long-lived **Gateway** process on your own machine (or server), connect it to the chat apps you already use, and message your AI assistant from anywhere — "an agent response from your pocket."
It was created by Peter Steinberger and evolved through several names: **Warelay → Clawdbot → Moltbot → OpenClaw**. It is a prominent, widely-adopted open-source project.
## The core idea
- **Gateway** — a single process that owns all your messaging surfaces and runs the [agent runtime](agent-runtime.md).
- **Channels** — it talks to you on Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo, IRC, LINE, and more ([channels](channels.md)). You text it like a friend; it replies with agent output.
- **AI coding agents** — behind the chat, OpenClaw drives an LLM-backed agent that uses tools, runs autonomously, and persists state ([the-agent-loop](the-agent-loop.md)).
- **Self-hosted** — you control where it runs and which [model providers](model-providers.md) it uses; no dependence on a vendor's cloud.
## What makes it distinctive
Beyond a chat bridge, OpenClaw adds a real agent platform: a pluggable [context engine](context-and-memory.md), a background **memory/dreaming** system, [automation](automation.md) (cron, hooks, **standing orders** for autonomous authority), [plugins](plugins-and-extensions.md), and **delegate** identities for organizations ([delegate-and-multi-agent](delegate-and-multi-agent.md)).
## Who it's for
Anyone wanting a persistent personal (or org) AI assistant reachable from their existing messaging apps, running on infrastructure they own. Start at [installation-and-deployment](installation-and-deployment.md), then [configuration](configuration.md). Full map: [docs-catalog](../summaries/docs-catalog.md).
---
title: "The OpenClaw CLI"
type: entity
tags: [cli, command-line, control-plane]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-cli-agent-md.md, raw/github_doc-docs-cli-channels-md.md, raw/github_doc-docs-cli-approvals-md.md]
---
# The OpenClaw CLI
The **CLI** is one of the control-plane clients that connects to the [Gateway](../concepts/gateway-architecture.md) over WebSocket — for operating OpenClaw from the terminal alongside the macOS app and web UI.
## Command areas
The CLI mirrors the platform's surfaces (one subcommand group each):
- **`agent` / `agents`** — drive and manage agents/sessions.
- **`channels`** — connect, list, and manage [channels](../concepts/channels.md).
- **`approvals`** — review and grant in-the-moment approvals the agent requests (the human-in-the-loop gate that pairs with [standing orders](../concepts/standing-orders.md)).
- **`message`** — send messages / polls programmatically.
- **`acp`** — Agent Control Protocol runs.
- **`browser`** — browser tool control.
- **`backup`** — back up state/config.
- **`commitments`** — manage inferred follow-ups ([context-and-memory](../concepts/context-and-memory.md)).
- **`completion`** — shell completion.
- **`clawbot`** — bot operations.
## Why use it
- **Automation & scripting** — drive the Gateway from scripts/CI ([automation](../concepts/automation.md)).
- **Headless operation** — manage a server deployment with no GUI ([installation-and-deployment](../concepts/installation-and-deployment.md)).
- **Approvals** — process the agent's approval requests from the terminal.
The CLI, macOS app, web UI, and automations are interchangeable front-ends over the same [Gateway](../concepts/gateway-architecture.md); use whichever fits the context. The full command reference is in [docs-catalog](../summaries/docs-catalog.md).
---
title: "Activity Log"
type: log
---
# Activity Log
Append-only record of all wiki changes.
## Format
Each entry follows this format:
```
### YYYY-MM-DD HH:MM — [Action Type]
- **Source/Trigger**: what initiated the action
- **Pages created**: list of new pages
- **Pages updated**: list of updated pages
- **Notes**: any contradictions flagged, decisions made
```
---
### 2026-04-08 00:00 — Setup
- **Source/Trigger**: Repository initialized
- **Pages created**: index.md, log.md, dashboard.md, analytics.md, flashcards.md
- **Pages updated**: none
- **Notes**: Empty knowledge base ready for first source ingestion
### 2026-06-19 00:00 — Initial curation (medium rung)
- **Source/Trigger**: 123 openclaw/openclaw docs pages (per-dir fetchers) + README/VISION
- **Pages created**: 15 concepts, 1 entity (openclaw-cli), 1 summary (docs-catalog), 1 synthesis (build-your-assistant)
- **Pages updated**: index.md
- **Notes**: OpenClaw is a post-training-cutoff project (researched via web search: open-source self-hosted AI agent gateway by Peter Steinberger, ex-Warelay/Moltbot, ~380k stars). Curated strictly from first-party repo docs. Redirect-stub doc pages skipped. Category: agents.
---
title: "Docs Catalog"
type: summary
tags: [catalog, map, reference]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-index-md.md, raw/github_doc-docs-concepts-architecture-md.md]
---
# Docs Catalog
Map of the OpenClaw docs this wiki distills (openclaw/openclaw `docs/`, also at docs.openclaw.ai; mirrored in `raw/` as `github_doc-docs--.md`).
| Area | Raw prefix | Wiki coverage |
|---|---|---|
| Overview | `index`, `readme`, `vision` | [what-is-openclaw](../concepts/what-is-openclaw.md) |
| Concepts | `concepts-*` (architecture, agent-loop, agent-runtimes, context-engine, compaction, dreaming, active-memory, commitments, delegate-architecture, channel-docking, agent-workspace) | [gateway-architecture](../concepts/gateway-architecture.md), [the-agent-loop](../concepts/the-agent-loop.md), [agent-runtime](../concepts/agent-runtime.md), [context-and-memory](../concepts/context-and-memory.md), [delegate-and-multi-agent](../concepts/delegate-and-multi-agent.md) |
| Gateway | `gateway-*` (configuration, authentication, background-process, doctor, discovery, bridge-protocol) | [gateway-architecture](../concepts/gateway-architecture.md), [configuration](../concepts/configuration.md), [model-providers](../concepts/model-providers.md) |
| Channels | `channels-*` (discord, imessage, line, irc, feishu, googlechat, routing, groups, access-groups, docking) | [channels](../concepts/channels.md), [channel-routing-and-docking](../concepts/channel-routing-and-docking.md) |
| Automation | `automation-*` (cron-jobs, hooks, standing-orders, taskflow, tasks) | [automation](../concepts/automation.md), [standing-orders](../concepts/standing-orders.md) |
| Providers | `providers-*` (anthropic, bedrock, cerebras, cohere, alibaba, cloudflare-ai-gateway, …) | [model-providers](../concepts/model-providers.md) |
| Plugins | `plugins-*` (architecture, building-plugins, agent-tools, adding-capabilities, bundles, cli-backend) | [plugins-and-extensions](../concepts/plugins-and-extensions.md) |
| Install | `install-*` (docker, fly, digitalocean, azure, ansible, bun, clawdock) | [installation-and-deployment](../concepts/installation-and-deployment.md) |
| Security | `security-*` (threat-model-atlas, incident-response, network-proxy, formal-verification) | [security](../concepts/security.md) |
| CLI | `cli-*` (agent, channels, approvals, message, acp, browser, backup, commitments) | [openclaw-cli](../entities/openclaw-cli.md) |
## Notes
- The docs contain many **redirect stubs** (e.g. `automation/clawflow` → Task Flow, `automation/webhook` → cron-jobs); these were skipped in curation — follow the canonical page.
- Reference-heavy material (full configuration reference, provider-by-provider keys, full CLI command reference) is mapped here but not reproduced — read the specific `raw/` page or docs.openclaw.ai.
- OpenClaw moves fast (frequent releases); verify version-specific details against the live docs.
---
title: "Building Your Assistant (End to End)"
type: synthesis
tags: [getting-started, workflow, synthesis]
updated: 2026-06-19
confidence: high
sources: [raw/github_doc-docs-index-md.md, raw/github_doc-docs-gateway-configuration-md.md, raw/github_doc-docs-automation-standing-orders-md.md, raw/github_doc-docs-security-threat-model-atlas-md.md]
---
# Building Your Assistant (End to End)
The path from install to a useful, safely-autonomous OpenClaw, tying the concept pages together.
## 1. Deploy the Gateway
Pick where it runs — local for testing, a [VPS/Docker](../concepts/installation-and-deployment.md) for always-on. Run the [Gateway](../concepts/gateway-architecture.md) as a persistent service.
## 2. Connect a model provider
Add a [provider](../concepts/model-providers.md) (Anthropic, Bedrock, etc.). On an always-on host, prefer an **API key** for predictable auth. Confirm with `doctor`.
## 3. Connect a channel
Link the chat app you live in ([channels](../concepts/channels.md)) — Telegram bot token, WhatsApp QR, Slack app, iMessage, etc. Now you can message the agent.
## 4. Configure
Set everything in `~/.openclaw/openclaw.json` ([configuration](../concepts/configuration.md)) — active channels, agent/model selection, enabled [tools/plugins](../concepts/plugins-and-extensions.md). Use the onboarding wizard for a starting point.
## 5. Lock down access
Define **access groups** so only you (or your team) can command the agent ([channel-routing-and-docking](../concepts/channel-routing-and-docking.md)). This is step zero of [security](../concepts/security.md) — an open agent on a public channel is dangerous.
## 6. Grant bounded autonomy
Write **standing orders** ([standing-orders](../concepts/standing-orders.md)): what the agent may do alone vs. what needs approval. Add [automation](../concepts/automation.md) (cron check-ins, hooks) within those bounds.
## 7. Let it learn
Enable [memory](../concepts/context-and-memory.md) (active memory, dreaming, commitments) so it improves over time and follows up proactively.
## 8. Extend as needed
Add [plugins](../concepts/plugins-and-extensions.md) for new tools/channels; for an org, move to a [delegate identity](../concepts/delegate-and-multi-agent.md).
## Safety checklist
Access groups set · standing orders bounded · approvals on destructive/outward actions · secrets protected · plugins vetted · network egress considered · OpenClaw kept updated ([security](../concepts/security.md)).