Projects like OpenClaw, Hermes Agent, and NanoClaw show that people want agents that actually do things, not just answer questions.
That is the part I agree with. I love smart agentic systems.
What I did not like in many agent setups was the default trust model: the same agent that can see your memory, instructions, and secrets can often also walk outside your system and take unrestricted actions.
It will be exposed to various attacks, including prompt injection, unsafe scripts, skills, and websites whose sole purpose is to attack AI agents and gain control over them. After the original OpenClaw release, the web became a much more dangerous place for AI agents.
This can lead to sensitive data exposure, identity theft, system compromise, and generally produce a lot of issues.
<ul>
<li>Octopal tries to make that simpler and safer to reason about.</li>
<li>Octo is the brain that plans and decides</li>
<li>Workers do the risky part: tools, shell, files, web, and external actions</li>
<li>Workers use Docker by default, so they do not start with full access to your machine</li>
<li>If a worker needs files from your main workspace, you share only the paths it actually needs</li>
</ul>
Why this is better in practice:
<ul>
<li>easier to trust, because the agent doing the work is not automatically sitting on top of your whole machine</li>
<li>easier to understand, because there is a clear line between thinking and acting</li>
<li>easier to control, because file access is shared deliberately instead of being wide open by default</li>
</ul>
OpenClaw and Hermes Agent both support sandboxed/containerized execution, but their documented defaults still allow host-side execution in common setups. Octopal takes the opposite approach: isolation first, host-style execution only as a fallback.
NanoClaw goes in a different direction, keeping the whole system much smaller. That is a good trade if you want the leanest possible setup. Octopal is broader on purpose: memory, worker templates, channels, MCP, skills, recurring tasks, and a private gateway/dashboard all live in one runtime.
Example workflow:
Example1:
User: “Research the latest Gemini model and write a summary.”
Octo:
<ol>
<li>Spawns Web Researcher</li>
<li>Researcher fetches sources and writes a summary</li>
<li>Researcher returns only a summary to Octo and terminates; its environment gets deleted</li>
<li>Octo stores canon entry</li>
<li>Result returned to the user</li>
</ol>
Example2:
Octo:
<ol>
<li>I want to read comments under my Moltbook post</li>
<li>Spawns Moltbook Orchestrator</li>
<li>Moltbook Orchestrator spawns Moltboot Client worker to read comments</li>
<li>Moltbook Client returns comments to Moltbook Orchestrator, the client’s instance gets deleted</li>
<li>Moltbook Orchestrator returns comments to Octo and pauses, waiting for the next instructions</li>
<li>Octo decides to reply to one comment</li>
<li>Moltbook Orchestrator spawns Moltbook Client to publish a comment reply and returns the final summary</li>
<li>All workers finish, and their environments are removed</li>
</ol>
Learn more: <a href="https://octopal.ca/" target="_blank" rel="noopener nofollow">https://octopal.ca</a>

Slava

Octopal is an AI agent framework built around an isolation-first security model. Instead of giving a single agent unrestricted access to the host machine, Octopal separates planning (Octo) from execution (Workers). Workers run in Docker containers by default and only receive the file paths they explicitly need, reducing the attack surface from prompt injection, unsafe scripts, and malicious websites. The architecture draws a clear line between thinking and acting, making the system easier to trust, understand, and control compared to alternatives like OpenClaw and Hermes Agent that default to host-side execution.

Why I Built Octopal?