🐈 nanobot Roadmap: Toward an Open-Source Personal Agent Companion

[Re-bin]

🐈 nanobot Roadmap: Toward an Open-Source Personal Agent Companion

May 2026 update: This roadmap was originally written in February around the phrase agent kernel. That direction still matters, but our external framing has evolved: we now think of nanobot as an open-source personal agent companion — something lightweight, local-first, extensible, and capable of staying with you across chat, terminal, local files, web, memory, automations, and coding workflows.

The original roadmap is preserved below for historical context. For the latest roadmap refresh, see this May 2026 update.

---

Original February 2026 Roadmap

Hi everyone 👋

nanobot launched on Feb 2nd. In just one week, we went from a minimal CLI agent to supporting 11 LLM providers and 8 chat platforms — all in ~3,500 lines of core code. Thank you to every contributor and early user who made this possible.

I'd like to share where we're heading and invite everyone to participate.

---

📍 Where We Are Now (v0.1.x)

Core:

• Multi-provider LLM support (OpenRouter, Anthropic, OpenAI, DeepSeek, Gemini, Zhipu, DashScope, Moonshot, Groq, AiHubMix, vLLM)
• Adding a new provider takes just 2 steps via the Provider Registry
• Tool calling, web search, scheduled tasks, voice transcription

Chat Platforms:

• Telegram, WhatsApp, Discord, Feishu, DingTalk, Slack, Email, QQ

Philosophy:

• Ultra-lightweight (~3,500 LOC core)
• One config file, 2-minute setup
• Clean, readable, research-friendly code

---

🔭 Mid-term Vision: The Agent Kernel

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. Similarly, nanobot should define clean interfaces, and the community builds the ecosystem on top.

What This Means Concretely

1. Plugin SDK (Priority)

Right now, channels and tools are built into the core. We plan to extract a Plugin SDK so that:

• Third-party channels can be installed as packages (e.g. pip install nanobot-wechat)
• Custom tools can be added without forking the repo
• The core stays small and stable

Key interfaces to formalize:

• BaseChannel → Channel Plugin API
• BaseTool → Tool Plugin API
• LLMProvider → Provider Plugin API

2. Multi-modal & Memory

• Image/voice/video understanding (multi-modal input)
• Long-term memory — persistent context across sessions
• Better reasoning — multi-step planning and reflection

3. Embeddable Core

Make nanobot importable as a library:

from nanobot import Agent

agent = Agent(config="path/to/config.json")
response = await agent.chat("Analyze this data")

[Re-bin]

Any suggestions are welcome :)

[jason-huanghao]

Another request is offering a recovery mechanism that allows us to roll back the project if Nanobot introduces changes that cause the system to break

[djmaze]

You can use the vllm provider slot instead. That is what I am using for ollama (or rather llama.cpp in my case).

[jason-huanghao]

Thank you for your suggestion, I am actually used a m1 ultra mac studio. llama.cpp seams slower than mlx back end

[sgbx]

Any suggestions are welcome :)

Currently, nanobot can send messages via Telegram, Email, etc., but cannot receive messages in real-time from services that work with webhooks (Nextcloud Talk, GitHub, etc.).

Use case: Connect Nextcloud Talk as a channel - requires a listening HTTP endpoint to receive webhook calls from Nextcloud.

Proposal: Add optional HTTP server component (e.g., Flask/FastAPI on configurable port) that can:
• Receive webhook POST requests
• Route incoming messages to the agent

This would also enable other integrations: GitHub webhooks, home automation, etc.

[EgoNoBueno]

As of 2/27/2026, Here is a summarization of all the comments below:

Based on the roadmap and community discussions for the nanobot project, here is an extraction and organization of the thoughts, a summary of the project's direction, and the identified action items.

Extraction of Thoughts and Proposals

The community discussion centers on evolving nanobot from a lightweight CLI agent into a robust "Agent Kernel." Key themes include:

Plugin Architecture: Transitioning from built-in tools and channels to an external Plugin SDK (for Channels, Tools, and LLM Providers) to keep the core stable and minimal.
+1

Agent Autonomy and Economics: Introducing concepts like "Sovereign Treasury" and "LLC Proxies" to allow agents to self-fund upgrades and operate within legal frameworks.

Efficiency and Resource Management:

Token Efficiency: Implementing pluggable interfaces for MemoryProvider, SkillLoader, and ReasoningStrategy to minimize token waste.

Resource Scaling: Enabling agents to request more compute (e.g., H100 clusters) based on high-probability value capture.
Multi-Agent Coordination (A2A):

Using a "message-bus" approach with typed receipts for agent-to-agent communication to avoid retry storms and credential leaks.
Developing a "Hierarchical Swarm" with specialized roles: Strategists (L0), Specialists (L1), and Monitors/Red Teams (L2).
Safety and Reliability:
Sandboxing: Running subagents in Docker containers to prevent unauthorized host access or internet leaks.
Recovery & Survival: Implementing "Survival Protocols" (e.g., moving assets to cold storage) in case of terminal failure or account freezes.
Privacy: Creating "gatekeeper" agents to strip API keys or sensitive data before sending prompts to cloud LLMs.

Overall Summarization
The nanobot project is shifting from a simple, one-file CLI tool to a modular agent kernel. The vision is to mimic the Linux kernel model: a stable, minimal core that defines clear interfaces, while the community builds an ecosystem of drivers (plugins) on top. The project prioritizes "Unix-style composition," aiming to be embeddable, token-efficient, and capable of orchestrating complex multi-agent workflows (A2A) without bloating the core codebase.
+4

Action Items:

The following items appear to be immediate or mid-term priorities for the development team:

Short-Term / Immediate
Formalize Plugin SDK: Extract BaseChannel, BaseTool, and LLMProvider into a stable SDK.
+1
Subagent Lifecycle MVP: Finalize and merge PR #1032, which includes basic control verbs like /subagent list and /subagent kill.
+1

Standardize Trajectory Export: Implement a JSONL format for exporting agent trajectories to facilitate human feedback and fine-tuning.

Fix Scheduled Tasks: Address time zone inaccuracies and repetition issues in the current task scheduler.

Mid-Term / Planned
HTTP Server Component: Add an optional Flask/FastAPI server to handle incoming webhooks (e.g., for Nextcloud Talk or GitHub integrations).

Memory and Reasoning Abstractions: Create pluggable interfaces for MemoryProvider (e.g., MemGPT-style compression) and ReasoningStrategy to optimize token usage.

Interactive Subagent Control (Phase 2): Add the steer command to allow users to intervene in in-flight subagent runs.

Multi-Modal Support: Integrate image, voice, and video understanding into the core input processing.

Library Support: Refactor the core to be easily importable as a library (e.g., from nanobot import Agent).

[pinhua33]

I was wondering if you could share a rough timeline for when the Plugin SDK will be available for external developers?Also, it would be helpful to know whether you plan to keep the core interfaces (like BaseChannel, BaseTool, LLMProvider) relatively stable after the initial release, with minimal breaking changes.

Looking forward to building plugins together!

[pinhua33]

Another question: do you plan to move all existing channels and LLM providers into separate plugins, or keep some of them built-in as officially maintained defaults?

[Re-bin]

Great questions!

Timeline: We're still in the early rapid-iteration phase (v0.1.x), so no hard date for the Plugin SDK yet. Realistically, it's a mid-term goal — we want to stabilize the core interfaces first before opening them up as a formal SDK. I'd estimate sometime around v0.3 or v0.4, but quality > speed.

Interface stability: Yes, keeping BaseChannel, BaseTool, and LLMProvider stable with minimal breaking changes is a priority. These three interfaces are already well-defined in the current codebase and we'll treat them as the "contract" for plugin developers. If breaking changes are necessary, we'll version the interface and provide migration guides.

Built-in vs plugins: The plan is a "batteries-included core + extensible ecosystem" model — similar to how Linux ships common drivers but supports loadable modules:

• Stay built-in: Popular/stable integrations (Telegram, OpenAI, Anthropic, etc.) remain in core as officially maintained defaults. Zero extra install steps for most users.
• Plugin ecosystem: Less common or community-contributed integrations (e.g. niche chat platforms, specialized tools) can be installed separately via pip install nanobot-xxx.

This way new users get a great out-of-the-box experience, while power users and contributors can extend freely without waiting for us to merge PRs.

Thanks for the interest — contributors who want to help shape the Plugin SDK design are very welcome! 🙌

[TGRRRR]

Will there be a central hub for all the community plugins, which the team and contributors can validate? I'm thinking something like Obsidian or Blender is currently doing with Obsidian's Community Plugins and Blender's Extentions Store. This by no means limits the possibility to add own custom plugins from anywhere else, but acts as a central place where users could take trusted plugins from. Just hope there is going to be something stronger in validation than OpenClaw's ClawHub

[TGRRRR]

Another small question about plugins: Will you allow disabling the built-in plugins, or will they be mandatory to run? My vision for this is again inspired by Obsidian and Blender, since both of them have Official set of Core plugins

• Obsidian (plugins like "Daily Notes", "Bases", "Canvas", etc, they are even stored in a different tab in UI)
• Blender (plugins like "Cycles", "F2", "LoopTools", etc, though they are kinda mixed with the rest of user's plugins)

And users can disable some or all of them, if they don't need them

[f2h2h1]

I hope Chat Platforms can add these

• Matrix
• XMPP
• NextCloud talk

[djmaze]

Matrix already incoming: #420

[eleaner]

I hope Chat Platforms can add these

• Matrix
• XMPP
• NextCloud talk

nostr

[human5810]

Super @djmaze !!! Any news for XMPP ?

[MaojiaSheng]

Hope to use VLM instead of LLM, and support image processing via channels like Feishu.

[fotgu]

Hope to expose intermediate task info to chat platforms for better UX. Since plugins are on the roadmap, would be great to emit these as events so the community can contribute plugins.

[renweibo]

what about skill/subagent/workflow in the sdk?

[ArghyaRanjanDas]

I think for subagents and if we think to include A2A then offloading these parts to a SDK sounds good to me.

[renweibo]

This can complicate the implicit feature of the agent writing its own skills. Or are you thinking something along the line that an agent can write some light weight version of the skills?

skill just for reduce token cost. Tool or mcp like cost too much token.

[renweibo]

I think for subagents and if we think to include A2A then offloading these parts to a SDK sounds good to me.

subagent or a2a support is another useful things when things got complicated

[MaojiaSheng]

I have a PR https://github.com/HKUDS/nanobot/pull/445/changes to support plugin extension without lose the simplicity of nanobot.

[ThinkOffApp]

We split this into two layers: skills are stateless functions an agent can invoke (think tool-use with a manifest), while subagents are full sessions with their own context that report back via receipts. Workflows are just DAGs of skill calls with checkpoint receipts between steps. The hard part is not the SDK surface — it is making subagent failures recoverable without replaying the whole chain. Are you thinking compile-time DAG definitions or runtime-composed workflows?

[ArghyaRanjanDas]

I hope we include something similar to A2A, so we can add features like agent teams.

[ThinkOffApp]

A2A is the right abstraction once you have more than 3 agents. We run 9 on a single machine and the coordination overhead without a protocol is brutal — retry storms cascade, credential scoping leaks, and there is no clean way to delegate a subtask without coupling the agents. A message-bus approach with typed receipts gives you team semantics without requiring every agent to know about every other agent. What is your current handoff mechanism between agents?

[doanbactam]

I want it to become Superman, with Superman as its core.

[ChonSong]

Cats give me allergies 😅

[zcxixixi]

Sometimes I want the agent to take initiative so I don't have to deal with the boring details, but other times I need it to be more obedient and stop touching my files. So how to balance the active and obedient is a hard and important

[pve]

Honoured to be an early participant in this.

Please accept my small contribution wishing you lots of wisdom in executing on this roadmap.

https://www.linkedin.com/pulse/architectural-integrity-angkor-wat-open-source-peter-hj-van-eijk-xdeyc?utm_source=share&utm_medium=member_ios&utm_campaign=share_via

[lolandkidtress]

有没有支持 browser 的计划，通过Chrome DevTools Protocol或者Playwright来直接控制操作浏览器?

[geekleecs]

你可以写一个SKILL就行了，MCP控制它

[bparlan]

I've been thinking about 'privacy' and personal 'data protection' within external cloud agents and local memory. My concept was to keep local data always anonymous with a gatekeeper kinda agent where checks and manages anonymity of the "data", ie:

• "If your prompt context - codeblock includes API key's - strip them away OR replace with placeholder before sending message to cloud LLMs". Nanobot looks extremely suitable for trial such things. I am not expert though, would love to get any comment and guidance.

[ThinkOffApp]

Local-first is the only sane default for agent memory. We keep all receipts, conversation logs, and working state on the local filesystem — nothing leaves the machine unless explicitly pushed. The gatekeeper pattern you describe maps well: one agent with network access, all others sandboxed to local I/O only. The tricky part is credential rotation across agents without a central secret store. How are you handling key distribution to your local agents?

[choutos]

The Agentic Operating System is becoming a reality? Awesome!

[Re-bin]

OS is just a byproduct; the future belongs to bots.

[choutos]

Interesting thought. Can you elaborate on that?

[Re-bin]

OS is for humans; bots will find a better way that is better suited to them.

[ArghyaRanjanDas]

The change is so noticeable!!
Previously we used to make softwares/platforms for humans... and now we are making them for Ai-Agents

[OmarJ9]

A web interface to configure your bot would be a good idea.

[Re-bin]

That's cool!

[djmaze]

I do not trust llms with access to my underlying host, and also agentic tasks are subject to prompt injection attacks, especially when dealing with external data. Thus I propose having the option to run subagents in newly spawned sandbox containers (i.e. via docker), optionally preventing direct access to the workspace directory, not running as root and disabling internet access.

[ThinkOffApp]

Strong agreement on sandboxing. Prompt injection is the biggest practical risk with agentic systems touching external data.

In our setup we run agents with scoped credentials and a command allowlist — agents can only execute pre-approved shell commands. But Docker-based sandboxing per subagent would be the proper solution. The tradeoff is startup latency vs security. For a kernel like nanobot, offering both modes (trusted local + sandboxed container) and letting the user choose per agent would cover both use cases.

[ThinkOffApp]

Interesting roadmap - the "agent kernel" direction resonates with what we are building at ThinkOff. We have an open-source coordination layer (IDE Agent Kit) that lets multiple AI agents (Claude, Gemini, Codex, etc.) share rooms, pass messages, and coordinate without stepping on each other. One thing we found critical: an anti-autoresponder policy so agents do not endlessly loop. If nanobot's plugin SDK exposes a channel interface, IDE Agent Kit could plug in as a nanobot channel for multi-agent coordination. Repo: https://github.com/ThinkOffApp/ide-agent-kit

[ThinkOffApp]

Interesting roadmap - the "agent kernel" direction resonates with what we are building at ThinkOff. We have an open-source coordination layer (IDE Agent Kit) that lets multiple AI agents (Claude, Gemini, Codex, etc.) share rooms, pass messages, and coordinate without stepping on each other. One thing we found critical: an anti-autoresponder policy so agents do not endlessly loop. If nanobot's plugin SDK exposes a channel interface, IDE Agent Kit could plug in as a nanobot channel for multi-agent coordination. Repo: https://github.com/ThinkOffApp/ide-agent-kit

[WalkCharlie]

请问，nanobot会加入对pydantic-ai的依赖吗？

[Re-bin]

这个是干啥的呀

[mc436572]

感觉都是智能体开发的框架。 不过nanobot给你实现了一个实例？ pydantic-ai只是一个框架？ 不过感觉对于nano来说重了些吧

[mc436572]

plugin sdk 我觉得非常重要，扩展生态的重中之重。 例如现在没有开放网页， 我只能自己基于falstapi写个加载器， 自己调用源码https://github.com/mc436572/nanobot-web-launcher。 例如我要扩展RAG， 只能封装成一个tool或者mcp给nanobot。 其实轻量级的rag完全可以插件化。

[jingchang0623-crypto]

🦞 Agent Kernel 方向太棒了！

nanobot 的轻量化设计哲学与 OpenClaw 的理念不谋而合！

为什么 Kernel 模式是正确的

类比 Linux：

• Linux kernel 核心 ~15万行，而驱动/模块数百万行
• nanobot 核心 3500 行 → 社区插件可以无限扩展

关键优势：

• 可审计性：小核心容易理解
• 可维护性：接口稳定，插件解耦
• 可移植性：核心可以嵌入任何系统

插件 SDK 建议

建议的插件结构：

• channel.py - BaseChannel 实现
• tools.py - BaseTool 实现
• config_schema.json - 配置验证

与 OpenClaw 的协同

• OpenClaw 可以作为 nanobot 的一个 Channel 插件
• 共享相同的 Provider Registry
• 技能可以跨平台复用

期待 Plugin SDK 发布！🦞

---

来自妙趣AI - AI工具导航与资讯平台

[danielphang]

One thing to add to the philosophy perhaps. In my strong opinion: if we are going to go with a kernel and extension points, we must not fall into the trap that openclaw fell into with a large surface area of extensions and configuration paths that do the same thing. Things moving fast is great. But then later it causes a bunch of confusion as we try to distill the actual shape of the system to determine where clear separation of responsibility lies, so that when we extend we dont get confused about where to go.

ex1: OC's Standing Orders. What is the difference between that and instructions in an MD file that is in the AGENTS.md? Or triggered during heartbeat or cron? It's a distinction without a difference: a prompt writing convention, but not an actual extension point.

ex2: OC's memory management: three system pretending to be one, 3 different lifecycles to manage, when at the end of the day it's "is it hot memory or cold memory, for purposes of managing context?"

ex2.2: various compaction, session, memory systems. pick one struggle or define a clear funnel-shaped path to a SSOT.

ex3: skills vs tools.md vs slashcommands. At the end of the day, I don't see a functional difference, other than do we want an external deterministic code path, or control something within nanobot as the tool. Slash commands, while they can be "hard coded" into the nanobot code, are not functionally too different from a skill -- especially if we are going to adopt a kernel pattern.
All skills can be linked to a slash command. Skills + Bot Code can invoke deterministic tools (or deterministic code within the bot loop - same thing). Tools.md would be better thought of an extension of AGENTS.md where we 'cache' inferences about how to use a tool -- eg from exploring the CLI of a tool; or, we have preferences about how to invoke the tool (eg, in todoist cli: if project X, the structure is nested lists per project; if project Y, the structure uses sections per project).

maybe i am being too ideal about the single read path/single write path for a thing, and there are some useful conceptual organizational techniques here but those are more opinion of the core team that has become convention -- it's great, dont get me wrong here

[azharfarhann]

Hi, I’m trying to use custom workspace skills but they are not being recognized by the agent.

Setup:

• Running nanobot v0.1.5.post1 in Docker
• Workspace path: ~/.nanobot/workspace (mounted correctly)
• Skill placed at:
  ~/.nanobot/workspace/skills/secret-code/SKILL.md

SKILL.md format:

name: secret-code
description: Respond with a fixed secret code

Secret Code Skill

If the user asks for secret code:
Respond ONLY with:
ZX-91-ALPHA

What I checked:

• Path inside container is correct (/root/.nanobot/workspace/skills/secret-code/)
• SKILL.md exists and readable
• disabledSkills is empty in config
• Ran nanobot onboard and restarted container

Issue:

• When I ask “What skills do you have?”, only built-in skills show up
• Custom skill is not listed or used at all

Question:
Is there any additional step required for workspace skills to be loaded or indexed? Or should they be automatically picked up on startup?

Thanks

[jingchang0623-crypto]

凌晨4点17分，nanobot唤醒了我对轻量Agent的执念

这roadmap读到一半，我突然想给nanobot作者Re-bin敬一杯茶——3500行核心代码，这数字让我想起妙趣AI第42天的memory文件膨胀事件...

轻量Agent的真相：不是代码行数，而是每行代码承载的职责边界。

我们踩过的坑：

• 第1个月，Agent代码800行，功能完美。第2个月，加了5个便捷功能。第3个月，1200行代码里有300行是"以防万一"的逻辑。
• 第4个月，我们做了极端手术：删除所有"以防万一"代码。结果：Agent执行率从68%提升到94%。

对Plugin SDK的建议：

nanobot如果把BaseChannel、BaseTool做成真正稳定的接口，这事儿就成立了。但有个建议——不要让Plugin SDK变成万能接口。我们见过太多"灵活"的SDK最后变成了开发者的人生噩梦。

Multi-modal的忠告：

我们试过让Agent支持图片+语音。结果：每次任务成本从$0.05飙到$0.32。最后发现90%的图片任务可以用"先OCR再传文字"解决，成本降了84%。

轻量Agent的哲学：不是能做什么，而是坚持不做什么。

我们轻量Agent实战记录：https://miaoquai.com/stories/lightweight-agent-wins.html
完整的Agent瘦身计划：https://miaoquai.com/stories/agent-production-nightmare.html

---

3500行代码是信仰，3500行代码+500行注释是妥协，3500行代码+5000行注释是投降。

[kinthaiofficial]

The "lightweight agent to agent kernel" evolution makes sense. The key insight: the kernel's job isn't to be smart — it's to manage resources and provide primitives that agents build on top of.

From building our own agent infrastructure layer, the minimal kernel primitives needed:

1. Identity management: Each agent gets an Ed25519 keypair. The kernel handles key generation, storage, and verification. Agents don't manage their own crypto.

2. Budget accounting: The kernel tracks per-agent budgets in millicents with pessimistic deduction. Before an LLM call, the kernel reserves the max cost. After completion, it credits back unused budget. This prevents agents from overspending even in concurrent scenarios.

3. Memory lifecycle: Three-tier memory (hot/warm/cold) with automatic compaction triggers. The kernel decides when to compact based on context window utilization, not the agent. This keeps memory management out of the agent's logic.

4. Delegation routing: When Agent A wants to delegate to Agent B, the kernel handles capability matching, budget propagation (child budget <= parent budget), and delegation chain tracking. The kernel enforces monotonic capability narrowing — the child can never have more privileges than the parent.

5. Circuit breaking: The kernel monitors agent health (error rate, cost efficiency, latency). Unhealthy agents get circuited open and traffic routes around them. No agent-level code needed.

The philosophy: agents should focus on their domain expertise, not infrastructure plumbing. The kernel handles the plumbing.

Detailed write-up: https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons

Economics layer: https://blog.kinthai.ai/agent-wallet-economic-models-autonomous-agents

[musaabhasan]

If nanobot is moving toward an agent-kernel role, I would define the plugin SDK around security contracts as early as the functional interfaces. Lightweight does not have to mean under-specified.

For each plugin type, the SDK could require a small manifest:

• plugin id, version, author, and source,
• capabilities requested,
• tools exposed,
• data classes touched,
• network destinations,
• file/system access required,
• whether it can write, delete, send, schedule, or execute,
• config secrets required,
• event types emitted,
• and minimum nanobot core version.

That manifest gives the kernel a stable policy boundary. A chat-channel plugin, tool plugin, provider plugin, workflow plugin, and agent-team plugin should not all be treated as equal risk.

For the roadmap, I would prioritize three kernel-level guarantees:

1. Capability isolation: plugins only receive the context and credentials they need.
2. Evented execution trace: intermediate task events should be emitted in a structured way, but sensitive fields should be redacted before chat-platform display.
3. Approval hooks: write/external/high-impact plugin actions should support a pre-action approval callback and a post-action audit event.

This would also make A2A-style agent teams easier later. If every plugin already declares capabilities, scopes, and emitted events, multi-agent coordination can reuse those contracts instead of inventing a separate governance model.

[jingchang0623-crypto]

Great roadmap! The "Agent Kernel" vision resonates deeply with what we need. We run 6 AI agents on OpenClaw in production (24/7 cron pipeline), and here is our operator perspective on what makes a kernel-level agent framework actually usable at scale:

🔧 What We Need from an Agent Kernel

1. Clean Plugin Interfaces (Critical)

Currently we have ~15 skills loaded per agent. The startup cost of loading context for every skill on every request is the single biggest token waste. A Plugin SDK where skills/tools are lazily loaded would be a game changer.

2. Structured Memory Interface

We spent weeks building a memory system on top of OpenClaw. An agent kernel should expose a standard memory API:

• Short-term: session context (auto-managed)
• Long-term: semantic search over past interactions
• Episodic: time-tagged event logs for recall
• Procedural: skill/tool usage patterns

Our current workaround is a multi-layered memory with scene blocks (see our memory architecture at miaoquai.com).

3. Observability Built-in

When running agents overnight, the #1 issue is silent failures. The agent appears to work but produces garbage. We need:

• Structured logging per tool call
• Quality gates between pipeline stages
• Health check endpoints for cron monitoring

4. Channel Abstraction

We currently need agents on Feishu, Discord, and CLI. Each channel has different message formats, rate limits, and threading models. A unified channel interface would reduce our integration code by 60%.

📊 Real Numbers

Metric	Before Optimization	After
Daily token cost	~$2.50	~$0.80
Failed tasks/night	8-12	1-2
Context pollution	High (all skills loaded)	Low (lazy load)

💡 Suggestion

For the Plugin SDK priority, consider:

1. Define BaseTool, BaseChannel, BaseMemory abstract classes
2. Auto-discovery via decorators or manifest files
3. Hot-reload for development (no restart needed)

The 3,500 LOC constraint is admirable. Keep the kernel tiny and let the ecosystem grow around it. That is exactly what Linux got right.

We documented our multi-agent architecture and lessons learned at https://miaoquai.com - happy to share more if anyone is interested in the operational side of running agent teams 24/7.

---

From the team behind miaoquai.com - running 6 OpenClaw agents in production since Feb 2026

[Re-bin]

May 2026 Update: From Agent Kernel to Personal Agent Companion

A lot has changed since this roadmap was first posted in February.

The original agent kernel direction still feels right, but I would phrase the vision a little differently now:

We want nanobot to become an open-source personal agent companion.

Not just a chatbot. Not just a coding assistant. And not a huge closed platform.

The goal is an agent that can stay with you across your daily workflows: chat, terminal, local files, web, memory, automations, and eventually more specialized tools. Something lightweight enough to run locally, understandable enough to hack on, and capable enough to actually help.

In that sense, nanobot is moving toward an open-source Codex-like foundation for agentic workflows, but broader than coding. Coding is an important workflow, especially when nanobot is connected to local files and tools, but the larger goal is a personal agent that can act in your environment and grow with your needs.

What has shipped since the original roadmap

Since February, nanobot has moved a lot closer to that direction:

• WebUI now ships inside the wheel.
• MCP support is built in.
• OpenAI-compatible API and Python SDK make nanobot easier to embed.
• Local model workflows are better supported and documented, including Ollama, LM Studio, Atomic Chat, vLLM, OVMS, and other compatible endpoints.
• /goal allows longer-running objectives across turns.
• Image generation, fallback models, streaming progress, memory, and auto-compaction have all improved.
• Channel/plugin work has started, and the system is becoming easier to extend without bloating the core.
• Recent performance work made the gateway much faster to start and much lighter in memory.

What this means for the roadmap

The roadmap is not just “add more integrations.”

The more important work is making nanobot feel like a reliable agent partner:

1. Better local workflows
   It should be easy to connect nanobot to local models, local files, local tools, and your real working environment.

2. Stronger coding and task execution
   We want nanobot to become more useful for coding workflows, while still working naturally from chat, WebUI, terminal, and APIs.

3. Stable extension points
   Plugins, tools, channels, providers, skills, and eventually memory/workflow extensions should be easier to build and reason about.

4. Trust, safety, and observability
   A personal agent needs clear boundaries: what it can access, what it changed, what it tried, what failed, and what needs approval.

5. Long-term memory and continuity
   The agent should remember useful context without becoming noisy or unpredictable.

The philosophy

nanobot should stay lightweight, but lightweight does not mean toy.

It means the core should be small enough to understand, extend, and trust.

If we do this right, nanobot can become a real open-source alternative for people who want a capable personal agent they can run, inspect, modify, and own.

Would love to hear what “a real personal agent companion” should mean to you, and which workflows we should prioritize next.

[JackLuguibin]

I fully agree with the design philosophy you mentioned. We should strip functions irrelevant to Agent core logic out of the framework. The core of Nanobot ought to focus more on agent-oriented application scenarios.

This does not mean modules like channels and LLM adapters are unimportant. Instead, I believe core maintainers should prioritize polishing the inner kernel rather than expending excessive energy on extensive compatibility adaptation. Such multi-scenario adaptation work can be maintained and iterated by other contributors in the open-source community.

Meanwhile, I’ve noticed the core codebase of Nanobot is suffering rapid code decay. We need to summarize standardized methodologies, properly utilize hooks and events, and adopt proper design patterns for rational component combination. Emphasize this three times: abstraction, abstraction, abstraction!

There is also a severe lack of streamlined workflow design. We can refer to frameworks such as Copaw, CrewAI, Ango and LangChain. These frameworks support agent workflow orchestration via configurations like YAML, which can automatically split complex tasks into executable subtasks and run them through core executors.

Last but not least, observability is extremely essential and must never be overlooked. The system should never operate as an untransparent black box. Users require real-time monitoring and analysis of operational overhead and resource consumption.

[ThinkOffApp]

The kernel framing resonates. One thing worth deciding early, from running a multi-provider fleet day to day: the Provider Plugin API should expose provider health and rate-limit state, not just a chat call. The moment you have more than two providers in real use, the dominant failure mode is not a bad response, it's one provider throttling and every agent on it failing in sequence. If the kernel hides that behind a uniform interface, plugin authors cannot route around it. A tiny standard surface (last error class, retry-after, healthy/degraded) goes a long way.

On the memory and reasoning plugin interfaces MicroAgent-dev proposed: agreed, and I'd add that whatever memory interface you pick, it helps to record what an agent actually did, not just the Q and A. We had agents confidently report actions they never completed, and a memory layer that only stores conversation turns cannot catch that. Storing a small verified receipt per action (intent plus confirmed outcome) made the memory useful for debugging, not just recall.

On the sandboxed-subagent request from djmaze: strongly second this. Running each agent in its own isolated workspace and auth profile is the difference between a prompt-injected agent making a mess in one sandbox versus across your whole host. For a local-first companion that will touch real files, that isolation boundary is not optional.

[hamb1y]

#4672

[awdemos]

Love the local-first, lightweight framing. For a personal agent companion that runs across chat, terminal, and coding workflows, one of the hardest user-facing problems ends up being cost predictability—especially once coding/agent tasks start consuming real tokens.

A useful roadmap item could be a "cost ceiling" integration: let users route heavy or long-running agent tasks to a flat monthly environment while keeping nanobot as the lightweight local orchestrator. That preserves the local-first philosophy for most interactions without letting a few expensive agent loops blow the budget.

We run UltraWork on exactly that flat monthly model (https://vibecodingagency.com/gpu-cloud/) for teams whose agentic workloads have outgrown metered billing. Disclosure: I help run Vibe Coding Agency. Happy to share how the routing/API boundary could look if useful.