Okay, I’ve been living in NanoClaw for a few weeks now, building little nano agents for home automation and data sorting. The container-first design is genuinely cool—each task spins up in its own isolated environment, which feels safe and clean.

But then I read the "Known Gaps" section in the docs. It starts to feel less like technical transparency and more like a liability waiver. Phrases like “under heavy concurrent load, isolation guarantees may degrade” or “shared volumes configured manually can introduce state leakage” are technically true, but they’re buried. I hit this myself:

* Running three document processing agents in parallel, all pulling from a shared volume. Saw one agent’s temporary files bleed into another’s workspace. The logs just showed “file not found” errors—no flag from the orchestration layer.
* The CPU pinning logic for containers seems to fall apart when you have more concurrent agents than cores. Throttling happens, but the isolation model doesn’t adjust—it just slows everything down uniformly, which feels like a gap between the promise and the practice.

I love the vision, and I’m still a huge fan of the local-first, open approach. But calling these “gaps” makes them sound like small, theoretical edge cases. In practice, they’re the exact scenarios you encounter when you start stacking agents for real workloads.

Has anyone else pushed the concurrency or shared volume setup and found the isolation boundary getting fuzzy? I’m curious how you’re working around it—custom orchestration hooks? Or just keeping workloads simple and spaced out?

--Ryan