The biggest one (as Karpathy notes) is having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each.
Call it “Claude native development” if you will, but “fork and customize” instead of batteries-included platforms/frameworks is going to be a big shift when it percolates through the ecosystem.
A bunch of things you need to figure out, eg how do you ship a spec for how to test and validate the thing, make it secure, etc.
How long before OSs start evolving in this way? You can imagine Auto research-like sharing and promotion upstream of good fixes/approaches, but a more heterogenous ecosystem could be more resistant to attacks if each instance had a strong immune system.
I'm not sure what is the advantage. Each user will have to waste time and tokens for the same task, instead of doing it once and and shipping to everyone.
OCI is a good choice of reuse, they aren't having the agent reimplement that. When there is an existing SDK, no sense in rebuilding that either. Code you don't use should be compiled away anyhow.
In order for it to be 'once': all hardware must have been, currently be, and always will be: interchangeable. As well as all OS's. That's simply not feasible.
The strength of open source software is collaboration. That many people have tried it, read it, submitted fixes and had those fixes reviewed and accepted.
We've all seen LLMs spit out garbage bugs on the first few tries. I've written garbage bugs on my first try too. We all benefit from the review process.
I would rather have a battle tested base to start customizing from than having to stumble through the pitfalls of a buggy or insecure AI implementation.
Also seems like this will further entrench the top 2 or 3 models. Use something else and your software stack looks different.
I’m assuming here an extrapolation of capabilities where Claude is competitive to the median OSS contributor for the off-the-shelf libraries you’d be comparing with.
As with most of the Clawd ecosystem, for now it probably is best considered an art project / prototype (or a security dumpster fire for the non-technical users adopting it).
> The strength of open source software is collaboration. That many people have tried it, read it, submitted fixes and had those fixes reviewed and accepted
I do think that there is room for much more granular micro-libraries that can be composed, rather than having to pull in a monolithic dependency for your need. Agents can probably vet a 1k microlibrary BoM in a way a human could never have the patience to.
(This is more the NPM way, leftpad etc, which is again a security issue in the current paradigm, but potentially very different ROI in the agent ecosystem.)
This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost.
What about the threat model where an agent deletes your entire inbox? Or sends your calendar events to a server after prompt injection? Bank transfers of the wrong amount to the wrong address etc. all these are allowed under the sandboxing model.
We need fine grained permissions per-task or per-tool in addition to sandboxing. For example: "this request should only ever read my gmail and never write, delete, or move emails".
Sandboxes do not solve permission escalation or exfiltration threats.
Yes 100%, this is the critical layer that no one is talking about.
And I'd go even further: we need the ability to dynamically attenuate tool scope (ocap) and trace data as it flows between tools (IFC). Be able to express something like: can't send email data to people not on the original thread.
The Security Model: Design for Distrust
I wrote about this in Don’t Trust AI Agents: when you’re building with AI agents, they should be treated as untrusted and potentially malicious. Prompt injection, model misbehavior, things nobody’s thought of yet. The right approach is architecture that assumes agents will misbehave and contains the damage when they do…I don’t trust the agent so I sandbox it before I gave it the access data to my mail and bank accounts
https://entropytown.com/articles/2026-03-12-openclaw-sandbox...
The core issue, to me, is that permissions are inherently binary — can it send an email or not — while LLMs are inherently probabilistic. Those two things are fundamentally in tension.
My posts about these aspects of agent security get zero engagement (not even a salty "vibe slop" comment, lol), so ironically security is the thing everyone's talking about, but most people don't know enough to understand what they need.
We already have: IAM, WIF, Macaroons, Service Accounts
Ask you resident SecOps and DevOps teams what your company already has available
It's also the first project I've used where Claude Code is the setup and configuration interface. It works really well, and it's fun to add new features on a whim.
Some update broke the OpenRouter integration and I haven't been able to fix the issue. I took a quick look at the code, hoping to narrow it down and it's pretty much exactly what you would expect, there's hidden configuration files everywhere and in general it's just a lot of code for what's effectively a for loop with Whatsapp integration (in my case :)).
Not to mention that their security model doesn't match my deployment (rootless and locked down Kubernetes container) so every Openclaw update seemed to introduce some "fix" for a security issue that broke something else to solve a problem I do not have in the first place :)
I've switched to https://github.com/nullclaw/nullclaw instead. Mostly because Zig seems very interesting so if I have to debug any issues with Nullclaw at least I'll be learning something new :)
If nailed this is going to be interesting.
All the other solutions I've been sumbling around are either very hard to customize or too limited.
Docker sandboxing is kinda nice, but not enough to trust an LLM even with my messaging accounts.
On Linux, however, I absolutely don't want a hypervisor on my quite underpowered single-board server. Linux namespaces are enough for what I want from them (i.e. preventing one of these agent harnesses to hijack my memory, disk, or CPU). I wonder why neither OpenClaw nor NanoClaw seem to offer a sanely configured, prebuilt, and frequently updated Docker image?
Every time I create/start a container, I have to override the container's default DNS server or access to the Internet is blocked/Domain Names will not resolve. A work around exists, and is not too bad, so I still get a lot of value of Container. There is no way I am installing Claude Code nor Node.js on my host machine, and thankfully, I am not forced to.
It does not really matter.
IMHO, until you figure out useful ways to spend tokens to do useful tasks the runtime should be a second thought.
As far as security goes, running LLM in a container in just simply not enough. What matters is not what files it can edit on your machine but what information it can access. And the access in this case as far as these agents are concerned is basically everything. If this does not scare you you should not be thinking about containers.
The more interesting security model for local AI is: don't give the model access to anything external at all. Run the model on your own hardware, feed it the specific task, get the output, verify it in an isolated sandbox. No API keys, no network access, no credentials in the environment. The model generates, a sandbox executes, verification happens outside the model's reach.
It's a much more constrained and arguably boring approach than the "agent that manages your life" vision, but it's actually secure by construction rather than by policy. The blast radius of a misbehaving model is zero when it literally cannot reach anything.
I've been thinking about how docker support would work, so I'll check this out!
In other words, Claude is the compiler.
Coding agents are not close to that yet, but it’s interesting watching history repeat itself.
This narrative of the coding agents being so much better now over the last few months seems VERY exaggerated. I’m still spending a lot of time telling Claude: No, that didn’t fix the problem. Again. Can you handle this task or do I have to give it to codex?
For me, it's my diet and workout buddy. It knows my goals, keeps me on track, does meal planning for me, gives me grocery lists, logs what I eat, when I exercise... anything I want so I don't slack off.
I've enhanced Nanoclaw quite a bit. Moved it to Apple containers (shipped with this Skill already). Then I wrote an API for Nanoclaw to use (food log, workouts, etc), then implemented long-term memory using LanceDB (because I was tired of repeating myself!).
It's better if your app's description just tells me what it does in a direct way using plain language. It's fine to tell me it's an alternative to something, but that should be in addition to rather than instead of your own description.
I install it and then what?
More seriously, set it up as you would a junior employee with a high quality getting started guide, guardrails, and clear feedback loops that it's doing tasks correctly (otherwise it will just suck). Then delegate tasks to it, start simple and grow in complexity as it demonstrates it does a good job on the simple tasks.
What role it does for you depends on your business, and what is best fit for automation. Purely digital roles with good feedback loops are the ones I focus on.
access control, provisioning, and delegation have been solved for a very long time now.
But I fundamentally agree that there is just too much overlap between what makes claws useful and what makes them insecure.
This has been my setup since early this year, not even that much code: https://github.com/hofstadter-io/hof/tree/_next/lib/agent/se...
The bigger effort is making it play nice with vscode so you can browse and edit the files and diffs.