Open Source
Close to 100 Apache-2.0 repositories, one noun and one domain each, assembled like legos into every product I ship. When someone asks how it works, the answer is a repo link, not a waitlist.
When people ask how any of this actually works, the answer is a repo link, not a waitlist.
That sentence only means something once you've watched the count behind it move. In March it was 32 open-source repositories, built to replace the SaaS my agents would otherwise depend on. Two weeks later it was 57. By mid-April it was pushing 60. By the end of April it was 70. The public GitHub org sits at 89 today, 81 of them public, and the npm count under @hasna/* is closing in on 100. Nobody planned a hundred-repo roadmap. What compounds that fast is not a plan, it is a rule: the second time an agent needs a capability, it becomes a function; the third time, it becomes its own package.
I call them building blocks for AGI, and the word building block is doing real work in that sentence, not decoration. A block only earns the name if it is small enough to reuse, boring enough to trust, and finished enough that nobody has to open it up to use it. Todos does task management and nothing else. Mementos does memory and nothing else. Secrets does secrets and nothing else. One noun, one domain, one package that owns it — machines, identities, conversations, brains, coders, testers, wallets, signatures, sandboxes, guardrails. A hundred of those is not a hundred products. It is a hundred verbs an agent can call without having to build the verb first.
Every block ships in the same shape on purpose: a CLI, an MCP server, an SDK, and often a small daemon or dashboard behind it. A parity test keeps the CLI and MCP command sets identical, because a capability the MCP server exposes and the CLI does not is a bug, not a design choice. Even the plumbing is standardized — MCP servers get sequential HTTP ports assigned per service, brains at 8801, machines at 8821, the markdown protocol server at 8822 — so an agent discovering the fleet does not have to guess where anything lives. Consistency at that level is what makes a hundred small things behave like one system instead of a hundred one-off tools with a hundred one-off interfaces.
The scale shows up in how work actually gets dispatched, not just in the repo count. One afternoon, a single delegation batch pushed abstraction work into fourteen different open-* repositories at once — loops, todos, dispatch, sessions, repos, secrets, shield, economy, machines, snapshots, knowledge, files, notes, mailery — each in its own tmux window, each running under its own subscription profile, purely so one account's rate limit could never gate fourteen repos' worth of parallel work. An independent verifier checked afterward, over SSH, that every pane was actually alive and every task actually landed, because a dispatch command returning success is not evidence anything happened. That is what building in legos actually looks like day to day: not one grand architecture diagram, but fourteen small, independently owned boxes moving at once without stepping on each other.
Some of the blocks are worth telling on their own, because the number attached to them makes the lego argument better than the metaphor does. Playwright MCP burns 13,700 tokens before an agent has done anything; Chrome DevTools MCP burns 17,000. So browser exists instead: 154 tools, four engines, native Bun.WebView in place of Chromium, 50 times less memory, twice the startup speed, one install covering every browser an agent might need to drive. Dispatch exists because tmux send-keys is flaky by default — the Enter often doesn't submit, long prompts get mangled — so it computes a delay from message length, pastes long text through tmux buffers, and confirms delivery by diffing the pane before and after, because dispatch does not assume success, it verifies. Swarm turns a goal into a task graph, fans it out across agents, and gates every result behind a frontier verifier that has to call an explicit approved tool before anything is accepted. Testers spawns cheap agents with headless browsers, generates one test scenario per button or link it finds in an app, and runs the resulting workflows across up to twelve sandboxes at once in deterministic batches.
Microservices is the block that makes the lego claim literal at the scale of a whole backend: 21 independent packages — auth, teams, billing, LLM routing, agents, memory, knowledge, guardrails, prompts, notify, files, audit, traces, flags, jobs — each with its own Postgres schema, its own HTTP API, its own MCP server, its own CLI. Install only the ones you need, run them embedded inside your app's process or standalone as their own services. A team that would normally spend a quarter standing up auth and billing and audit logging from scratch gets all three the same afternoon they run bun install, because someone already turned each one into a block instead of a bespoke integration.
Not every block looks like infrastructure. Identities gives both humans and AI agents an actual identity record — verified emails and phones, plus narrative documents like SOUL.md and PERSONALITY.md — and ships a deterministic roster of agents with canonical Greek and Roman names, each scoped to a role, only the externally-facing ones getting a public address at all. Open Markdown Protocol compresses an entire thesis about model economics into one line: smart LLM writes it, cheap LLM or regex executes it, structured markdown as the intermediate format one model hands to a cheaper one. Economy tracks what all of this costs across Claude, Codex, Gemini, and everything else, reconciling estimates against each vendor's actual billing and shipping as a CLI, an MCP server, a REST API, a web dashboard, and a native macOS menu bar app, because a cost tracker that requires opening a terminal to check a number has already failed at its one job.
More than fifty of the hundred blocks exist specifically to replace SaaS a normal team would otherwise rent. Conversations replaces the internal chat tool. Mementos replaces the wiki nobody keeps current. Files replaces the shared drive. Todos replaces the project tracker. None of them are toys built to prove a point — they are the substrate my own agents run on every day, which means every bug in them is a bug I feel within the hour, not a support ticket that reaches me eventually. That is the actual quality bar a building block has to clear: it has to be good enough that the person who built it depends on it too.
The lego framing is not a metaphor I apply after the fact, it is the literal instruction I gave the team rebuilding my own flagship product. Partway through that rebuild I told them to treat the open-source repositories as SDKs and use them to replace large parts of the app's own core architecture, exactly the way installing them from npm as a stranger would work — assembling the product out of blocks instead of rebuilding what a block already does. A hundred repositories only pay for themselves if the person who built them actually uses them as parts, instead of writing the hundred-and-first version of the same capability inside a monolith because reaching for the package felt like more setup than copying twenty lines.
Even the number itself gets checked rather than asserted. Close to 100 is not a round figure I repeat because it sounds good — it is what gh repo list actually returns against the public org, cross-checked against the npm registry separately, because a claim about your own primitives deserves the same evidence standard as any other claim an agent hands you. Saying a hundred repositories exist and being able to list them are two different sentences, and only the second one is worth publishing.
Naming every block after the domain it owns, rather than after a specific implementation, is what lets the count keep growing without the whole thing turning into a pile of abandoned experiments. A package named todos can be rewritten twice from the ground up and nobody downstream has to change how they call it, because the contract is the noun, not the code behind it on any given day. That durability is what a hundred small, independently replaceable parts buys you that one large, tightly coupled system never can: the freedom to gut and rebuild any single block without asking anyone else's permission first.
Compare that to how most of the industry hands out access to anything interesting right now. I've lost count of how many times a reply to some new tool has been some version of it says it's still waitlist only. A waitlist is a company telling you the product exists but you are not trusted with it yet, gated behind a form and a queue and someone else's judgment about when you deserve to see it. A repo link is the opposite transaction entirely: the whole thing, source included, available to install the moment you ask, with nothing standing between curiosity and the actual code except a package manager. I would rather ship something rough that anyone can clone today than something polished that requires an email and a wait.
That is also why the count matters more than any single package does. One good open-source tool proves you can build one good thing. A hundred small ones, all following the same four-surface shape, all named by the same one-noun-one-domain rule, all consumable the same way, prove something else: that the discipline generalizes, that it was never about one clever repo, and that whatever gets built next inherits the same shape for free instead of starting over. The lego architecture is not a hundred bets. It is one bet, replayed a hundred times, that composability beats cleverness once you are building at any real scale.
None of the hundred repositories are finished in the sense that a shipped product is finished. They keep changing, get renamed, get split apart when one block starts doing two jobs, get merged when two blocks turn out to be the same job wearing different names. That is fine. A building block is allowed to keep improving as long as its contract — the CLI verbs, the MCP tools, the package exports — stays stable enough that everything built on top of it does not have to know it changed underneath.
Ask me how the fleet of agents coordinates, how the loops stay durable across restarts, how a product gets built by agents that have never met each other in the same session. The honest answer to all three questions is the same ninety-something repositories, Apache 2.0, one npm install away. Not a demo. Not a deck. Not a waitlist. A repo link, and the rest is just reading the README.
A hundred building blocks is not a finish line, it is a pace. The number that matters is not where the count sits today, it is how few weeks it took to double the last time, and whether the same one-noun-one-domain discipline holds at the next order of magnitude as cleanly as it held at this one. Ask again in a year. The link will still be public, and there still will not be a waitlist.