Notes from Shipping 28 Open-Source Projects in One Year

Twelve months ago the neul-labs org was empty. Today it holds 28 public, MIT-licensed projects spanning agent runtimes, Rust accelerators for Python AI libraries, developer tooling, build systems, network utilities, and compliance scaffolding. None of this was the plan in January. The plan was “ship one or two Rust accelerators for LiteLLM and LangGraph and see what happens.” The portfolio is what happened.

This is a debrief, not a victory lap. We have not solved agents. We have built a useful set of primitives, and the act of building them has changed our view of where the field is heading. The themes below are the ones the portfolio actually surfaced — not the ones we set out to prove.

What we shipped, in one paragraph

Eight categories, twenty-eight repos:

• Performance Accelerators — fast-litellm, fast-langgraph, fast-crewai, fast-axolotl. Rust + PyO3 drop-ins for popular Python AI libs.
• Agent Infrastructure — brat, fastagentic, fastworker, m9m, ringlet, ormai, mcp-pay, memorg.
• Agent Runtime & Workspaces — agentvfs, openclawOS, openclawMU, openclaw-rs.
• Developer Tools — rjest, rpytest, gity, grite.
• Build & Release — rninja, stout, stkd.
• Network & Data — recurl, rewget, stratafs.
• Compliance & Governance — regulus.
• Personal AI — ukkin.

Everything has a marketing site at <slug>.neullabs.com and docs at docs.neullabs.com/<slug>/. Everything is MIT.

The remainder of this post is what the shape of that portfolio taught us.

Theme 1: the agent stack is missing primitives more than it is missing optimisations

We started with the accelerator thesis: take libraries that already won developer adoption — LiteLLM, LangGraph, CrewAI — and replace their hot paths in Rust. That thesis is still correct. The README for fast-axolotl cites 77× faster streaming data loading versus HuggingFace datasets on a 50,000-row dataset; the fast-langgraph work targets the checkpoint serialization layer that we covered in our earlier benchmark post. Drop-in Rust acceleration is a real lever.

But the moment we tried to use these accelerated libraries inside our own agents, we kept hitting absences. Where was the workspace boundary? Where was the durable memory? Where was the payment surface? Where was the policy-enforced ORM? These weren’t optimisation problems. The primitives didn’t exist.

So a year that was supposed to be about acceleration became a year of building runtime pieces:

• agentvfs gives agents isolated workspace vaults with fork/rollback. Its README describes it as “the proxy boundary [that] mediates between your agent and the workspace” — agents operate against mounted forked workspaces, not the host filesystem, with structured JSON deltas reported back.
• memorg is explicit about the problem it exists for: “LLMs forget. Context windows fill up. Important details get lost.” It ships SQLite-backed sessions and conversations plus pluggable vector storage.
• ormai is the answer to “what if the agent runs wild queries?” — its README enumerates the four scary scenarios (sensitive reads, runaway costs, no audit trail, no tenant isolation) and wraps SQLAlchemy/Prisma/Drizzle/TypeORM/Tortoise/Django/SQLModel/Peewee in a policy-enforced runtime so none of them can happen.
• mcp-pay added a rail-agnostic payment manifest to MCP. Its README is candid about the gap: the MCP Registry has discovery but no payment; x402 Bazaar requires payment before discovery; Tempo MPP is in-network only. mcp-pay sits at .well-known and works across all of them.

The lesson: the agent stack today looks a lot like the web stack circa 2005 — clear, exciting application patterns, but most of the load-bearing infrastructure still has to be invented. If you want a one-line summary of where we’ll spend 2026: more primitives, fewer optimisations.

Theme 2: drop-in compatibility scales adoption faster than novelty

Roughly two-thirds of the portfolio is some flavour of “drop-in replacement.” That’s not an accident; it’s an explicit design rule. We’ve written it up in more depth in “Drop-in compatibility as a design principle”, but the short version is: every time we asked a developer to change their config, their CLI, or their import statements, adoption stalled. Every time we promised to read their existing config and accept their existing flags, it moved.

The portfolio reflects this:

• rjest reads existing jest.config.* files unchanged and supports --watch, --coverage, --runInBand, --testNamePattern, --json, --machine. The README claims warm runs in roughly 14ms, ~100× faster than standard Jest. We will believe the number when you run the benchmark on your machine — but the design point holds either way: no config changes.
• rpytest keeps tests, fixtures and plugins completely untouched. The README’s headline metric is modest by accelerator standards (1.9× wall-clock on a 480-test suite) and that’s the right number — the larger win is the 5.8× drop in CLI memory thanks to the daemon.
• rninja is binary-compatible with Ninja and doesn’t require changes to your build files.
• recurl and rewget keep the exact same CLI surface as curl and wget, and silently escalate to TLS-impersonating or browser-rendered fetches when blocked.
• stout is a Homebrew-compatible package manager that drops Ruby and uses a pre-computed SQLite index with FTS5 full-text search.
• The fast-* accelerators preserve the upstream Python APIs.

Drop-in compatibility is unglamorous. It requires reading other people’s source code carefully, matching undocumented edge cases, and refusing to “improve” the surface. It also massively reduces the activation energy required to try your project. We will keep biasing toward it.

Theme 3: distribution beats deployment

A lot of the projects in the portfolio sit in adjacent developer ecosystems — Jest is a Node tool, pytest is Python, Ninja is C++, Homebrew is Ruby. We could not pick one package manager and call it a day. So we didn’t. The pattern that emerged is “publish wherever the user is already typing install commands”:

• rjest ships to npm (rjest-install), PyPI (rjest-install), Homebrew (neul-labs/tap) and crates.io.
• rpytest ships to PyPI, Homebrew, npm and crates.io.
• rninja ships to crates.io, npm (rninja-cli), PyPI (rninja-cli) and Homebrew.
• The accelerators ship as pip wheels with prebuilt binaries.

This is mostly a tooling problem and we will write up the release pipeline separately. The takeaway is that, in agent-adjacent infrastructure, you do not get to pick one distribution channel and ignore the others. The user’s existing habits decide which install command they will type.

What we thought would matter and didn’t (yet)

A few hypotheses that, a year in, look weaker than expected:

• A “platform” SaaS dashboard. We assumed at least one project would naturally pull demand toward a hosted product. So far, the gravitational center is still the open-source primitives. We’re not in a hurry to change that.
• Benchmarks as a marketing wedge. Numbers like “100×” or “700×” land well in posts but rarely show up in the questions developers actually ask. The questions are “does it read my existing config?” and “what happens if it crashes?” The accelerators that get the most pull are the ones whose READMEs answer those questions cleanly, not the ones with the biggest multiplier.
• A unified CLI. We shipped ringlet to manage every coding agent from one CLI, and it’s useful, but the broader idea of unifying all our tools behind a single binary turned out to be the wrong abstraction. Each tool has its own ecosystem-shaped entry point, and that’s fine.

What 2026 looks like

A smaller number of bigger commitments. The runtime pieces — agentvfs, brat, fastagentic, ormai, memorg, mcp-pay — are where most of our time will go. The accelerator cluster will keep pace with upstream LangGraph and LiteLLM releases but is unlikely to grow much in count. The dev-tools and build cluster will get release polish but no new lines. Regulus will get more attention as the EU AI Act bites.

If you want to follow along, the canonical index is the projects page. Every README in this post links back to its GitHub repo. The numbers we cite are the numbers from those READMEs — your mileage on your hardware will vary, which is exactly why we keep the benchmark scripts open.

Thanks for reading. We’re hiring contributors more than employees right now; the door is on every repo.