Latent Space caught Gavriel Cohen, founder of NanoClaw / Nanocloud, at the AI Engineer conference in Singapore for a 23-minute conversation on how to design work agents that don’t fall over the moment they hit real enterprise data. This is a rare interview where the founder skips the vision-slide fluff and just names the four decisions he made and why. Worth a full watch if you are shipping an agent-in-Slack this quarter.
The Karpathy origin story alone is worth the click — but the substance sits in the middle, where Cohen enumerates the design choices.
Origin: a public wiki, a retweet, a working prototype
The setup is that Andrej Karpathy publicly wished for a personal “LLM wiki” — a private, ambient assistant that would ingest his notes and produce ready-to-act summaries. Cohen built a minimal working version over a weekend, posted it, Karpathy retweeted it, and Nanocloud existed.
The lesson Cohen draws is not “reply to Karpathy.” It is that the shape of what people actually want from a work agent is much smaller than the frameworks assume: give me an inbox, let me talk to it in Slack, and let it keep a well-organized set of markdown files on my behalf.
Design decision #1 — fine-tune the output, not the model
The interview’s most quotable line is Cohen’s blunt correction to the common mistake: teams reach for LoRA or full fine-tuning when what they actually need is to constrain the output shape. NanoClaw’s agents use frontier models as-is but tightly specify the format, tone, and structure of what comes back.
“The mistake people make is that they try to fine-tune the model. But you should fine-tune the output — get it to give you ready-made output.”
Practical implication: prompt-level output contracts, plus an evaluator that rejects free-form drift. No custom weights.
Design decision #2 — minimal SDK, fewer dependencies
Cohen built NanoClaw on a small agent SDK rather than adopting a full framework. The reasoning is operational: fewer moving parts means fewer places for the agent to accidentally leak, fewer version-pin fights, and fewer surprise behaviors when a dependency ships a new “smart” default. He specifically calls out that most framework abstractions “decide what gets pushed into the context” for you, which is exactly the decision he wants to own.
Design decision #3 — sanitize inputs, distrust the tool surface
The third architectural point is the one seasoned prod engineers will nod at: treat every incoming document, ticket, email, or message as unsanitized input. For most useful agents, that means a filter stage before the LLM ever sees the content, plus explicit tool-call allowlists rather than “give the agent access to the whole workspace.”
The Slack integration in particular is scoped by default to read-only for messages, with write capability gated by explicit user opt-in per channel.
Design decision #4 — files first, database maybe later
The agent’s persistent memory is a directory of markdown files, Obsidian-vault-shaped. The prompt to the underlying model is roughly “Create markdown files. See what files you already have. Then go and save it.”
Cohen admits the first version happily created duplicate files until he added the “look first” instruction. The point of the anecdote is not that markdown-as-memory is optimal — it’s that a plain filesystem is inspectable, portable, gives users an escape hatch (they own the vault), and defers the vector-DB question until a real retrieval problem exists.
The Slack-first UX bet
Nanocloud’s most contrarian product bet is that enterprise buyers do not want another dashboard. Their agents are addressable, respond, and file work directly inside Slack. Cohen argues this is what makes the “read your inbox and tell me the top three things to focus on this week” question actually usable: the user doesn’t context-switch, and the agent’s outputs land where the team already coordinates.
The downside — Slack rate limits, threading UX, and message-length caps — he treats as constraints to design into, not around.
Enterprise adoption note
Toward the end of the interview, Cohen describes the go-to-market pattern that surprised him: he expected startups, got governments. Ministries and enterprises with strict data-sovereignty rules found a small, output-constrained, filesystem-based agent easier to deploy than a heavier framework. The privacy story (“your files stay in your vault, your model calls stay in your VPC”) is what he now leads with.
Key takeaways
- Fine-tune the output, not the model — output contracts + evaluators beat LoRA for most work-agent use cases.
- Minimal SDK, few deps — own the context-assembly decision rather than inheriting a framework’s defaults.
- Treat all incoming content as unsanitized input — filter before the LLM sees it; gate write tools per channel.
- Markdown files as memory — inspectable, portable, no premature vector-DB. Add retrieval only when a real problem appears.
- Slack-first UX beats a new dashboard — for work agents, the win is not asking the user to context-switch.
- Ready-made output is the product — “top 3 things to focus on this week” beats “here is a chat window.”
- Privacy and portability sell to enterprise/government — a minimal, self-hostable agent is easier to procure than a heavy platform.
Source
- Title: The Blueprint for Autonomous Work Agents
- Guest: Gavriel Cohen (Founder, Nanocloud / NanoClaw)
- Host: Latent Space
- Recorded at: AI Engineer Singapore
- Duration: 23:14
- URL: https://www.youtube.com/watch?v=hLUGXO5DSpo