OpenClaw: designing a persistent assistant around a trusted gateway

OpenClaw is an open-source, self-hostable assistant platform that connects chat channels and other interfaces to agents, models, tools, and persistent state. Its gateway coordinates these capabilities. The application can act through configured tools; the language model proposes actions and consumes their results. OpenClaw is MIT licensed. Product details in this chapter were checked against official documentation on September 24, 2026. Project documentation.

The interview value is architectural: explain how a persistent assistant knows who is speaking, which conversation to use, what it may do, where it executes, and what survives failure. A personality file or a collection of plugins does not answer those questions by itself.

Define the deployment before selecting features

OpenClaw's security guidance explicitly treats one gateway as one trust boundary. Team operation is supported; an arbitrary “more than ten people is unsupported” threshold is not a sound criterion. The relevant question is whether those people may share the agent's delegated authority. Mutually adversarial customers need stronger separation.

Understand the current architecture and version boundary

Older installations and tutorials may use agents.list, JSON session stores, or a different runtime description. Current documentation uses agents.entries, an OpenClaw-owned embedded runtime, and SQLite-backed active state. Use the installed release's schema and migration tooling; a familiar project name does not imply that an old configuration remains valid. See agent runtime.

Follow an incoming request

flowchart TD
    C[Chat channel or Control UI] --> I[Authenticate source and normalize event]
    I --> R[Route to agent, account and session]
    R --> Q[Admission and active-run queue]
    Q --> P[Assemble authorized context<br/>instructions, history, skills and memory]
    P --> M[Configured model or external harness]
    M --> T[Proposed tool call]
    T --> G[Deterministic tool policy<br/>and execution checks]
    G --> X[Configured executor<br/>sandbox, node or permitted host]
    X --> O[Observation and artifacts]
    O --> P
    M --> D[Reply through intended channel]
    R <--> S[Durable runtime databases]
    O --> S

The diagram shows responsibilities, not a promise that every component is a separate service. For a personal deployment, keeping the gateway together reduces coordination overhead. Separate execution environments prevent tool workloads from inheriting the control plane's full host access.

Component responsibilities

A paired node is another execution surface, not a synonym for a model server. A plugin may run on the trusted gateway. A sandbox around shell execution does not automatically isolate every plugin or outbound message.

Agents, accounts, sessions, and people

These identifiers solve different problems:

The multi-agent documentation describes separate workspaces, agent directories, auth profiles, and session stores. It also documents shared surfaces: plugin storage may remain global, ordinary cross-agent session access is enabled by default under its policy, and some OAuth behavior can reuse the main agent's matching profile. A workspace is a working directory, not a filesystem sandbox. Use independent accounts and restrictive policies where separation matters.

A current routing fragment looks like this. It assumes the support agent and the Slack work account already exist; it configures routing, not authentication or permissions:

{
  "bindings": [
    {
      "agentId": "support",
      "match": { "channel": "slack", "accountId": "work" }
    }
  ]
}

Inspect the effective bindings rather than assuming an agent's display name selects a channel. Source-account identity, message admission, tool authority, and conversation routing must all agree.

Session isolation and cross-channel continuity

The personal default shares direct-message context, while groups and rooms normally have separate sessions. For multiple senders, configure an appropriate session.dmScope; per-account-channel-peer separates account, channel, and sender. Verified identityLinks can associate a person's channel identities where shared continuity is intended. Platform-specific thread rules still apply. See session management.

flowchart LR
    A[Person A on Slack] --> V[Verified identity mapping]
    B[Person A on Telegram] --> V
    V --> P[Permitted private conversation scope]
    C[Person B on Slack] --> O[Separate private conversation scope]
    G[Shared team room] --> R[Room conversation scope]
    P --> M[Recall policy for each request]
    O --> M
    R --> M

Design example: a private discussion of a customer's account must not appear in a public support room merely because both conversations use the same assistant. Separate session transcripts are necessary but may be insufficient: inspect shared workspace memory, plugin vaults, explicit session tools, cross-provider sends, and operator permissions.

What a channel adapter must preserve

1. Provider, connected account, stable sender ID, conversation/thread ID, and event ID.
2. Authentication/signature evidence appropriate to that provider.
3. Message text and attachments marked according to their provenance.
4. Reply destination and visibility, independent of model-generated recipient text.
5. Delivery status and retry information without inventing a successful send.

Use the selected channel's official guide for current settings. Telegram uses fields such as botToken, dmPolicy, and allowFrom; old examples using generic token and allowedUsers should not be assumed valid. A missing channel-account owner may block that account until its binding is configured. Do not infer equivalent configuration or delivery guarantees across Slack, Telegram, WhatsApp, Discord, Signal, iMessage, Teams, and other adapters.

State, memory, and instructions

Runtime state survives ordinary restarts

The default global runtime database is ~/.openclaw/state/openclaw.sqlite; per-agent state lives in ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite. Active session history is SQLite-backed. JSON/JSONL files can exist as migration inputs, exports, or archives; they are not the current active-store contract. See runtime storage.

An ordinary restart does not inherently erase history. Recovery can resume interrupted work within documented limits. Explicit incognito sessions are different and can expire on restart; tool writes outside the session store can still persist. A durable transcript also cannot tell you whether an external action completed during a lost response. Use the source service's state for that decision.

Workspace files have distinct jobs

See workspace behavior. There is no need to create a universal Memories/ directory and assume the runtime recognizes it.

Memory is a write-and-retrieval system

Current OpenClaw memory combines files, a SQLite index, provenance, and gated consolidation. Episodic notes/transcripts can be searched; curated core information is eligible for automatic context under the memory runtime's rules. Background “dreaming” consolidates candidates rather than treating every observed sentence as a permanent user fact. Source classification has limits, including tools that do not declare network-derived results. See memory architecture.

flowchart LR
    I[Permitted observations and notes] --> P[Record origin, time and source]
    P --> E[Episodic evidence and search index]
    E --> G[Promotion eligibility checks]
    G --> C[Bounded consolidation]
    C --> M[Curated memory]
    E --> R[Request-scoped retrieval]
    M --> R
    R --> V[Recheck relevance and access before use]

Interview tip: identify write quality before adding another vector database. Duplicates, wrong-user facts, outdated preferences, and prompt-injection content can make retrieval worse even when similarity search works perfectly. Evaluate recall and contamination separately. See long-term memory.

Skills: useful guidance with a supply-chain boundary

A skill is a directory containing SKILL.md metadata and instructions, optionally with scripts or references. OpenClaw filters eligible skills and presents a compact catalog to the agent. Eligibility, selection, and execution permission are separate decisions. Current roots include workspace skills, project/personal .agents/skills, managed skills, Workshop outputs, bundled skills, and configured extra/plugin directories. Highest-precedence same-name sources win; personal library revisions have separate selection rules. See skills.

An original read-only deployment-review skill could be:

---
name: deployment-status-review
description: Compare a requested release revision with CI and application health evidence.
---

1. Identify the intended environment and release revision.
2. Use the configured read-only CI and health tools.
3. Compare the exact deployed revision, not only an HTTP 200 response.
4. Report passed, failed, pending, or unknown evidence separately.
5. Do not deploy, modify configuration, or send a message unless that work is authorized.

This example uses standard name/description metadata. Invented triggers or tools frontmatter fields should not be presented as an enforcement mechanism. Configure the real tool policy separately.

A trusted source is useful evidence, not proof that every future update is safe. For a production workflow, review changes before broad rollout and test the exact effective skill/tool set. Avoid loading a large unused catalog simply because it exists.

Models, runtimes, accounts, and billing

Use canonical provider/model references from the current installed catalog. For example, current OpenClaw documentation includes anthropic/claude-opus-5-5. The same model reference can have different execution routes, such as a direct API or supported Claude CLI runtime. Model availability, account selection, context limits, and billing must all be checked for that route. See Anthropic integration.

Do not label all local models low quality or all hosted models appropriate for sensitive data. Test the chosen workload and deployment. A provider-compatible API can still differ in tool schemas, streaming, reasoning controls, and model behavior.

Provider-policy changes belong in the operating plan

As checked for this review, Anthropic's June 15 update paused the proposed separate Agent SDK credit. Agent SDK, claude -p, and supported third-party usage continue drawing from subscription limits; the announced monthly credit is unavailable. API-key billing is separate. The notice takes precedence over the older retained text on the same page. See the current help-center update.

For a shared service, budget against the actual supported access path. Keep provider restrictions, credentials, quotas, and model behavior in the dependency inventory. A fallback is useful only if switching preserves data policy and acceptable quality. Repeatedly retrying an authorization failure is not a fallback strategy.

Enforce identity and scope outside the model

OpenClaw supports configurable execution sandboxes; sandboxing is off by default. Tool policy and the chosen backend determine whether execution uses the gateway host, an isolated runtime, or a paired node. A sandbox's restricted network does not prevent disclosure through a separately permitted message or gateway tool. See the execution trust boundary.

Current hardened-baseline guidance recommends a local authenticated gateway, scoped sessions, limited tools, and restricted cross-agent access. Sender-specific tool rules apply to the current requester; they do not sanitize all third-party text already present in that request's context.

For a read-only support pilot, start with approved lookup tools and no shell, deployment, or send capability beyond the intended reply path. Add each capability only when it has a concrete requirement and verification method. For outbound communications, validate recipients and visibility at the dispatch boundary.

Team collaboration does not imply hostile-tenant isolation

Current team setup supports identity-aware ingress, named operator roles, shared sessions, and sandbox-required guest work. A shared token identifies a common owner rather than proving which person acted. Individual authentication is valuable when attribution matters.

Multi-user mode distinguishes immutable creator, assignable owner, and participants. Changing an assignee changes responsibility, not sharing authority. A sidebar filter or avatar is not access control. Public transcript sharing is an explicit separate capability with its own exposure; do not turn a private support session into a public link as an ordinary reporting step.

For mutually untrusted customers, separate gateway state, credentials, execution identities, storage, and network authority. A Kubernetes namespace alone is insufficient: configure workload identity, storage isolation, network policy, host access, and administrative boundaries.

Deployment and operations

flowchart TD
    U[Authorized operators] --> I[Identity-aware HTTPS ingress]
    C[Configured chat providers] --> G[Gateway in trusted control plane]
    I --> G
    G --> D[Protected runtime databases<br/>and workspace artifacts]
    G --> M[Approved model route]
    G --> W[Restricted execution workers]
    W --> T[Scoped service adapters]
    D --> B[Encrypted consistent backups<br/>and restore verification]
    G --> O[Redacted operational telemetry]

A gateway packaged in Docker is not the same as sandboxing its agent tools. Never infer the tool sandbox from the packaging diagram.

Remote access needs both proxy and gateway configuration

Use authenticated ingress and restrict direct access to the gateway. Configure exact trusted proxy addresses, overwrite forwarded-client headers at that proxy, preserve supported WebSocket behavior, and allow only intended browser origins. Current OpenClaw rejects unconfigured proxy attribution on protected routes rather than blindly treating forwarded traffic as trusted localhost. See network exposure.

A CDN or TLS certificate authenticates neither the human operator nor the intended tool operation. Avoid a generic reverse-proxy snippet that omits the gateway's authentication, origin, and trusted-proxy requirements.

Backup and upgrade discipline

The current state contract includes schema versions and guarded upgrades. Use supported backup/migration commands, preserve the workspace and runtime databases together, and restore into a separate location for verification. Downgrading the executable does not necessarily make it compatible with a newer on-disk schema. See versioned state and upgrades.

1. Record the installed release, provider/runtime routes, configuration, and plugin revisions.
2. Create and verify a consistent backup under the current release's supported method.
3. Review migration notes and test a representative restored deployment.
4. Upgrade a controlled instance; verify identity, routing, history, tools, and schedules.
5. Promote only after acceptance checks; keep a compatible recovery path.

A raw copy of a live SQLite file may omit relevant write-ahead-log state. Backup success means a restore was exercised, not merely that an archive exists.

Background work: choose the right lifecycle

Current automation documentation distinguishes explicit scheduled jobs, heartbeat monitoring, background-task records, task-flow orchestration, and lifecycle hooks. Tasks record detached work; they are not themselves a scheduler. Heartbeat and explicit automations share scheduling infrastructure but differ in purpose and delivery.

A HEARTBEAT.md instruction is not a substitute for a durable schedule. Pin job identity, execution scope, timezone, misfire behavior, destination, and cancellation semantics. Scheduled tasks should not silently inherit broader privileges because an administrator later views or reassigns them.

Capacity and cost: separate the gateway from the workload

There is no universal “512 MB is enough” deployment size. Gateway state, browser processes, code workers, memory indexing, local inference, and concurrent tasks have different requirements. Measure resident memory, queue age, active turns, open browsers, tool latency, and provider quotas.

Assume a trusted 25-person team creates 20 turns per person during an eight-hour day. With an illustrative 10× sustained peak and 15-second mean active turn:

Five slots are an initial capacity hypothesis, not an OpenClaw benchmark or tail-latency guarantee. A large attachment, browser workflow, or constrained provider quota can dominate the result. One shared conversation may also serialize work independently of available machine capacity.

Context and model optimization

1. Keep instruction catalogs and returned tool output focused on the task.
2. Preserve durable evidence while compacting old conversational detail.
3. Retrieve relevant memory rather than repeatedly sending every note.
4. Measure reasoning effort, model choice, cache use, and failure/review rates together.
5. Use bounded admission and task deadlines before adding more workers.

Dense attention has a quadratic pairwise component during full prefill, but doubling prompt length does not universally quadruple total request time. Cached prefixes, decoding, architecture, kernels, and fixed overhead all matter. See inference fundamentals. Lower reasoning effort is a quality/latency tradeoff, not a guaranteed 50% saving.

Worked monthly operating cost

At 500 turns/day and 22 workdays, assume 11,000 turns/month. If measured model/tool cost averages $0.04 per turn, compute is $60/month, storage/monitoring is $20, and operations take two hours at $100/hour:

11,000 × $0.04 + $60 + $20 + 2 × $100 = $720/month.

Suppose 10% of turns need one minute of review at $60/hour: add $1,100, for $1,820/month before development and any other channel/service fees. All rates here are hypothetical. The model component alone is $440, so quoting only that figure understates the operating plan.

Practical uses with bounded authority

These are design examples, not claims about named customer deployments.

Recognize where a different architecture is needed

• Hard real-time control: use deterministic control systems for strict deadlines; the assistant can explain or propose changes outside the critical loop.
• Money movement or safety-critical actions: use authoritative policy and transaction services, plus appropriate human decisions, around a bounded assistant.
• Hostile multi-tenancy: design separate trust boundaries and verify every shared service.
• Unsupported channel behavior: use a supported adapter or narrow the product scope; avoid promising arbitrary application coverage.
• Regulated data: evaluate the actual controls, agreements, retention, and evidence. A vendor label or open-source license is not a compliance conclusion.

Compare alternatives by responsibility

If the task is mainly interactive coding, a coding product may provide the required workflow directly. If it is a durable, fixed business process, a workflow engine with a small model step may be simpler. If it requires persistent cross-channel assistance, OpenClaw is a useful candidate. Compare other personal-agent projects, such as Hermes, using their current documented runtime and access model rather than a blanket “learns versus does not learn” distinction. See the current tool-agent landscape.

A controlled learning setup

The current getting-started guide requires Node.js 24.16+ or 26.1+ and recommends Node 26. Use its supported installer/onboarding path for your platform; inspect the release you install. The guide's npx openclaw@latest path is convenient for exploration; record/pin an evaluated release for reproducible operation.

After installation and configured authentication, these commands from the CLI reference inspect the setup:

openclaw --version
openclaw gateway status
openclaw agents list --bindings
openclaw security audit
openclaw doctor

Service installation is a separate operation (openclaw gateway install). openclaw doctor --fix can migrate/modify state; use it after backup and reading the reported repair. These commands are reference-checked here, not evidence of a runtime deployment test.

For the first exercise:

1. Use a dedicated workspace and a local authenticated gateway.
2. Connect only one permitted operator/channel and verify its agent binding.
3. Start with a read-only task and inspect the actual tool inventory.
4. Test an unapproved sender and confirm that no task is admitted.
5. Restart after a harmless task; verify history and intended recovery behavior.
6. Add one capability at a time, including a failure and cancellation exercise.

Interview exercise: build a team operations assistant

Scope: 25 trusted colleagues need chat-based deployment status, repository questions, and draft change proposals. Assume the workload estimated above. Production writes and public publication are outside the initial scope.

Functional requirements

1. Support a selected team chat and authenticated operator interface.
2. Route messages to the correct agent and conversation.
3. Retrieve deployment/CI evidence for an exact revision.
4. Answer repository questions with relevant references.
5. Produce scoped draft changes and validation artifacts.
6. Resume interrupted work and report uncertain external outcomes.
7. Run a daily status report with controlled delivery.

Non-functional requirements

1. Enforce tool, file, credential, and conversation scope.
2. Preserve individual attribution in shared sessions.
3. Bound task time, spending, queue length, and execution resources.
4. Back up and recover state within an agreed recovery objective.
5. Keep private content out of public transcripts and unnecessary logs.
6. Measure accepted outcomes, false status reports, recovery time, and full cost.

Basic design: one gateway for the trusted team, identity-aware ingress, explicit channel bindings, a scoped CI/repository tool set, and isolated code execution. Use existing CI and source control as evidence systems.

Find the flaw: a shared MEMORY.md says “production is healthy” after yesterday's check. The agent repeats it as today's result.

Repair: treat remembered status as historical context. Read current health and exact deployed revision for a status answer, retain the timestamp and evidence, and report unavailable evidence as unknown. Benefit: fresh, auditable answers. Cost: extra service calls and dependence on source availability.

Find a second flaw: two background workers edit the same checkout. Repair: assign isolated workspaces and integrate their artifacts against an explicit revision. This adds setup and merge work but prevents accidental overwrite and makes review meaningful.

Interview questions and answer notes

1. Is OpenClaw a language model? No. It is an assistant platform that coordinates models, tools, interfaces, and state.
2. Does self-hosting keep all data local? No. Inspect inference, channel, telemetry, plugin, and tool destinations.
3. Does a gateway restart lose every conversation? No. Ordinary active history is persisted; incognito and external-operation state have different semantics.
4. Are two agent directories a hostile-tenant boundary? No. Inspect shared host authority, plugin stores, session policy, and credentials; use stronger separation when needed.
5. Why are channel identity and gateway identity different? A provider sender ID and an authenticated operator profile come from separate trust paths. Link them only through verified mapping.
6. Does a skill's description permit its tools? No. The runtime's effective tool and execution policy governs capability.
7. Can a sandbox with no network leak data? Its own process network is restricted, but other allowed tools or the controller may still send data. Check the complete path.
8. Does assigning a new session owner transfer sharing rights? No. Responsibility, creator attribution, and access are distinct.
9. Why is provider billing part of reliability design? Unsupported credentials, exhausted quotas, or policy changes can stop work or change its cost.
10. What would you monitor first? Incorrect/unsafe outcomes, unknown side effects, queue age, tool/provider failures, recovery, and total cost per useful outcome.
11. When should the gateway become several services? When measured load, trust separation, ownership, or availability requirements justify the added coordination.
12. What is the closing tradeoff? A gateway simplifies a trusted assistant deployment; stronger customer isolation and critical workflows need additional enforced boundaries.

Final notes

Remember identity → routing → context → policy → execution → evidence. Persistent memory improves continuity; durable state improves recovery; neither grants authority. A good interview answer explains the current implementation, its limits, and the extra controls required by the proposed deployment.

Next: Computer-use agents.