How Matthew Berman Organizes and Secures His OpenClaw Setup

NVIDIA CEO Jensen Huang opens by arguing that enterprises and software companies need an agent strategy. After spending extensive time on my OpenClaw setup, I want to share the practices I use to make the assistant easier to work with and maintain. These are my configuration choices, not guarantees that every setup will behave the same way.

One of the simplest improvements is to split conversations into topic threads. A single long chat mixes unrelated subjects and makes it awkward to return to a previous task; it also puts a lot of unrelated context into the conversation. I use a Telegram group containing my bot and me, with separate topics for general work, customer relationships, my knowledge base and scheduled updates.

Each topic in my setup has its own session and focused context, making it easier to resume one conversation while another is underway. I find this helps the agent stay on topic and helps me navigate my work. The same principle can apply to other messaging platforms that support suitable threading.

Voice messages are another useful mobile interface. I hold the microphone button in Telegram, speak a question or task, and receive a response without typing a long prompt. I use it for questions, tasks and coding requests. The capabilities available depend on the messaging integration and how the assistant is configured.

The sponsor of this video is here.now, a service for publishing agent-created artifacts such as static pages, images and PDFs. I ask my agent to publish an Eiffel Tower explanation, then revise the page to text only. Berman says an unclaimed page expires after 24 hours and an account can claim it for longer use; service terms and pricing can change.

I do not use one model for every task. At the time of this video, I use Anthropic models for much of my main chat and coding, GPT-5.4 as a fallback, Grok for search, Gemini for video and research, Nomic for embeddings, and Qwen for local work. These are my personal choices and I change them as models, availability and quotas change.

The main model plans and delegates, so I generally favor a capable model there. Simpler work may be faster and cheaper with a smaller model. OpenClaw has configuration for models and fallbacks, and I can check the main session with `/status`; assignment is not perfectly deterministic, so I still check what actually ran.

In my setup I can also assign a model to a specific thread: a simple question-and-answer thread may not need the same model as difficult coding. Choosing based on the work can help manage token use, latency and cost. Whether a smaller model is sufficient should be measured against the actual task.

I am exploring replacing suitable frontier-model tasks with fine-tuned local models. For email labeling I collected labeled examples and trained a 9-billion-parameter Qwen model; in my own use, I say it performs as well as Opus 4.6 on that specific task. This is my experience, not a general comparison or a published benchmark; local hardware and training still have costs.

I delegate longer tasks so the main agent is not blocked while I continue the conversation. My rule is to delegate work expected to take over ten seconds, including coding, searches, multi-step processing, file operations and calendar or email work. Simple replies, clarifications and quick reads stay with the main agent. Delegation can still fail or choose the wrong route.

The main agent can assign different models to sub-agents and can also invoke coding harnesses such as Cursor Agent or Claude Code. A harness can execute a task and return a summary through the sub-agent to the main agent. I prefer to delegate early, selecting a cheaper model for simple jobs and a stronger one where the task warrants it.

Different models may respond differently to prompt structure, so I maintain separate versions of my instruction files for different model families. I use each provider’s prompting guidance as a starting point and tell OpenClaw which files to use. My examples about capitals or negative instructions are heuristics, not universal rules; test prompts against the task and model.

I keep a primary set of instructions and a separate fallback set, then run a nightly job to compare them. The job checks that the instructions remain consistent in substance while reflecting each model’s prompting guidance. Documenting that arrangement helps the agent select the intended version.

Scheduled jobs, or crons, perform recurring work without my having to ask each time. I spread many daily maintenance tasks through the night, when I am less likely to be using the system, to reduce contention and manage my rolling usage allowance. Examples include checking job health, prompt and configuration consistency, and backups.

Other jobs run every few hours, including HubSpot and Asana synchronization and a review for personal information or secrets. Scheduling makes recurring work convenient, but jobs still need monitoring: an authentication failure or other error can affect multiple dependent tasks.

Security matters because an agent can read untrusted external content and use powerful tools. Prompt injection is an attempt to put instructions in a webpage, email or other material that diverts the agent from its authorized task. I treat incoming material as potentially untrusted and use several defenses; no scanner alone can guarantee it will catch every attack.

My first layer uses conventional code to scan incoming text for suspicious patterns and unusual characters. A second, model-based scanner reviews material that passes the first layer, assigns a risk score and can quarantine it. Both pattern matching and model review can miss attacks or flag harmless content, so I do not treat them as a complete security boundary.

I also inspect outbound content for secrets and personally identifying information and redact aggressively. Sometimes that means I must explicitly authorize information that is safe to share. Redaction is another safeguard rather than proof that every sensitive value will be detected.

I scope permissions narrowly: my assistant can read my email but cannot send it, and can read Box files but cannot delete them. Destructive actions require my approval. These restrictions limit what an injected instruction or mistaken agent can do even if earlier screening fails.

Another concern is wallet draining: an attacker could send enough material to consume the model budget used by a security scanner. A runaway loop can create a similar cost. My runtime governance uses spending caps, volume limits and loop detection to constrain both cases.

I keep logs so I can investigate failures instead of guessing. Each morning I ask the system to review overnight errors and propose fixes. In the example shown, a Google authentication problem affected an inbox refresh and calendar-dependent daily brief, alongside a smaller code bug. Logs can contain sensitive information, so their access and retention need care.

I check for OpenClaw updates regularly using a scheduled job that summarizes the changelog and updates the installation. Security fixes matter, but automatic updates and restarts can also disrupt a setup; testing and a recovery path are useful. The appropriate update cadence depends on the deployment.

I recommend evaluating subscription access against API pricing for your workload. I describe ways I use provider subscriptions in my setup, but permitted integrations, usage limits and pricing vary. Check the current provider terms and documentation for the specific application rather than assuming all OAuth or SDK uses are allowed; [OpenAI describes supported plan use in participating apps](https://help.openai.com/en/articles/20001542-using-your-chatgpt-plan-in-other-apps-and-sites).

Documentation makes the system easier to operate. I maintain a product requirements document, workflow descriptions, workspace organization, prompting guides and security notes, as well as a learnings file for mistakes. A daily job compares documentation with code and commits to identify gaps, although generated updates still need review.

Git records versions of the code, making it possible to inspect recent changes or restore an earlier state. I also push snapshots to GitHub as an off-device copy. Databases, images and PDFs need separate backups when they are not in Git; I use Box for those files. A backup is useful only if it can be restored.

Tests check whether code behaves as intended. My simple example is verifying that two plus two equals four; for real systems, tests should exercise meaningful behavior and failure cases. Logging, documentation, version control, separate backups and testing all help keep an evolving agent setup manageable.

To reduce interruptions from scheduled work, I batch low-priority notifications into a three-hour digest and higher-priority items into an hourly digest. Critical incidents, such as the assistant being unavailable, bypass the batch and alert me immediately. I can ask for more detail when a digest identifies something worth investigating.

Finally, I prefer building and modifying the OpenClaw system in a separate coding environment, such as Cursor, while using Telegram for everyday interaction. Codex, Claude Code or a text editor can also be used. A dedicated development interface makes code easier for me to inspect and iterate on than a chat window.