Nanoscrypt

Inspiration

Modern AI agents face what recent research (EvolveTool-Bench) calls the Verification-vs.-Conformance Gap: a generated command can exit with code 0 and still return a wrong result, or improve one task family while breaking another. At the same time, static hand-coded toolsets bloat context windows and crash when external APIs shift, while naive tool caching promotes brittle code without proving that the tool actually caused better outcomes.

We built Nanoscrypt to close both gaps giving agents an autonomous engine to synthesize, verify, and self-heal Python tools on the fly, backed by a version-scoped lifecycle state machine that prevents broken or outdated tool versions from corrupting production workflows.

What it does

Nanoscrypt turns natural language into verified, persistent, and empirically governed Python software:

• On-Demand Tool Synthesis & 11-Stage AST Gate: Dynamically plans and writes typed Python tools (enforcing a mandatory def run(...) entry point), inspecting syntax, type contracts, cyclomatic complexity, and AST security before a single byte of code executes.
• Self-Healing Loop with Context Compression: Dispatches verified code into isolated Nebius Sandboxes streaming live stdout/stderr via Server-Sent Events (SSE). If a runtime edge case fails, Headroom AI (compressor.py) shrinks stack traces over 300 characters while our diagnostic repair loop autonomously patches the tool across versions (v_1 -> v_2 -> v_3) .
• Zero-Token Fast Path : Commits verified tools into an immutable SQLite registry with SHA-256 content hashes, allowing recurring tasks to bypass the LLM entirely and execute using 0 LLM tokens.
• Version-Scoped Lifecycle Governance: Using decide_lifecycle_state in core/tool_lifecycle.py, Nanoscrypt governs each tool version (tool_id, version) based on real task outcomes:
  • Candidate Shared: Requires (>= 5) outcomes across (>= 3) distinct non-empty task keys with a helpful rating fraction (>= 0.8).
  • Quarantined: Automatically isolates a tool after (\ge 3) harmful outcomes across (>= 2) distinct task keys.
  • Needs Improvement: Triggered when a shared tool logs (>= 2) harmful outcomes within its latest 5 executions, flagging it for self-healing repair.

How we built it

• NVIDIA & Nebius Inference Router (litellm_provider.py): Powered by NVIDIA GPUs on Nebius Token Factory (https://api.tokenfactory.nebius.com/v1), our router pairs NVIDIA Nemotron, Qwen2.5-Coder-32B-Instruct, Llama-3.3-70B-Instruct, DeepSeek-R1, and GLM-5.2 with strict credential isolation (_inject_llm_credentials()) and exponential backoff failover (_execute_with_retry()).
• Version-Isolated SQLite Registry (DBToolVersionLifecycle): Keyed by (tool_id, version) so outcome aggregation, lifecycle transitions, and current_version shared retrieval are strictly version-scoped.
• Enterprise Interfaces & Memory: Built with an interactive Rich CLI/REPL (featuring real-time /tokens and /cost slash commands), MemMachine semantic memory, human-in-the-loop security approval gates, and a FastAPI REST suite.

Challenges we ran into

• The Version-Overwrite Defect: During our implementation audit, we discovered a subtle race condition: while Nanoscrypt queried outcomes by version, it stored lifecycle state in DBToolLifecycle keyed only by tool_id. If an agent registered a repaired version (v_2), delayed telemetry arriving from an older execution of (v_1) could recompute (v_1)'s evidence and overwrite (v_2)'s active state! We solved this by engineering DBToolVersionLifecycle with conservative legacy migration, enforcing strict non-interference across versions.
• Reasoning Token Truncation vs. Strict AST Contracts: Heavy reasoning models occasionally burned thousands of internal thinking tokens and hit output limits before closing their Python code block causing the AST gate to reject the truncated file with [entry_point] Tool missing mandatory 'run(...)' entry point function. Routing code emission to direct instruction/coder models on Nebius and enforcing strict signature contracts eliminated truncation.

Accomplishments that we're proud of

• Proving the Version-State Isolation Invariant: Mathematically modeled and empirically verified that delayed or noisy feedback targeting tool version (v_1) is guaranteed never to corrupt, regress, or alter the lifecycle state of active version v_2), solving a critical state-leakage vulnerability in autonomous tool registries.

• 11-Stage Static AST Guardrails & Autonomous Self-Healing: Engineered a sub-10ms pre-execution compiler pipeline that blocks unsafe bytecode (eval, exec) and enforces strict type contracts, coupled with a progressive diagnostic repair loop that auto-patches syntax, import, and runtime exceptions without human intervention.

• Sub-200ms Zero-Token Execution ($0.00 Cost): Built an immutable, SHA-256 verified SQLite registry that completely bypasses LLM synthesis on recurring tasks slashing execution latency down to 70–182 ms while driving token consumption and API spend down to exactly $0.00.

What we learned

We learned that process success (exit code 0) is not evidence of tool conformance, and that fixed-threshold feedback labels (helpful, neutral, harmful) are only the first step toward safe autonomous tool libraries. To truly prove causal tool value across shifting environments and compositions, lifecycle engines must evaluate paired counterfactual incremental utility:

Δ_v(x) = U(x | tool version v available) - U(x | tool version v withheld)

where \(U\) captures externally verified correctness, latency, execution cost, and risk.

What's next for Nanoscrypt

• Paired Counterfactual Evaluation Benchmark: Running our preregistered sequential benchmark across structured data conversion, numerical computation, and file transformation to compare version-isolated lifecycle control against EvolveTool-Bench, Ratchet, and LOTS baselines.
• Uncertainty & Abstention Gates: Adding confidence intervals and change-point drift detection so the registry can explicitly Abstain and request human review when evidence is sparse or contradictory.
• Environment & Dependency Fingerprinting: Scoping lifecycle evidence not just by (tool_id, version) , but also by dependency hashes, runtime manifests, and verifier versions.

Built With

• fastapi
• headroom-ai
• memmachine
• nebius-sandbox
• nebius-token-factory
• python
• python-ast
• qwen2.5-coder
• sqlite
• tavily-api