Skip to main content

The Distri shipping log: three months to a CLI you can actually ship

· 3 min read
Vivek Gudapuri
Building Distri in public

I have been building Distri in public, but the changelog was living in my head and in git history. That is not much use to anyone else. So here is the record, from the middle of April to the middle of July, framed the way I actually think about it: what problem each stretch of work was solving.

The full list is on the changelog page. This is the story behind it.

April: stop having three ways to do everything

The framework had grown a few overlapping paths for the same idea. Agents could talk to each other one way in-process and another way remotely. Bots and channels each had their own half-built plumbing. The first stretch of work was unification: one A2A service with in-process and remote dispatch behind the same interface, one bots list with real access modes and pairing, one gateway. Native Telegram and WhatsApp libraries replaced the hand-rolled bits. None of this is glamorous. It is the tax you pay before the next feature is cheap instead of expensive.

Mid-May: the open-source rearchitecture (v0.3.8, v0.3.9)

This is where Distri became something other people could build on without reading my mind. An MCP client pool and tool adapter let a Distri agent call remote MCP servers, with scope-based filtering so a tool is only reachable where it should be. A unified author workflow (push, checkout, search, install) gave the registry a real shape. Then authorization got typed and permission-based with a route catalog, OAuth moved onto the oauth2 crate with a proper provider catalog, and connections became user-scoped. The boring news underneath all of it: credentials are now separated end to end, which is the kind of thing you only notice when it is missing.

Mid-June: tracing you can read (v0.4.0)

An agent that you cannot see is an agent you cannot trust. The v0.4.0 work was tracing done properly: propagation and provenance, tags, span naming, CLI flags, and a Traces UI that was reworked so it renders fast instead of choking on a long run. Context compaction landed end to end at the same time, alongside a config cache so agent definitions do not reload on every call. I also fixed two deadlocks, which is the unromantic reality of concurrency.

July: make the CLI shippable (v0.4.4, v0.4.5)

By July the framework was solid enough that the question shifted from "does it work" to "can someone install it in one line and not care about the rest." So the CLI became buildable on its own, without the UI or server, with a Linux cross-compile path for publishing. Parallel tool execution and metadata-driven skill auto-load made runs faster. The Z.ai coding-plan provider joined the list. And a batch of workspace fixes made agents and templates visible and editable to every member of a workspace, not just whoever created them.

What is next

The honest gap at v0.4.5 is per-client token rate limiting, which was still spec-only. That is near the top of the list. If you want the terse version of any release, it is all in the changelog, and the code is open at github.com/distrihub/distri.