Nanobot
Nanobot proposes stable tool identities and finer recovery evidence without automatic replay
Two Nanobot proposals expose a session-scoped tool invocation identity and persist completed batches before the entire tool set finishes. The design keeps interrupted work distinguishable from completed results, but explicitly stops short of automatic replay or exactly-once external effects.
Nanobot opened two complementary runtime proposals on September 12 that make the small agent's recovery boundary more explicit. One supplies tool implementations with a stable identity for the logical invocation; the other checkpoints completed batches while the larger tool-call set is still running. Together they would give integrations a better account of what happened before a process stopped. They remain separate open changes, not a new transaction system. That narrowness is important: a deterministic identifier and a saved result improve evidence, but neither can retroactively prove what an external service did during a crash.
The facts
- The invocation-context proposal binds at the existing per-call execution boundary and exposes the provider's tool_call_id to tools and lifecycle hooks. - A deterministic invocation key is derived only when a stable session key exists; without that namespace, the key is intentionally unavailable. - Context is task-local for concurrent calls and is reset on success, exceptions, hook failures and cancellation. - The recovery proposal advances the existing awaiting_tools checkpoint after each completed execution batch instead of waiting for the full tool set. - Completed and pending calls must form strict, disjoint partitions; completed results are preserved while pending calls become interrupted results. - Neither proposal promises exactly-once external effects, and restart recovery remains fail-closed with explicit user confirmation rather than automatic tool replay.
Why it matters
For builders extending Nanobot, this is a move from anonymous function calls toward inspectable execution boundaries without giving up the project's small-runtime approach. The user consequence appears after interruption: a completed action should not be made indistinguishable from work that never finished. That reduces pressure to retry everything, but the remaining uncertainty still belongs in the interface. The current project README is context for this extensibility story, not evidence that these proposals have landed.
Current
Inspected on 2026-09-13. The Nanobot release baseline is v0.3.0 published 2026-07-25T08:08:47Z. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.
Evidence
Primary evidence: HKUDS/nanobot PR #5750 (https://github.com/HKUDS/nanobot/pull/5750). Supporting context: HKUDS/nanobot PR #5748 (https://github.com/HKUDS/nanobot/pull/5748); Nanobot — official product README (https://raw.githubusercontent.com/HKUDS/nanobot/main/README.md). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.
Operator take
An integration should use the proposed key as correlation input, not assume the framework has implemented idempotency for it. A remote API still needs its own acceptance and deduplication contract. Test concurrent calls, a stop after the first completed batch and a tool whose response is lost after the external action succeeds. The authors report focused execution and recovery tests, while also disclosing unrelated or order-sensitive failures in full local suites. Preserve that distinction in adoption decisions.
Caveat
Both source changes remain open. No new scheduler, task ledger, public configuration or provider-state synchronization is claimed. Saved results do not prove exactly-once side effects, and the invocation key is deliberately absent without stable session scope. Contributor test reports were inspected but not reproduced by this publication.
Both source changes remain open. No new scheduler, task ledger, public configuration or provider-state synchronization is claimed. Saved results do not prove exactly-once side effects, and the invocation key is deliberately absent without stable session scope. Contributor test reports were inspected but not reproduced by this publication.