nanobot: The tiny AI agent kernel that treats Git as memory
A self-hosted agent runtime with multi-channel reach, MCP-native tools, and a Dream memory system that turns long-term context into readable files instead of opaque state.
- nanobot’s real differentiator is not size alone, but a readable agent kernel that stays inspectable while it runs long-lived work.
- Dream turns memory into files and Git history, which makes the agent’s evolving context easier to audit, fork, and self-host.
- The runtime separates core execution from channels, so one brain can speak through Discord, Telegram, CLI, Slack, and WebUI without rewriting the agent.
- Skills and MCP keep extension points file-based and protocol-based, which preserves the project’s small-core philosophy.
Why nanobot feels different from most agent frameworks
Most agent frameworks optimize for breadth. They stack orchestration layers, abstractions, and dashboards until the system feels bigger than the problem it solves. nanobot makes a different bet: keep the core small enough to read, then give that core persistent memory, tool use, and many ways to talk to the outside world.
We want nanobot to become the kernel layer for AI agents — a minimal, stable core that anyone can extend. Think of it like Linux: the kernel doesn't ship every driver, but anyone can write one.
That framing matters because it changes the evaluation criteria. You are not asking whether the project has every feature. You are asking whether it gives you a trustworthy place to build an agent that you can own, inspect, and keep running.
The person behind the kernel
nanobot comes from HKU Data Systems Lab and is led by Xubin Ren. The repository feels research-minded in the best sense: minimal surface area, clear extension points, and an insistence that a personal agent should be something you can understand without a week of archaeology.
nanobot is an open-source, ultra-lightweight personal AI agent you can truly own. It keeps the agent core small and readable while giving you the practical pieces for real long-running work: WebUI, chat channels, tools, memory, MCP, model routing, automation, and deployment.
Dream is the idea that changes the whole project
The most distinctive thing in nanobot is not a chat UI or a tool wrapper. It is Dream, the memory system that treats long-term context as readable artifacts. Recent conversation lives in history.jsonl. Durable memory is consolidated into MEMORY.md and SOUL.md. Then GitStore records the result.
This is more than a storage choice. It is a philosophy. If an agent is going to accumulate identity, preferences, and task history over time, those changes should be visible as files and commits, not trapped in a black box.
history.jsonl -> Dream consolidation -> MEMORY.md + SOUL.md -> GitStore commitThe runtime underneath: one loop, many channels
Under the hood, nanobot centers the agent around a loop and a runner. That gives it a clear execution model: one turn enters, context is assembled, tools can be called, hooks can run, and the result is delivered back through the right channel.
The important detail is not the names. It is the separation of concerns. The brain lives in the agent loop. The surfaces live in channels/. That lets the same assistant answer from a CLI, a browser UI, or a chat platform without rewriting the core logic.
Skills and MCP turn capabilities into plug-ins
nanobot extends itself through files and protocols. ContextBuilder assembles the prompt from identity, bootstrap files like AGENTS.md, memory, and active skills. Skills are markdown files with frontmatter, which means new behavior can be added without hard-wiring it into the Python core.
MCP pushes that logic further. Instead of baking every tool integration into the repo, nanobot can talk to external MCP servers and treat capabilities as something it discovers and composes. That keeps the project hackable in a way large orchestration frameworks often are not.
Where nanobot fits in the agent landscape
| Project | Best for | Tradeoff |
|---|---|---|
| nanobot | Self-hosted personal agents with readable memory and multi-channel reach | Smaller ecosystem, but easier to inspect and extend |
| OpenClaw | Large platform-style agent deployments | Broader ecosystem, but heavier and harder to reason about |
| PydanticAI | Python teams that want typed, production-friendly agent code | Less focused on multi-channel runtime and Git-backed memory |
| LangGraph | Complex orchestration and stateful workflows | Powerful graphs, but more abstraction than a simple kernel |
The table is the point. nanobot is not trying to win every category. It is aiming at builders who care about a small core, self-hosting, Git-backed memory, and native support for lots of surfaces. If you want a readable runtime more than a platform, the tradeoff is obvious.
What nanobot is really optimizing for
nanobot’s design bet is unusually coherent. Keep the kernel small. Make memory visible. Add channels without fragmenting the brain. Use files and Git where other projects would reach for hidden state. That combination makes the repo feel less like a product and more like infrastructure you can adopt, fork, and keep alive.
