NanoClaw turns down a $20M buyout and bets on open source AI agents

NanoClaw went from couch-coded side project to venture-backed AI infrastructure startup in less than two months. Its creator, Gavriel Cohen, says the project reached a term sheet under six weeks after the first lines of code were committed. NanoCo, the company behind NanoClaw, has now raised a $12 million seed round led by Valley Capital Partners, with participation from Docker, Vercel, Monday.com, Slow Ventures, and angels including Hugging Face CEO Clem Delangue.

Gavriel and his brother Lazer Cohen also reportedly turned down an acquisition offer worth about $20 million, including jobs to keep running the company.

That only makes sense if you believe NanoClaw is sitting in the right part of the AI agent stack. It’s an open source agent runtime arriving as developers try to make agents useful without handing them broad access to laptops, credentials, SaaS accounts, file systems, and production data.

The problem is easy to describe and hard to contain: AI agents need tools, and tools create blast radius.

Why NanoClaw caught fire

NanoClaw started as a safer alternative to OpenClaw, built for the Cohens’ previous startup, an AI marketing company that used agents to handle much of the work. The key design choice was containerization.

Instead of letting an agent run directly on a user’s machine with broad access to local services and secrets, NanoClaw runs sandboxed inside a container. That gives teams a clearer boundary around execution, dependencies, filesystem access, network behavior, and credentials.

For developers, this is practical, not philosophical. There’s a big operational difference between an agent running commands on your machine and an agent working inside a constrained environment you can inspect, reset, and isolate.

Containers don’t magically make agents safe. A container with mounted secrets, broad network permissions, and access to sensitive volumes can still do damage. But the model is easier to reason about than running an agent as a normal local process with the same privileges as the user. It also fits how engineering teams already deploy and manage software.

That’s why Docker and Vercel showing up in the seed round matters. NanoClaw’s pitch depends on developer workflow. If containerized agents become a normal pattern, companies that own build, deploy, and runtime surfaces have a reason to stay close.

The project’s public momentum came from a strange mix of technical validation and mainstream visibility. Andrej Karpathy praised it on X. Singapore’s foreign minister called NanoClaw his “second brain” in a Facebook post that went viral. Gavriel Cohen told TechCrunch that about 50 or more founders and tech executives sent DMs asking to invest.

Clem Delangue was one of them. According to the report, he messaged Cohen saying, “I like what you’re doing with NanoClaw.” Cohen replied that he liked Hugging Face’s small desktop robot, Reachy Mini, and hoped to run NanoClaw on it someday. The two started talking technically, and Delangue later agreed to invest as an angel. Cohen says someone in NanoClaw’s open source community is already working on running it on Reachy Mini.

It’s a cute anecdote, but also a useful one. AI agents are moving out of chat windows and into execution environments, developer tools, browsers, robots, and business workflows. The runtime layer is where the operational mess starts.

The security angle is the product

Open source agent frameworks have a familiar early-stage problem. They look exciting until a security engineer asks what they can access.

An agent that reads email, edits documents, opens tickets, runs shell commands, updates CRM records, or invokes internal APIs needs permissions. Those permissions need scoping, auditability, revocation, and sane defaults. Otherwise every agent becomes an overprivileged intern with API keys.

NanoClaw’s container-first approach is appealing because it borrows from infrastructure patterns developers already know:

• Ephemeral environments for risky or repeatable work
• Isolated dependencies per task or user
• Reduced host access by default
• Easier cleanup after execution
• Better compatibility with CI/CD and cloud deployment systems

The model also gives enterprises a path to standardize agent execution. Instead of every adventurous employee installing a local agent stack, a platform team can define approved images, network rules, mounted resources, and logging policies.

That seems to be where NanoCo is heading. The company has started booking enterprise customers, though it hasn’t named them. The Cohens say executives at companies including Amazon, Gap, Google, Meta, SentinelOne, and Accenture are using NanoClaw. That wording matters. It doesn’t mean those companies have formally adopted it. It means influential technical users inside large organizations are experimenting.

Still, that’s how plenty of developer infrastructure enters companies. One engineer solves their own problem, three coworkers ask for the setup, and soon the platform team has to decide whether to bless it, block it, or operationalize it.

NanoCo’s early commercial model reflects that. The company is offering implementation and support through “forward-deployed engineers,” helping businesses roll out NanoClaw-based agents internally.

That’s a very 2026 way to monetize open source AI infrastructure: sell the messy last mile. The software may be free, but safe deployment across a company rarely is.

Why turning down $20 million could work

The TechCrunch report says the Cohens first received a six-figure acquisition offer from a VC who wanted to buy the project for one of his portfolio companies. Around two weeks later, they received a much larger offer, roughly $20 million, with roles to stay and run the company. They declined.

That’s a bold call for a project that was only weeks old.

The case for saying no rests on open source compounding. A fast-growing open source project can become more valuable as users contribute code, test weird edge cases, create integrations, write deployment guides, and find use cases the founders didn’t predict. The Cohen brothers reportedly got similar advice from a founder friend: if they believed NanoClaw could become that kind of project, they needed to shut down the old venture and commit fully.

They did. Soon after, the viral posts landed, and NanoCo secured partnerships with Docker and Vercel.

There’s an obvious risk. Open source attention is volatile. GitHub stars, X praise, and executive tinkering don’t automatically become durable revenue. Many projects get a burst of interest because they map neatly to a current anxiety, then stall when users hit integration friction, governance questions, or unclear production value.

NanoClaw’s challenge is to turn “secure agent sandbox” from a clever default into a dependable platform. That means boring work: access control, logs, policy configuration, enterprise identity, secrets handling, admin dashboards, deployment templates, observability hooks, compliance posture, and support for the weird internal systems that big companies never put in blog posts.

The container boundary is a good start. It’s not the whole product.

What developers should watch

For engineers experimenting with agentic systems, NanoClaw’s rise is a sign that runtime design is becoming a first-order concern.

The early wave of agent tooling focused heavily on orchestration: planning loops, tool calling, memory, retrieval, browser control, and multi-agent coordination. Those pieces matter. Production use often breaks at less glamorous boundaries.

Can the agent access only the files it needs?

Can it call only approved endpoints?

Can you replay what happened?

Can you terminate and reset the environment cleanly?

Can you separate one user’s context from another’s?

Can security teams inspect the execution surface without reverse-engineering a pile of scripts?

Containerization gives teams a starting point for those questions. It also creates new ones.

Running agents in containers can introduce performance overhead, especially if workloads spin up frequently, pull large images, or need GPU access. Cold starts matter for interactive agents. So does network latency if the agent constantly calls external tools or model APIs. Teams also need to decide where state lives. If every agent session is ephemeral, persistence needs deliberate design. If state is mounted into the container, the isolation story gets more complicated.

Privilege creep is another problem. A sandbox often starts tight, then product requirements push teams to add filesystem mounts, host integrations, browser access, internal API credentials, and outbound network permissions. At that point, the container is still useful, but only if policies are explicit and monitored.

The strongest version of NanoClaw would treat containers as one layer in a broader security model. Developers should look for maturity around:

• Secret injection and rotation
• Network egress controls
• Per-agent and per-user permission scopes
• Audit logs that security teams can actually use
• Integration with identity providers
• Safe defaults for local and cloud deployments
• Clear guidance on what the sandbox does not protect against

If NanoCo gets those details right, it has a credible shot at becoming part of the standard agent stack. If it stays mostly a viral wrapper around containers, larger infrastructure vendors can copy the idea quickly.

Docker and Vercel are not random investors

Docker’s involvement is easy to understand. If agent workloads move into containers by default, Docker gains another high-frequency developer workflow. Agents need reproducible environments, dependency isolation, and distribution. That’s Docker’s home turf.

Vercel’s interest also tracks. AI-native apps increasingly need background execution, tool calls, browser automation, file processing, and internal workflow agents. Web app platforms want those workloads close to their deployment and developer experience layers. A safe agent runtime could become part of the modern web stack, especially for teams building internal tools or customer-facing AI features.

Monday.com’s participation points in a different direction: business workflow automation. Agents that can safely operate inside work management systems are more useful than chatbots that summarize tasks. They’re also riskier. Once an agent can edit project plans, assign work, update customer records, or trigger automations, access boundaries become a product requirement.

Slow Ventures and Delangue bring the open source and AI community angle. Hugging Face has spent years proving that open ecosystems can become serious distribution channels. NanoClaw is making a similar bet in infrastructure rather than models.

The open source company problem arrives early

NanoCo now has to satisfy two groups that often want different things.

The open source community wants transparency, fast iteration, permissive access, and trust that the project won’t become bait for an enterprise upsell. Enterprise customers want support, governance, SLAs, admin controls, and someone to blame when deployment gets messy.

Those goals can coexist, but only with careful product boundaries. If NanoCo keeps the core runtime open and sells operational support, enterprise management, hosted services, or deployment help, the model is straightforward. If too much important functionality moves behind a commercial wall, community goodwill can fade fast.

The presence of “many thousands” of users gives NanoCo room to maneuver, but it also raises expectations. Popular infrastructure projects don’t get to stay casual for long.