How I Went From Reading the Code to Shipping 21 Contributions in HKUDS/nanobot

I didn't plan to become a regular contributor to nanobot. I was exploring AI agent frameworks, stumbled on the HKUDS repository, and did what most developers do I read the code, found something that looked off, and thought I could fix that.

Two months later: 21 contributions, 11 pull requests, and a significantly deeper understanding of what it actually takes to build reliable AI agents.

This is that story.

Starting Small: A Validation Bug Nobody Had Filed

My first PR was straightforward almost embarrassingly so. The tool parameter validation in nanobot would crash if it received a non-dict input. There was no guard, no graceful error, just a raw exception that would bubble up and break the agent's execution flow.

I added the guard. I wrote the tests. PR #28 — Validate tool params and add tests got merged.

It wasn't glamorous. But it taught me the first rule of contributing to a live codebase: the most valuable fixes are often the unglamorous ones. The ones that prevent silent failures. The ones that no one notices until they're gone.

Going Deeper: Safety, Security, and the Plumbing Nobody Talks About

Once I had a feel for the codebase, I started looking at the harder problems.

The exec tool had no safety guard. It would run commands without sufficient constraints a real problem in an agentic context where tools can chain together in unexpected ways. PR #30 hardened that.

The ReadFileTool had no size limit. Feed it a large enough file and you'd hit an OOM error. Not a hypothetical this is the kind of thing that kills a long-running agent job in production. PR #1511 fixed it with a configurable size cap.

The CronTool would crash on invalid ISO datetime strings instead of failing gracefully. PR #1508 added proper error handling so a bad timestamp doesn't take down the whole workflow.

Each of these fixes followed the same pattern: find the assumption the code was making, find the case where that assumption breaks, add a defensive layer. It sounds simple. It's actually a discipline.

The One That Mattered Most: Secrets in Tool Output

Of everything I've shipped on nanobot, PR #1513 is the one I'm most serious about.

The issue: tool outputs things like API responses, command results, environment reads could contain secrets. API keys. Tokens. Credentials. And those outputs were being passed around the agent's context without any sanitisation.

In an agentic system, that's not just a bug. It's a potential data exfiltration vector. If the agent's output gets logged, stored, or sent to another model, you've just leaked a secret.

The PR adds secret redaction to tool output before it touches the rest of the pipeline. It's still open for review, and I'm genuinely proud of the thinking behind it because it's the kind of problem that only becomes obvious when you start thinking about AI agents not as demos, but as systems running in production with real credentials.

Session Scoping: The Statefulness Problem

One of the more architecturally interesting contributions was PR #713 scoping session storage to the workspace, with a legacy fallback.

The problem was subtle: sessions weren't isolated per workspace. In a multi-project or multi-user context, session state could bleed across contexts. The fix required understanding how nanobot manages state, what "workspace" means in its model, and how to introduce scoping without breaking existing behaviour for users on the old path.

The legacy fallback was the hard part. You can't just change how state is keyed and ship it you break everyone's existing sessions. The solution was a migration path: check for workspace-scoped storage first, fall back to the legacy key if not found. Clean, backward-compatible, and invisible to users who don't know it's there.

That PR taught me more about thoughtful system design than almost anything I've worked on.

What I've Actually Learned

Eleven PRs in, here's what contributing to a real AI agent framework has taught me that I couldn't have learned from tutorials:

1. Agents fail differently than regular software. The failure modes are non-linear. A bad datetime string three tools deep can crash a workflow that started hours ago. Defensive programming isn't optional it's load-bearing.

2. Security in agentic systems is underspecified. Most of the AI agent literature talks about capabilities. Very little of it talks about what happens when an agent with tool access handles secrets. That gap is real, and it's going to matter more as these systems move into production.

3. Backward compatibility is respect. Every time I've added a fallback or a migration path, it's because real users have existing data and existing workflows. Breaking them is easy. Preserving them while still moving forward is craft.

4. Open source is still the best way to grow. Reading code is fine. Writing code that gets reviewed by maintainers of a production codebase that's a different education entirely.

What's Next

I've got two open PRs I'm actively working on. One is continuing the session history work (persisting tool-call events so agent runs are fully auditable). The other is the secret redaction PR watching that review closely.

If you're building with AI agents, nanobot is worth exploring: github.com/HKUDS/nanobot.

And if you're thinking about contributing to open source but haven't started find the unglamorous bug. Fix it. Write the test. That's how it begins.