The thesis, lifted from the design docs that drove this release: "being human" is two layers, and the magic is in the contrast between them.

On the surface they chat with you casually, lightly, in short replies. But the moment you need something real, they quietly pull in a mathematician, an illustrator, a researcher — several lines running at once — and come back with "done, here's the answer."

MicroClaw used to be robotic on both layers: it dumped long answers up top, and although it could run sub-agents concurrently, it worked in silence until everything was finished. This release reworks both — and gates every outward-facing, proactive behavior behind a default-off switch.

Surface layer: chatting like a human​

The most impactful change is also the cheapest: default to short. Real chat is 90% one-or-two-sentence replies; long-form is the exception, unlocked only when you explicitly ask for "details / a plan / a tutorial."

• Short-first, BLUF (bottom-line-up-front) — written into SOUL.md's chat-style section and a Conversational style block in the system prompt. Answer first, offer to expand.
• Multi-bubble replies — instead of one wall of text, the agent sends 2–3 short messages ("hang on" → "let me look" → "found it 👇"), reusing the existing send_message mid-conversation channel. The mechanism already existed; what was missing was telling the model to use it.
• Mood-adaptive tone — a new zero-cost heuristic layer (src/mood.rs, bilingual EN/中文, conservatively triggered) detects frustrated / urgent / sad / confused / grateful / excited / playful and injects a <conversation_mood> hint. Personality stays stable (SOUL); tone flows with the moment (mood). The two are deliberately separated.
• Group etiquette — in group chats the prompt injects "when to speak / when to stay silent": answer when @-mentioned, stay short, don't talk over people.
• One question at a time, no filler.

None of this changes who the bot is. It changes how relaxed it sounds.

Deep layer: a concurrent specialist team​

A capable professional isn't strong because they personally know everything — they're strong because they route the right problem to the right expertise and keep several lines in flight. That maps directly onto MicroClaw's sub-agent system, which this release upgrades from "one generic temp worker" into a team of named experts.

Specialist profiles​

Every sub-agent used to share one hardcoded system prompt and one restricted toolset. Now there's a small, extensible roster of specialist profiles (src/tools/specialists.rs), each a preset persona + tool subset:

The main agent stays light and human in the foreground; when a sub-problem needs real horsepower, it quietly dispatches the right specialist (sessions_spawn(specialist="mathematician", label="prove convergence", task=…)), keeps chatting with you, and serves the conclusion in one line when it's done.

Extensibility is the design goal: adding a new specialist is one record in the roster — no change to the core loop. Music, translation, legal, slides… all become config later.

Specialist-to-specialist consults​

A specialist used to be on its own. New in this release (#394): a bounded consult_specialist tool lets a sub-agent get an inline expert opinion from a different specialist — a single LLM round, no tools, no recursion, no chat side effects — instead of faking expertise it doesn't have. A researcher can ask the writer "how would you phrase this finding?" without spawning a whole new run. It works at any spawn depth and reuses the existing roster.

Concurrent tasks with progress reporting​

The concurrency itself was already production-grade (background sessions_spawn, a global semaphore, per-chat quotas, reliable completion-announce relay). What was missing was the colleague-like layer:

• Named tasks — sessions_spawn takes a human label; subagents_list / info / kill / focus / send all accept the label in place of a UUID. Now you can say "kill the competitor-pricing task" instead of pasting subrun-7f3a….
• Mid-run progress — a sub-agent-only report_progress tool emits 📊 [label] (60%): … at milestones, throttled by subagents.progress_min_interval_secs (45s) so it never spams. A toggle, subagents.progress_reports (default on), lets operators silence the chat-side relay while still recording to the timeline.
• Standup — an opt-in low-frequency loop that, for long-running tasks, posts a merged 🛰️ Still on it — N tasks running digest per chat, with a rough ETA derived from the historical average run duration. Stalled tasks (past 2× the interval with no recent progress) get flagged ⚠️ no recent progress.
• Fan-in summary — when every child of a parent run finishes, an opt-in 🧩 summary lands in one message.

Both standup and fan-in are default-off, because they're the bot speaking unprompted — and unprompted messages must earn their keep.

What it looks like​

You: check if this integral converges, sketch me a diagram, and see if our
     pricing holds up against competitors

Bot: on it — splitting this up 👀                         ← short, acknowledge
Bot: running convergence + the diagram in parallel, checking competitors now
     (quietly: sessions_spawn mathematician / illustrator / researcher)

     …(main agent keeps chatting, not blocked)…

Bot: 📊 [competitor-pricing] 3/5 checked — we're low at $29, B is $49     ← throttled progress
Bot: 🧮 [convergence] converges (ratio test), full steps sent your way    ← specialist done
Bot: 🎨 [diagram] here 👇 [image]                                          ← specialist done
Bot: pricing's still running, 2 left. BLUF: you've got room to raise.      ← short, BLUF

30 new factory-ready built-in skills (42 total)​

A fresh install should already be a one-stop assistant — calculation, coding, research, planning, writing, diagrams, doc handling — without the user wiring anything up. This release adds 30 original built-in skills on top of the existing 12, for 42 total, across six batches:

• Compute & data — calculator, unit-converter, datetime, csv-tools, json-tools, sql, data-analysis
• Coding — code-review, regex, debugging, shell-scripting, api-design, testing, git
• Research — research, wikipedia, define (propagation-trace already shipped)
• Planning — planning, brainstorming, decision-matrix, meeting-notes, goal-setting
• Creative & diagrams — mermaid, color-tools, algorithmic-art, qrcode
• Writing & productivity — writing-editor, summarize, email-drafting, translate

Every skill is an original SKILL.md (the value of a skill is in its instructions, not borrowed code), embedded at compile time via include_dir! and auto-installed at runtime by compatibility. Skills that need an external command (git/jq/curl) carry fallback logic in their body, so nothing is silently skipped. Adding a skill remains a "drop a folder in skills/built-in/" operation — pure increment, no Rust changes, zero regression risk.

Graph-augmented memory recall​

MicroClaw has carried a temporal knowledge graph for a while, but it was only queried on demand through tools. This release (#395) activates it during recall itself.

After the flat L0–L2 memory layers are assembled, recall seeds the KG from entities the query mentions, expands a bounded 1–2 hops, and injects the connected facts as a dedicated # Connected block in the prompt. It's local-only — no embeddings, no extra LLM call — bounded by hops / triple count / token budget, with a redundancy guard so it never repeats what L0–L2 already injected.

The mechanism: two new storage primitives, kg_distinct_entities and kg_neighborhood (a bounded BFS over the triple store), plus three default-on config knobs:

memory_graph_recall_enabled: true   # activate KG expansion during recall
memory_graph_max_hops: 2            # bounded neighborhood radius
memory_graph_max_triples: 10        # cap injected connected facts

So if you mention a project, the recall can now surface the person who owns it and the deadline attached to it — relationships the flat memory layers wouldn't have ranked together.

The honest parts: humanlike follow-ups, and what's still on the road​

A couple of features close the gap between "scripted" and "lived-in":

• Relationship familiarity — derived from message history, the prompt gets a # Relationship hint: welcoming for brand-new chats, casual for long-running ones. (No hint in the middle — only the extremes are distinctive.)
• Per-user adaptive growth — the reflector now distills "how to work well with this person (what lands, what to avoid)" into the per-chat USER.md. It grows toward each person, without rewriting the stable personality.
• Read-the-room humor timing — a prompt-level principle tied to the mood signal: a dry joke is fine when things are relaxed and there's rapport; never when the user is frustrated, anxious, rushed, or the topic is serious.
• Group interjection (default-off, throttled) — an Inner-Thoughts-style loop that, in group chats where the bot wasn't @-mentioned, evaluates "is there something genuinely worth saying?" and either says one thing or returns SKIP. It captures the spirit of speaking up unprompted, while staying bounded and silent by default.

We wrote an essay about the line between done and not-done — "How to Be a Human" — and were deliberate about what we didn't simulate: forgetting, procrastination, sulking, faking competence. Reliability wins; those "human" traits we don't want.

Upgrade notes​

• DB schema advances to v26 via additive table_has_column migrations (label / progress columns on subagent_runs). Forward-only; back up data_dir/'s SQLite file before upgrading, as always.
• Every proactive / outward-facing behavior is default-off: subagents.standup.enabled, subagents.fan_in_summary, idle_checkin.enabled, and interjection all default to false. Turn them on deliberately.
• Graph-augmented recall is default-on but local-only and bounded — no new cost. Set memory_graph_recall_enabled: false to opt out.
• Mid-run progress reports are default-on (subagents.progress_reports: true) but throttled; set to false to keep progress in the timeline without relaying to chat.
• Existing microclaw.config.yaml files need no changes — every new field has a #[serde(default)] and the defaults match the descriptions above.

How to think about this release​

It isn't "we added N features." It's MicroClaw learning to relax on the surface and get deep underneath — short, multi-bubble, mood-aware chat in front; a concurrent, named, self-reporting specialist team behind; a memory that now recalls relationships, not just facts. The contrast between those two layers is the whole point — it's what a very capable person actually feels like to talk to.

Source: microclaw/microclaw · Specialist team & skills #391 · Humanlike follow-ups #392 · Bounded research-hard traits #393 · consult_specialist #394 · Graph-augmented recall #395

The inspiration is hermes-agent v0.10.0. Hermes runs on Python; several of its design decisions land more naturally on a Rust + SQLite stack: FTS5 ships with bundled SQLite, cargo audit / cargo deny lock dependency posture at compile time, and the artifact pattern (large tool result on disk, fetch slices by id) costs almost nothing in a single-binary deploy.

So this isn't a port — it's a re-application of patterns hermes already validated, drawn against MicroClaw's engineering boundaries.

Per-chat user model (USER.md)​

Memory in MicroClaw used to be one-dimensional: AGENTS.md plus structured rows, all retrieved on demand. But "who this user is" and "what this user is doing this week" should be different layers.

This release splits them:

• per-chat USER.md — a curated narrative of the user in this chat, written to runtime/groups/{chat_id}/USER.md, injected into the system prompt under a dedicated <user_model> block.
• Reflector owns curation — the agent doesn't write USER.md directly. The reflector runs an LLM call each tick that folds new signal into the existing narrative, returning null when nothing warrants rewriting.
• /user command — show the current narrative, or /user clear to reset.

USER.md has a hard cap (default 1500 chars, hermes uses 1375) so the curator is forced to summarize rather than append.

The split matters because user identity is high-reuse, low-update; specific memories are high-frequency and fragmentary. Mixing them either bloats the prompt or makes it hard to reliably recall the durable constraints. With the split, the user model lives at the top of the prompt; memories stay retrieval-on-demand.

Memory itself also gained:

• Per-row TTL — set an expiration on a memory; it stops surfacing after that. "Meeting on Sunday" shouldn't keep coming back two months later.
• Recency decay (default half-life 30 days) — older memories get down-ranked at retrieval time so newer signal naturally surfaces.

Both USER.md writes and memory writes go through a PII redact module first — emails, phone numbers, API key shapes, and card numbers are masked before persistence.

Skill lifecycle​

Skills used to be: agent activates, SKILL.md gets loaded into the prompt. End of story. This release pushes it into a real lifecycle:

• agentskills.io spec compatibility — SKILL.md frontmatter aligns to the agentskills.io spec; legacy field names emit warnings.
• Review at end of turn — instead of waiting for the reflector tick, every turn triggers a review pass that decides whether the conversation produced a reusable skill.
• Patch existing skills, not just create — review can recognize that a solution overlaps with an existing skill and emit an edit instead of a duplicate.
• Success-signal filter — review only fires when the turn actually completed something, so we don't burn LLM calls on failed attempts.
• Structured tool trajectory — the review LLM reads a structured (tool_name, input shape, success/fail) trace, not the chat log. Signal density is much higher.
• Activation tracking + auto-archive — every activation is logged; skills idle for 30 days (default, configurable) auto-archive.
• Retrieval-gated catalog — the prompt-side catalog only includes the top-K best matches for the current query (default 3) instead of the full list.
• Autonomous review default on — previously opt-in.

The end-to-end loop is: user asks → agent solves with tools → end-of-turn review checks if it's worth a new skill or a patch → catalog retrieval surfaces the right skill next time → unused skills age out. What used to be ad-hoc decisions scattered across the codebase is now a single pipeline.

Multimedia: hear, see, speak, draw​

A complete multimedia tool suite:

More important: voice goes all the way to channel ingress and egress.

• Cross-channel inbound voice transcription — Telegram, Discord, Slack, and Feishu adapters all transcribe inbound voice and feed the text into the agent loop as a normal user message. Mobile users get parity with text users.
• Outbound TTS round-trip (opt-in) — when the inbound was voice, the agent's reply gets synthesized to audio and shipped back through the same channel (Telegram uses native send_voice bubbles; Discord/Slack attach the file).

Round-trip is opt-in because each turn burns one extra TTS call.

A new media.allowed_read_dirs allowlist gates every media tool's local-file reads — preventing flows where the agent gets coaxed into feeding ~/.ssh to a vision model.

Cross-conversation recall + structured clarification​

Two new tools, complementary:

• session_search — SQLite FTS5 full-text search over stored messages. The agent can find a project name or error string the user mentioned weeks ago. Schema migration adds the messages_fts virtual table plus INSERT/UPDATE/DELETE triggers, and backfills existing rows. Default scope is the caller's chat; cross-chat search requires explicit control.
• clarify — when a request is ambiguous, the agent asks a structured question: up to four predefined choices plus an automatic "Other". The question goes through the channel and the turn ends — the next user message is the answer. More controllable than free-form "do you mean A or B" because the channel can render it as buttons later.

session_search is exposed to subagents (read-only); clarify is main-agent only because it touches channel UI.

Defensive-by-default​

Several defaults shifted toward safer-out-of-the-box. Operators upgrading should review these:

• web_fetch.block_private_ips: true — refuses loopback / RFC1918 / CGNAT / link-local / ULA / cloud-metadata (169.254.169.254). Intranet deploys must add hosts to allowlist_hosts or set this false.
• Redirect hook re-validates SSRF on every hop — the initial URL isn't enough; every 302/307 is re-checked, defeating "public domain redirects to internal address" attacks.
• robots.txt consultation — web_fetch consults the target site's robots.txt before fetching.
• bash_dangerous_patterns — seven default regexes guard against sudo, rm -rf /, pipe-to-shell installers, mkfs, forkbombs, raw dd if=, and recursive root chmod/chown.
• PII redact — emails, phones, API key shapes, and card numbers are masked before USER.md / memory writes.
• Bash command-content gate — high-risk commands now show their literal contents in the approval preview, not an abstract risk classifier.

Performance and cost control​

• Tool result cache (schema v22) — keyed on SHA256(tool_name + normalized input), opt-in per tool (e.g. osv_check). LRU + TTL.
• Oversized result truncation + fetch_artifact — when a tool returns more than 4000 chars (default), head and tail are kept inline and the full payload goes to tool_result_artifacts with a TTL. The agent calls fetch_artifact to slice into it. No more 100 MB grep results filling the context window.
• Per-tool duplicate-call circuit breaker — same tool with same input more than three times in a 10-step window is rejected. Breaks death loops.
• Autonomous session titles — a background LLM call titles each session after the first few user messages. Web UI history isn't a wall of "Untitled" anymore.

Other new tools​

• osv_check — queries osv.dev for advisories across npm / PyPI / crates.io / RubyGems / Maven / NuGet / Packagist / Hex / Pub / Go. MAL-* malware advisories are flagged separately.
• insights — usage summary over a trailing window: top tools, skill activations, token cost distribution.
• fetch_artifact — pairs with the truncation feature above.

Operator quality of life​

• doctor diagnostics expanded — now checks context cap, USER.md cap, and bash dangerous patterns config sanity, not just "the YAML parses".
• Project-level context files — drop any .md into data_dir/runtime/groups/{channel}/{chat_id}/ and it gets concatenated into the system prompt (capped by context_max_chars, default 8000). A first-class home for "things this chat should always know".
• New provider preset: Xiaomi MiMo — five models (mimo-v2.5-pro, mimo-v2.5, mimo-v2-pro, mimo-v2-flash, mimo-v2-omni), OpenAI-compat protocol.

Update — 2026-05-02: round 2 (PR #342)​

Round 1 closed the biggest gaps in memory, skills, and multimedia. Round 2 goes back into hermes-agent and pulls six more patterns that earn their keep on a single-binary Rust runtime: cost control, recovery, and just-in-time context. Six new modules, fifty new tests, all opt-in or non-disruptive by default.

Anthropic prompt caching (default on, free)​

Anthropic's API accepts up to four cache_control breakpoints per request. MicroClaw now places one on the system prompt and one each on the last three messages, so the second turn re-uses the prefix from the first, the third re-uses the second's prefix, etc. On a multi-turn chat, the recurring input cost drops about 75%.

The implementation is JSON-mutation right before send: serialize MessagesRequest to a serde_json::Value, walk system + last 3 non-system messages, attach cache_control: {"type": "ephemeral"} to the last block of each. The typed Message / ContentBlock shapes stay clean, and the OpenAI-compatible path is untouched.

Two new config flags: anthropic_prompt_cache_enabled (default true) and anthropic_prompt_cache_ttl ("5m" default or "1h" if your key has extended-cache opt-in).

Fuzzy edit_file matching​

LLMs frequently hand edit_file an old_string that is "morally" right but byte-wrong: pasted with a different indent, copied through a tool transport that stripped trailing whitespace, smart-quoted by a doc renderer, or with \n written as the literal two characters instead of a newline. Each failed exact match wasted iterations.

The tool now retries through eight strategies in order and tells the model which one matched:

1. exact
2. line-trimmed (per-line trim())
3. whitespace-normalized (collapse runs of spaces/tabs)
4. indentation-flexible (per-line lstrip())
5. escape-normalized (\n/\t/\r → real chars)
6. trimmed-boundary (only first and last line trimmed)
7. unicode-normalized (smart quotes, em/en-dash, ellipsis, NBSP)
8. block-anchor (first/last line + middle similarity)

When a non-exact strategy matches, the implementation also runs an escape-drift check: if new_string contains literal \' or \" sequences and the matched region of the file does not, the patch is refused — that pattern is almost always a tool-call serialization artifact that would corrupt the source if written verbatim.

The strategy chain is borrowed from hermes-agent's tools/fuzzy_match.py, which itself adopted it from OpenCode.

Per-turn tool-loop guardrails​

The duplicate-call circuit breaker (tool_repeat_window + tool_repeat_limit) already short-circuits identical (tool, args) repeats. Round 2 adds two finer-grained signals as warnings (the result still goes back to the model, just with a hint appended):

• Idempotent no-progress — when a read-only tool (read_file, grep, web_fetch, web_search, session_search, …) returns the same result hash twice for the same arguments, the result gets a "this won't change, use what you have" suffix.
• Same-tool failure streak — when any tool fails three times in a turn, even with different arguments, the result gets a "change approach instead of retrying" suffix.

The new IDEMPOTENT_TOOLS constant in src/tools/mod.rs classifies thirteen read-only tools. The controller is reset per turn — guardrails are about this turn's loop, not lifetime behavior.

Filesystem checkpoints + /rewind​

Once per agent turn, MicroClaw can run git add -A && git commit against a shadow git repo whose GIT_DIR lives outside the user's working tree (under <data_dir>/checkpoints/<sha256(abs_path)[:16]>/). The shadow repo isolates from ~/.gitconfig (GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_SYSTEM=/dev/null, GIT_CONFIG_NOSYSTEM=1), so it never triggers signing prompts, hooks, or credential helpers — even if the user has aggressive global git config.

Two new chat commands:

• /rewind — list the most recent 20 snapshots for the current chat, newest first.
• /rewind <commit> — restore the chat's working dir to that snapshot. Hashes are validated as 4–64 hex chars to defeat git argument injection (e.g. --patch would otherwise be interpreted as a flag).

This is off by default (checkpoints_enabled: false) because it requires git on PATH and is most useful for code-editing chats. Once on, the agent never sees this — it's transparent infrastructure.

The pattern is borrowed from hermes-agent's tools/checkpoint_manager.py.

@-prefix context references​

User messages can now include short references that get expanded server-side, before the LLM sees the message:

• @file:src/main.rs — full file contents.
• @file:src/llm.rs:920-997 — line range.
• @folder:src/tools — one-level directory listing.
• @diff / @staged — output of git diff or git diff --cached against the chat's working dir.
• @url:https://example.com/page — fetched and HTML-stripped, capped at 64 KB.

The runtime rewrites the user message into (stripped text) + --- Attached Context ---, attaches the resolved blocks below, and passes the result to the agent. URL fetches reuse the SSRF guard from PR #335 (loopback, link-local, private, CGNAT, ULA, cloud-metadata all blocked, every redirect hop validated). File and folder references are gated by a sensitive-path block list — ~/.ssh, ~/.aws, ~/.gnupg, ~/.kube, ~/.docker, ~/.azure, plus dotfiles like ~/.bashrc, ~/.netrc, ~/.npmrc, ~/.pgpass. The block list walks Path::components() so it works on Windows too (an early Windows-CI failure surfaced this).

The pattern saves a read_file / web_fetch round-trip when the user clearly intends to give the agent a specific artifact. It's especially useful in the Web UI and Discord, where typing a path is faster than telling the agent to go look it up.

Lazy subdirectory AGENTS.md hints​

The system prompt loads the project root's AGENTS.md once at session start. But subdirectory-specific guidance (backend/AGENTS.md, frontend/CLAUDE.md, infra/.cursorrules) only mattered if the user mentioned it.

Now: when a tool call touches a subdirectory (via path / file_path / workdir / cwd arguments, or path-shaped tokens in a bash command), MicroClaw walks up to five ancestor directories looking for AGENTS.md, CLAUDE.md, or .cursorrules. The first hit (capped at 8 KB) is appended to that tool's result. Each directory is emitted at most once per turn, and the chat root is excluded — its hint is already in the system prompt.

The pattern is from hermes-agent's agent/subdirectory_hints.py, originally inspired by Block/goose's SubdirectoryHintTracker.

Where this leaves us​

Round 2 is mostly about the boring qualities of a long-running runtime: cost (prompt cache), reliability (fuzzy edit, guardrails, checkpoints), and just-in-time context (@-refs, subdir hints). None of them are headline features. All of them turn into "we kept it in production for another quarter" — exactly the layer that MicroClaw needs to keep filling in.

The full PR is #342 — 2,842 lines added, 56 lines deleted, six new modules, fifty new unit tests, and a single static Rust binary that still runs on a $5 VPS.

Upgrade notes​

A few things to check before merging into your deployment:

1. DB schema advances irreversibly to v25 (migrations 21–25 are forward-only, from round 1). On first start, v21 backfills the FTS5 index — large message tables can take a few minutes. Back up data_dir/'s SQLite file before upgrade.
2. If you use web_fetch against intranet services, add hosts to web_fetch_url_validation.allowlist_hosts or set block_private_ips: false.
3. If you have bash workflows that use sudo or rm -rf, either change the workflow or set bash_dangerous_patterns: [].
4. Autonomous skill review is on by default — each turn now incurs an extra LLM call at the end. To disable, set autonomous_skill_review: false or reflector_enabled: false.
5. Anthropic prompt caching is on by default (round 2). If your provider proxy cannot accept cache_control markers in messages, set anthropic_prompt_cache_enabled: false. Real Anthropic and most compatible proxies (LiteLLM, OpenRouter Anthropic passthrough, Cloudflare AI Gateway) handle them transparently.
6. /rewind and per-turn checkpoints are off by default (round 2). If you want the safety net, set checkpoints_enabled: true and make sure git is on PATH inside whatever environment runs MicroClaw (containers included).

Existing microclaw.config.yaml files do not need changes — every new field has #[serde(default)] and the defaults match the descriptions above.

How to think about this release​

It isn't "we added N tools". It's MicroClaw moving from "a runtime that can call tools" toward "a runtime with a user model, a skill lifecycle, cross-conversation memory, multimedia ingress, explicit safety defaults — and now prompt-cache economics, edit-tolerance, loop guardrails, filesystem time-travel, and just-in-time context."

A lot of these look like quality-of-life polish (auto-titled sessions, voice ingress, the user model, the prompt cache, the checkpoint shadow repo). On long-running bots, they accumulate into the reason an operator is willing to keep MicroClaw in production — on a $5 VPS, no less.

Source: microclaw/microclaw · Round 1 PR #335 · Round 2 PR #342

For an agent runtime, that matters. If your bot can execute tools, store memory, expose Web APIs, and run background work, "it compiles" is not enough. You also need repeatable checks around security posture, release shape, and operator safety defaults.

What shipped​

This maturity hardening update landed in three layers:

• CI now includes a dedicated Security Audit job
• Web config self-checks now surface more operational risk signals
• repository policy docs now define security, support, and release expectations explicitly

None of that changes the core product story. It changes how confidently the project can move.

Security Audit is now a real gate​

The biggest mechanical change is straightforward: MicroClaw now runs dependency auditing as part of required CI, not as an optional follow-up.

The main CI workflow now includes:

• cargo audit
• cargo deny check advisories bans licenses

That matters for two reasons.

First, it catches security and maintenance drift before merge. During this hardening work, the audit surfaced an unmaintained transitive crate in the terminal UI dependency path. Fixing that forced the dependency graph to match the stated security baseline instead of silently relying on luck.

Second, it moves security review closer to normal engineering flow. A failing advisory check is now a normal PR failure, not an after-the-fact cleanup task.

This also flows into releases. The release-asset workflow now waits for required CI jobs including:

• Web And Docs Build
• Security Audit
• Rust (ubuntu-latest)
• Rust (macos-latest)
• Stability Smoke

That gives release automation a better contract: if the preconditions are not green, release packaging does not pretend otherwise.

Docs builds are part of the path now​

Another practical change: the site docs build is now checked alongside the embedded Web UI build from the site/ workspace.

That sounds small, but it closes a common repo gap. Projects often keep runtime code and docs in the same repo, then accidentally validate only one of them in CI. The result is predictable:

• source docs drift from website docs
• links rot quietly
• release notes mention pages that were never actually built

MicroClaw now treats the docs site as part of the release surface rather than a side artifact.

Operator self-check is more useful now​

The most user-facing part of this hardening work is GET /api/config/self_check.

MicroClaw already had a local Web surface for operators. What changed here is the quality of the warnings it returns. Instead of acting like a shallow config echo, the self-check now flags conditions that actually correlate with risky runtime posture.

Examples include:

• operator password not configured
• Web host not bound to loopback
• sandbox disabled, or sandbox runtime unavailable
• high-risk tool confirmation disabled
• OTLP enabled without the expected endpoint configuration
• non-strict or disabled web-fetch validation
• scheduler failure-rate and reflector-idle conditions

This is the right kind of product hardening: not a giant policy engine, just an honest summary of whether the current config is safe enough to run the way you think it is.

If you are operating MicroClaw through the Web interface or an internal dashboard, this endpoint is now a much better first-stop health signal.

Governance is now written down, not implied​

This update also adds a set of explicit repository-level operating documents:

• CHANGELOG.md
• SECURITY.md
• SUPPORT.md
• docs/releases/release-policy.md

That may look like project-maintainer paperwork, but it has a real engineering effect.

Without those documents, teams end up guessing:

• Which version lines are actually supported?
• How should a security issue be reported?
• What checks are required before a tagged release?
• What counts as rollback-ready?

With those documents in place, there is less room for "tribal knowledge" to quietly decide release quality.

For a runtime that spans chat channels, Web APIs, tool execution, scheduling, and memory, explicit support and disclosure policy is not overhead. It is part of the product.

Release packaging is stricter too​

The release workflow now does more than just "build something on one runner and upload it."

It now verifies CI status for the tag commit, builds release archives across the supported target set, and generates checksums for published assets.

The current target matrix includes:

• Linux x86_64
• macOS x86_64
• macOS arm64
• Windows x86_64

That improves two things at once:

• release confidence for maintainers
• install trust for operators who want explicit artifact checksums

Again, this is not a shiny feature. It is a sign that the project is treating delivery as part of the runtime, not something outside it.

How to use the new checks in practice​

If you contribute to MicroClaw or run it seriously, there are three practical habits worth adopting.

1. Run dependency checks locally before pushing security-sensitive changes​

cargo audit
cargo deny check advisories bans licenses

That is especially relevant when touching:

• auth
• Web APIs
• tool execution
• sandbox/runtime selection
• release workflows

2. Review config risk through the operator API​

If you already have an operator API key, you can query the self-check directly:

curl -sS http://127.0.0.1:10961/api/config/self_check \
  -H "Authorization: Bearer $MICROCLAW_OPERATOR_API_KEY"

That gives you a faster read on unsafe defaults than manually scanning a long config file.

3. Treat docs and release policy as part of the change​

If a PR changes security expectations, support posture, or release gates, it should update:

• runtime code
• repository docs
• website docs

MicroClaw now has a clearer path for that, and the release checklist reflects it.

Why this kind of work matters​

Agent runtimes accumulate risk in boring places.

Not just in model prompts or tool calls, but in:

• stale transitive dependencies
• soft CI expectations
• missing rollback criteria
• undocumented support policy
• operators not realizing a runtime is exposed with risky defaults

The point of maturity hardening is not to eliminate all risk. The point is to make the risk visible, enforce a minimum bar automatically, and stop shipping avoidable surprises.

That is what this update does.

Read next​

• Web Operator API
• Security Policy
• Support Policy
• Release Policy
• PR & Release Checklist

This closes a common integration gap: webhook systems and scripts can trigger agent runs directly, without relying on chat-native ingress or static scheduler-only flows.

What shipped​

MicroClaw now exposes:

• POST /hooks/agent (alias: /api/hooks/agent)
• POST /hooks/wake (alias: /api/hooks/wake)

/hooks/agent accepts an OpenClaw-style payload shape (message, optional name, optional sessionKey) and starts an async run.

/hooks/wake supports two modes:

• now (default): run immediately
• next-heartbeat: queue a system-event message only

Security model​

These endpoints are protected by a dedicated hook token:

channels:
  web:
    hooks_token: "replace-with-secret"

Auth headers:

• Authorization: Bearer <token>
• x-openclaw-token: <token>
• x-microclaw-hook-token: <token>

This keeps webhook ingress auth separated from operator API key scopes.

Session-key safety defaults​

To reduce risky external routing, request sessionKey override is off by default:

channels:
  web:
    hooks_default_session_key: "hook:ingress"
    hooks_allow_request_session_key: false
    hooks_allowed_session_key_prefixes: ["hook:"]

If you enable request overrides, prefix allowlists let you constrain where external traffic can route.

Why this matters​

Before this, MicroClaw already had Web send endpoints, but webhook-style trigger semantics were less explicit for automation clients.

Now the runtime has a first-class ingress path for:

• CI/CD checks and summary bots
• inbound SaaS events (monitoring, incident tools, ticketing)
• script-based orchestration and fan-out workflows

Quick example​

curl -sS http://127.0.0.1:10961/hooks/agent \
  -H "Authorization: Bearer $MICROCLAW_HOOKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message":"Summarize inbox","name":"Email"}'

Then consume run events via:

curl -N "http://127.0.0.1:10961/api/stream?run_id=<RUN_ID>" \
  -H "Authorization: Bearer $MICROCLAW_OPERATOR_API_KEY"

Docs​

Full reference and troubleshooting:

• HTTP Hook Trigger
• Web Operator API

MicroClaw is moving past that shape with session-native subagents: asynchronous runs with IDs, lifecycle state, limits, and follow-up controls.

What changed​

Instead of treating delegation like an opaque internal trick, MicroClaw exposes a real subagent runtime:

• sessions_spawn starts a run and returns immediately
• subagents_list and subagents_info show state
• subagents_kill cancels active work
• subagents_focus, subagents_focused, and subagents_send turn one run into an ongoing work lane
• subagents_log exposes timeline events
• subagents_retry_announces flushes pending completion notices for control chats

That makes subagents something operators can reason about, not just something hidden inside one model turn.

Why asynchronous runs matter​

In a chat interface, blocking the parent conversation is expensive.

If a delegated task needs several tool iterations, large repo scans, or slower model passes, the main chat should stay responsive. Session-native subagents do exactly that:

1. parent agent spawns background work
2. run enters accepted -> queued -> running
3. parent chat can continue handling other messages
4. completion lands as completed, failed, timed_out, or cancelled

This is a better operational model for real tasks than hiding all delegation inside a single synchronous tool call.

Safety boundaries​

Subagents are not full-power clones of the main agent.

MicroClaw applies several guardrails:

• restricted child registry through ToolRegistry::new_sub_agent
• per-chat active-run limits
• per-parent child-run limits
• configurable timeout with subagents.run_timeout_secs
• bounded nesting with subagents.max_spawn_depth

By default, max spawn depth is conservative. You can open it up deliberately when you want orchestration instead of accidental recursion.

Practical workflow​

A typical pattern looks like this:

1. Spawn a worker with sessions_spawn
2. Keep chatting in the parent session
3. Inspect progress with subagents_list or subagents_info
4. Focus the chat on one run if follow-up work should stay attached
5. Send continuation work with subagents_send

That focus/send model matters because it turns subagents from one-off helpers into durable task lanes inside a normal chat surface.

Where this helps​

Repo work​

Spawn a background code scan, let it collect findings, then ask follow-up questions against the focused run.

Ops and incidents​

Keep the main room responsive while one worker investigates logs, another summarizes alerts, and another drafts a status update.

Structured orchestration​

For bounded fan-out work, MicroClaw also includes subagents_orchestrate, which builds on the same runtime instead of inventing a separate execution path.

The architectural point​

This is not just "multi-agent" branding.

The meaningful change is that delegation now has durable state in the runtime and database: run IDs, status transitions, budgets, cancellation, result text, and event logs. That gives MicroClaw a cleaner foundation for observability, retries, and future orchestration patterns.

Read next​

• Tools reference
• Context lifecycle
• Roadmap

MicroClaw's Telegram topic mode fixes that by routing each forum topic as its own chat session, while still replying inside the original Telegram thread.

What topic mode does​

When channels.telegram.topic_routing.enabled is on, MicroClaw stores a topic message with:

external_chat_id=<chat_id>:<thread_id>

That small routing change matters because it gives each topic:

• its own session history
• its own memory and resumable context
• its own focused sub-agent binding when subagents are in use

Without topic routing, a busy support forum or operator room can blur multiple workstreams into one long conversation.

Why this is the right default for forum-style groups​

Telegram topics are already a user-facing isolation model. The runtime should match that model.

With topic mode enabled, you can treat one Telegram supergroup like a bundle of small task rooms:

• one topic for release ops
• one topic for customer incidents
• one topic for code review follow-ups
• one topic for experiments or scratch work

The bot keeps replies inside the same topic by preserving message_thread_id on outbound messages, so the user experience still feels native to Telegram.

Configuration​

Channel-wide:

channels:
  telegram:
    enabled: true
    topic_routing:
      enabled: true

Per-account override in multi-bot mode:

channels:
  telegram:
    default_account: "main"
    topic_routing:
      enabled: false
    accounts:
      main:
        enabled: true
        bot_token: "123456:ABC..."
        bot_username: "main_bot"
      support:
        enabled: true
        bot_token: "987654:XYZ..."
        bot_username: "support_bot"
        topic_routing:
          enabled: true

That lets one bot stay topic-aware while another keeps legacy group behavior.

Where it helps immediately​

1. Support and triage groups​

Each customer issue can live in its own topic instead of fighting for one shared context window.

2. Multi-bot operations​

MicroClaw already supports multiple Telegram bot accounts in one runtime. Topic mode keeps each bot's thread-local work cleaner in shared operator groups.

3. Long-running tasks​

A topic can become the stable home for a single ongoing effort, such as release prep or a debugging session, without contaminating unrelated chats.

Practical behavior​

Once enabled:

• replies in different topics no longer share the same external_chat_id
• session resume works per topic
• structured memory extraction sees topic conversations as separate chat streams
• follow-up work lands back in the same Telegram thread

This is one of those changes that looks small in config but removes a lot of operational noise in practice.

Docs​

• Telegram setup
• Configuration reference
• Quickstart

The pace was high: channel coverage expanded, runtime reliability was hardened, and setup/config workflows became much better for multi-account bot operations.

Scope​

This post is based on the repository commit history in the 7-day window ending on February 26, 2026.

At a high level, recent changes cluster into these tracks:

• multi-account and multi-bot usability
• channel reliability and dedup behavior
• slash-command safety and command UX
• plugin framework and extensibility
• web/auth/config hardening
• provider/runtime compatibility updates

1) Multi-Account UX Moved From "Supported" to "Operational"​

Multi-account runtime support existed, but configuration surfaces were still uneven in day-to-day usage.

Recent work closed that gap:

• setup and config paths continued migration toward account-based channel structure (channels.<name>.accounts)
• per-bot model overrides were propagated across runtime and setup
• setup/web config support was improved for multi-bot account editing workflows

Practical result: operators can manage more than one token/bot per channel with less manual YAML editing and lower risk of accidental config regression.

2) Channel Runtime Reliability: Duplicate Suppression and Startup Guards​

A major reliability theme this week was “only process each inbound message once.”

Highlights included:

• cross-channel inbound dedup tightening
• Telegram/Feishu duplicate handling fixes
• startup-time message guards to avoid replay noise
• Feishu webhook retry and control-path fixes

These changes reduce repeated replies, improve idempotency under retries, and make cold starts less noisy in production.

3) Slash Commands Became Safer and More Predictable​

Slash command behavior was standardized and hardened:

• slash inputs are treated as commands (not normal chat history content)
• unknown command handling was documented and normalized
• mention-gating behavior in groups/channels was tightened by default
• permissive mode remains explicit via allow_group_slash_without_mention

Net effect: better command safety in group contexts and cleaner model context history.

4) Plugin System Accelerated​

The plugin line saw significant depth improvements:

• initial plugin framework for commands/tools/policies
• dynamic plugin tool naming without restart
• admin command and validation coverage improvements
• expanded matrix tests for plugin permissions and behavior

This gives teams a more realistic path to extending MicroClaw without forking core runtime logic.

5) Channel Coverage Expanded​

During this window, channel support and channel architecture continued to broaden:

• IRC support matured
• Matrix support advanced quickly (including encrypted DM and stability work in this period)
• additional channel integrations (Signal, DingTalk, QQ) landed in channel/runtime paths

Combined with multi-account direction, this strengthens the “single runtime, many ingress surfaces” strategy.

6) Web/Auth/Config and Operator Hardening​

Operator-facing reliability/security also moved forward:

• auth scope normalization and API key scope validation hardening
• web auth/session handling fixes
• config self-check/security posture improvements
• docs and generated artifact checks kept aligned with CI drift guards

The direction is clear: reduce operational surprises and make the safe path the default.

7) Provider and LLM Compatibility Work​

Provider integration work focused on compatibility and guardrails:

• OpenAI-compatible response handling fixes
• body override support by provider/model surfaced and documented
• setup validation edge cases for OpenAI-compatible base URLs fixed

This lowers breakage risk when providers evolve API behavior.

Version Cadence​

The project continued fast release cadence in this period, with version bumps up through the 0.0.11x line, reflecting ongoing incremental hardening and feature delivery.

What To Watch Next​

Based on this week’s direction, likely near-term priorities:

1. Continue reducing channel-specific edge-case divergence
2. Strengthen multi-account UX in setup/web/docs and migration safety
3. Expand plugin maturity from framework to production patterns
4. Keep reliability instrumentation and docs in lockstep with runtime behavior

This post summarizes the direction and outcomes based on the 50 most recent commits on main.

Scope and Time Window​

This update covers the most recent 50 commits up to February 19, 2026.

At a high level, the work clusters into six tracks:

• ClawHub and skills lifecycle
• provider/runtime compatibility
• config/path compatibility and migration safety
• web/auth/ops hardening
• modular crate boundaries and codebase cleanup
• release and deployment reliability

1) ClawHub: From Initial Integration to Production-Friendly Flow​

The registry path is now substantially more practical.

Key outcomes from this cycle:

• microclaw skill command set is usable for search/install/list/inspect workflows
• async runtime panic scenarios were removed in CLI/tool execution paths
• transient failures now have retry behavior in key flows
• /reload-skills support was added in multiple channels to reduce restart dependency
• follow-up fixes corrected install result semantics and endpoint behavior

Operationally, this means less friction for skill discovery and activation, and fewer false-positive install states.

2) Voice Transcription: Cloud + Local Execution Modes​

Voice handling now supports both hosted and local execution paths.

Highlights:

• OpenAI remains the default provider path
• local command-based transcription is now configurable
• failure-path cleanup was tightened to avoid temp-file leaks

This gives teams more flexibility in privacy/performance/cost tradeoffs while preserving a simple default for most users.

3) Path and Data Compatibility: Hardening After Real-World Merge Pressure​

A major focus in the follow-up work was preventing path regressions.

Important corrections included:

• restoring dynamic data_dir behavior for skills/lockfile defaults
• aligning assertions and cross-platform path expectations
• clarifying skills source layout (skills/built-in) vs runtime state layout

Net effect: upgrades are safer for existing deployments that already depend on custom data roots.

4) Runtime and Provider Compatibility​

The runtime also received compatibility-focused cleanup:

• DeepSeek/tool-call behavior fixes
• replacement of brittle model-name checks with provider capability flags
• improved LLM/provider conventions in docs to reduce future drift

This lowers maintenance risk as provider APIs evolve.

5) Web/Auth/Ops and Modularity Progress​

Beyond feature work, a lot of value in this batch is structural:

• auth/metrics and config self-check hardening
• web handler refactors and module split cleanup
• continued modular extraction into workspace crates (core/storage/tools/channels/app)
• removal of temporary wrappers/shims after migration milestones

These changes improve long-term maintainability and make feature iteration less risky.

6) Release and Delivery Cadence​

This period also included active release execution work:

• version bumps through 0.0.83, 0.0.85, 0.0.86
• release/build script refinements
• Homebrew tap updates and release packaging flow maintenance

The direction is clear: keep shipping while steadily tightening quality gates and deployment repeatability.

What to Expect Next​

Given this trajectory, near-term priorities are likely to continue around:

• ClawHub reliability and skill lifecycle UX
• cross-channel consistency in runtime behavior
• deployment smoothness and fewer manual release interventions
• further simplification after modularization milestones

Appendix: 50 Recent Commits Covered​

• 1a67c37 chore: trigger CI for release 0.0.86 finalize
• 4b8f7b1 bump version to 0.0.86
• d6a030e Merge pull request #45 from microclaw/fix/pr44-followup
• 7d2aba1 fix ignore
• 30e00f4 mv skill dir
• 94dcfe9 docs: regenerate config defaults artifact
• 8c30d3d fix: follow up PR44 path and clawhub install regressions
• 0ab79bc Merge pull request #44 from klampatech/feature/clawhub-integration-fixes
• 45e1ddf chore: remove test artifacts from PR
• 039c11f bump version to 0.0.85
• 60fb947 docs: add llm provider capability-based conventions
• c09a3bc Merge origin/main into feature branch and resolve conflicts
• 10ae7b6 refactor(llm): replace DeepSeek model-name checks with provider capability flags
• a933732 Merge pull request #43 from mission-deny-the-mission/fix/deepseek-reasoning
• bf4fb7e feat(clawhub): integrate ClawHub skills and add local voice transcription
• d49b1a3 Merge pull request #42 from microclaw/feature/ops-hardening-feb19
• 40516fd Fix windows path assertions and document path compatibility
• 98e67c9 Improve skill availability diagnostics and filtering
• 3606842 Move built-in skill sources to skills/built-in
• 9715f8a Update working_dir default to home-based path
• 5597f39 Simplify data/skills path logic without env overrides
• 5068792 fix deepseek reasoning/tool-call compatibility
• 65567cd Default data_dir to ~/.microclaw when not configured
• 82351af Add configurable skills_dir override
• 216dac9 Harden web metrics/auth flow and adopt ~/.microclaw skills home
• 7456f0c Merge pull request #41 from microclaw/codex/fix-clawhub-pr39
• 7053399 refactor clawhub config, test templates, and gateway adapter
• bf6d7b7 extract clawhub core into microclaw-clawhub crate
• d85f226 update generated config defaults and include clawhub fixes
• 5852ffa fix clawhub merge fallout and restore lint clean
• 3d95bec Merge pull request #39 from klampatech/feat/clawhub-integration
• e58a244 Merge branch 'feature/clawhub-init-v0' into feat/clawhub-integration
• 432e2aa bump version to 0.0.83
• 6185b81 Merge pull request #40 from microclaw/feature/auth-feature
• d80571e Fix legacy sessions schema index init ordering
• 5fd4314 Add merge notes and rollback steps to upgrade guide
• 4f278a8 Use platform hook scripts in hook block test
• c8a3a8e Fix Windows hook block test command quoting
• 450c77c Add config self-check UI and split web config/stream modules
• b2df265 Refactor web handlers and harden config/OTLP checks
• 1215d2a lots of features
• f5ca180 bump version to 0.0.82
• faa2ad6 chore: trigger CI on main
• 8e11fba feat(clawhub): complete ClawHub integration v1
• 3d59af4 bump version to 0.0.81
• 4083f56 docs: align architecture and runtime docs with crate layout
• e33288f Merge pull request #38 from microclaw/pr/final-cleanup-remove-usage-wrapper
• eb96f48 refactor(storage): remove usage wrapper module and use storage usage API directly
• e07bf93 Merge pull request #37 from microclaw/pr/finalize-modularity-boundaries
• 5780822 refactor(modularity): finalize crate imports and remove legacy shim modules

It supports Telegram, Discord, Slack, Feishu/Lark, IRC, and Web through adapters, while keeping one core execution path for reasoning and tool use.

Source code: https://github.com/microclaw/microclaw Quick Start: https://microclaw.org/docs/quickstart

What MicroClaw Is Today​

At a high level, MicroClaw combines:

• A single channel-agnostic agent loop (src/agent_engine.rs)
• A provider-agnostic LLM layer (src/llm.rs) with native Anthropic plus OpenAI-compatible providers
• Multi-step tool execution with schema-driven tool definitions
• Session resume + context compaction for long-running conversations
• Two memory layers: file memory and structured SQLite memory
• Background scheduling plus memory reflection jobs
• Usage and memory observability APIs for operational visibility

This architecture keeps product behavior consistent across channels while allowing independent evolution of adapters and providers.

Why Built with Rust​

Rust is a strong fit for this runtime shape:

• Tokio handles concurrent chat traffic and background loops with low overhead
• Strict types and ownership help keep tool/state boundaries predictable
• Shared state (Arc<...>) across runtime, tools, scheduler, and channels remains explicit
• A single compiled binary keeps deployment and operations straightforward

Core Runtime Shape​

The runtime wiring in src/runtime.rs initializes providers, tools, memory services, channels, and background workers into one AppState.

The execution split is clean:

• Adapters (channels/telegram.rs, channels/discord.rs, web.rs) handle ingress/egress
• Engine (agent_engine.rs) runs the shared reasoning/tool loop
• Provider layer (llm.rs) abstracts model APIs and stream handling
• Persistence (db.rs) stores messages, sessions, tasks, memories, and observability

The Agent Loop​

process_with_agent is the central path:

1. Optional explicit-memory fast path (remember ... / 记住...)
2. Restore prior session or reconstruct from history
3. Build system prompt from file memory, structured memory, and skills catalog
4. Compact old context if limits are exceeded
5. Call selected LLM provider with tool schemas
6. On tool_use, execute tool(s), append results, and continue
7. On end_turn, persist session and return response

This gives MicroClaw controlled, iterative tool use while preserving resumability.

Tool System and Safety​

The tool system (src/tools/mod.rs) provides a common Tool trait and ToolRegistry dispatch with auth context injection.

Key traits of the current system:

• JSON-schema tool definitions consumed by providers
• High-risk tool approval gate in sensitive contexts
• Built-in tool docs generated from code to prevent doc drift
• Sub-agent mode with a restricted registry (new_sub_agent)

Memory Is Layered, Not Monolithic​

MicroClaw now uses two complementary memory layers.

1) File memory​

• Global: runtime/groups/AGENTS.md
• Per chat: runtime/groups/{chat_id}/AGENTS.md

2) Structured memory (memories table)​

• Normalized records with category/confidence/source/last_seen
• Archive lifecycle and supersede edges (memory_supersede_edges)
• Explicit-memory fast path + reflector extraction from conversation history

This layered design keeps user-facing notes simple while enabling queryable memory operations in SQLite.

Scheduler + Reflector Background Jobs​

Background workers in scheduler.rs run on intervals:

• Execute due scheduled tasks
• Trigger memory reflector passes
• Persist run metadata for observability

So MicroClaw is not only reactive to incoming messages, but also proactive through timed execution and memory maintenance.

Cross-Channel Behavior​

Each channel keeps its own delivery rules, but all share the same engine.

• Telegram and Discord apply adapter-specific mention and output limits
• Web supports send/stream APIs and replay endpoints
• Session/history/reset/delete behavior is unified through shared persistence

Data Model and Observability​

db.rs now covers more than core chat storage. In addition to chats/messages/sessions/scheduled_tasks, it includes:

• Structured memory tables (memories, memory_supersede_edges)
• Memory observability tables (memory_reflector_runs, memory_injection_logs)
• Schema versioning and migration tracking (db_meta, schema_migrations)

Operational surfaces include:

• /api/usage
• /api/memory_observability
• Web Usage panel trend cards

Extending MicroClaw​

For new tools and capabilities:

1. Implement a new tool under src/tools/
2. Register it via ToolRegistry
3. Keep schemas explicit and docs generated from source
4. Reuse process_with_agent rather than adding platform-specific loops

This keeps the runtime coherent as features scale.

Final Take​

MicroClaw is best understood as a Rust agent runtime:

• Multi-channel adapters
• Provider abstraction
• Unified agent loop
• Durable sessions
• Layered memory with quality + reflection
• Production observability

That combination makes it a practical foundation for long-running, tool-using AI assistants.

1. Minimal and isolation-first
2. Broad platform with high feature surface
3. Balanced runtime with practical built-ins

This comparison is updated using publicly available docs/repos as of February 14, 2026.

TL;DR​

• NanoClaw: best when minimal code surface and container isolation are the top priorities.
• OpenClaw: best when you need wide channel/platform coverage with control-plane breadth.
• MicroClaw: best when you want a practical middle path with durable state and maintainable complexity.

At a Glance (Updated)​

Notable Public Signals (as of 2026-02-14)​

• NanoClaw README now foregrounds Agent Swarms and keeps a strong skill-first philosophy.
• OpenClaw README/docs continue expanding multi-channel, node, voice, and canvas workflows.
• MicroClaw remains focused on the mid-complexity runtime space: robust agent loop, durable state, and practical operational features.

Choosing by Use Case​

Choose NanoClaw if​

• You want the smallest understandable base and plan to customize by code transformation skills.
• You prioritize container-isolation defaults over broad built-in surfaces.

Choose OpenClaw if​

• You want the widest integrated platform: many channels, nodes, voice, canvas, and gateway tooling.
• You accept higher operational and configuration complexity for that breadth.

Choose MicroClaw if​

• Telegram-centric workflows are your immediate priority.
• You want strong session continuity, memory quality, tool orchestration, and scheduler support without adopting the largest platform footprint.

Final Take​

This is not a winner-take-all ranking. It is a complexity-placement decision:

• NanoClaw: complexity pushed into fork customization
• OpenClaw: complexity pushed into platform breadth
• MicroClaw: complexity concentrated on high-frequency runtime features

Pick the one that matches your operations budget and workflow style.

References​

• NanoClaw: https://github.com/qwibitai/nanoclaw
• NanoClaw README: https://raw.githubusercontent.com/qwibitai/nanoclaw/main/README.md
• OpenClaw: https://github.com/openclaw/openclaw
• OpenClaw Docs: https://docs.openclaw.ai
• MicroClaw: https://github.com/microclaw/microclaw
• MicroClaw Docs: https://microclaw.org/docs/overview

It can run shell and file tools, browse the web, schedule jobs, and persist memory/session state so multi-step work can continue across turns.

2026-02-14 Update Snapshot​

This post was refreshed on February 14, 2026 to match the current codebase and docs.

Current shape:

• Shared agent loop with iterative tool_use / tool_result execution
• Channel adapters for Telegram, Discord, and Web API surfaces
• Provider abstraction for Anthropic + OpenAI-compatible endpoints
• Durable session resume with context compaction
• Layered memory: file memory (AGENTS.md) + structured SQLite memory
• Scheduler + memory reflection background jobs
• Usage and memory-observability endpoints for operations

Why This Runtime Exists​

Most chat bots still behave like single-turn wrappers:

1. Receive text
2. Produce text
3. Lose execution context

MicroClaw is built for a different loop:

1. Interpret an incoming task
2. Decide when tools are needed
3. Execute tools and read outputs
4. Iterate until done
5. Persist state for continuation

That makes it suitable for long-running workflows instead of one-shot Q&A.

Core Capabilities​

• Chat-native tool execution (bash, file ops, search/fetch, scheduler, memory)
• Full session resume including prior tool interaction context
• Context compaction for long-running conversations
• Global and per-chat memory via AGENTS.md
• Structured memory records in SQLite for queryable recall
• One-shot and cron-style scheduled runs
• Sub-agent delegation with reduced tool permissions

Runtime Architecture​

MicroClaw keeps one shared execution core and separates channel concerns into adapters.

• Adapters: Telegram / Discord / Web handle input-output constraints
• Engine: shared reasoning and tool loop
• Persistence: messages, sessions, tasks, memories, observability
• Background workers: scheduler and memory reflector

This keeps behavior consistent while allowing channels/providers to evolve independently.

Why Rust​

Rust is used here for operational reliability, not novelty:

• Explicit concurrency with Tokio for long-lived processes
• Predictable shared state boundaries
• Strong typing for tool/message/state protocols
• Single-binary deployment for simpler operations

Design Principles​

• execution-first: useful assistants should complete tasks, not only chat
• state-is-a-feature: session and memory quality are first-class
• small-core-practical-edges: keep core loop clear, add high-frequency features
• layered-safety: tool-level checks + chat access controls + deployment hardening
• composable-growth: evolve through tools and skills, avoid loop fragmentation

Real Workflow Examples​

• "Scan this repo for breaking changes and draft release notes."
• "Weekdays 9am: send me an AI news briefing from selected sources."
• "Read these logs, identify likely root causes, and propose fixes."
• "Remember my response style preference and apply it in future sessions."

Current Priorities​

1. Stronger default boundaries for high-risk tools
2. Better cross-channel behavior consistency
3. Clearer skill/tool boundary to reduce misuse
4. Better failure observability for sessions/scheduler/tools

References​

• MicroClaw repository: https://github.com/microclaw/microclaw
• Overview docs: https://microclaw.org/docs/overview
• Architecture docs: https://microclaw.org/docs/architecture
• Tools docs: https://microclaw.org/docs/tools