A few newbie questions this week asked where to run an agent: a VPS or a hosted sandbox. If you pick the VPS, these four steps prevent most of the breakage that shows up in threads here. 1. Run the agent as a service (systemd, or Docker with a restart policy), so a crash or a reboot brings it back without you. 2. Keep API keys in an env file outside the project folder, readable only by the user the agent runs as. 3. Turn on snapshots or backups before the first update. Updates are where most setups break, and a snapshot turns a bad one into a two minute rollback. 4. Pin the model id in the config, so a change of default on the provider side can't swap the model under you. What broke first on your setup?

OpenClaw has a feature called dreaming, and it is switched on from the start. Every night at 3 AM the agent reads its recent real chats, keeps the strongest notes in its long term memory and writes a short Dream Diary about it. It uses the same model your agent already runs on, so it takes a small slice of your plan each night. One switch on the Memory page turns it off for every agent at once, and what is already remembered stays. We have prepared a very nice guide for you, with a screenshot for every step: https://oneclickclaw.io/news/openclaw-dreaming-what-it-does-how-to-switch-it-off

Hey guys, I bought the paid version. And for the life of me cannot make it work. I swear I am following the instructions but totally stuck. We cannot see the templates other than Openclaw, Hermes, and Claude Code. There is no Nick's Stack. However when we launch Hermes, we cannot get terminal to work -so there is no way to actually use the Hermes template. Anyone feel charitable and want to jump on a zoom with me?

Part 7 was about turning trusted knowledge into repeatable work through SOP prompts. Once those workflows existed, I needed a simple way to find them and start the right one without remembering internal names or digging through setup notes. The final piece I added was a Skill Command Registry. It is a small, human-facing reference that gives each approved workflow a plain-English activation phrase. It can also record an optional shortcut, what the workflow does, its current status, and any reminders about verification or human review. In practice, it acts like a control panel, but there is no dashboard or complicated interface. I can intentionally start a workflow by using a phrase I am likely to remember. For example, second brain capture (SBC) starts the workflow that extracts and routes source material into my Second Brain. Capturing something does not make it trusted or approved. Human review still decides what happens next. Hermes capability builder (HCB) shows me the current top three capability candidates and starts planning for the one I choose. Choosing a candidate does not authorize the build. Building still requires separate approval. That distinction matters. A memorable command starts a workflow. It does not give the workflow new powers or remove its existing safeguards. The registry does not authorize publishing, sending, spending, destructive changes, or work outside the scope I approved. Each workflow still carries its own verification steps and human approval gates. The Skill Command Registry simply makes those workflows easier to find and use intentionally. It improves the interface between me and the system, not the correctness of the result. This closes the eight-part series. It started with making an organically grown vault easier to understand. From there, I added source mapping, capture and review, confidence labels, structural validation, and SOP prompts for recurring work. The Skill Command Registry became the final human-facing layer that ties those workflows together.

Hey @Nick Vasilescu! I’ve been using Orgo for the past few days and have a question about something I believe you mentioned in one of your videos. You said agents can communicate directly with one another. Does Orgo have a built in feature that enables this? If so, how does it work?