Why we built OpenKit, and why we stopped

At the start of this year we had a problem most teams didn’t have yet. We were running several coding agents at once, on the same projects, and nothing we could find was built for that.

So we built something. It’s called OpenKit, it’s open source, and for a few months it was how we ran our agents. Then we stopped developing it. Both decisions were right, and the reasons say a lot about how we work.

The moment we started aiming higher

Claude Opus 4.5 came out on November 24, 2025. Anthropic’s announcement called it state-of-the-art on tests of real-world software engineering, and noted that it reached similar or better results than its predecessors with dramatically fewer tokens. Benchmarks aside, what we noticed was simpler: agents could now hold a task for much longer without drifting, and the code they produced held up in review far more often.

That changed the question we were asking. It was no longer “can an agent help with this ticket?” but “how many agents can we keep busy at once, and what has to exist around them for that to be safe?” That’s when we started aiming for the moon.

The gap

Running one agent in one terminal is easy. Running five against the same repository is not. They fight over the same checkout. Their dev servers all try to bind the same ports. Each one needs the same tools, credentials and instructions configured separately. And someone has to keep track of which agent is working on which issue.

We looked for tools that handled this. There weren’t many, and the few we found weren’t actively maintained. Agent orchestration was a problem very few people were working on yet, and we didn’t want to bet our day-to-day on a project that had already gone quiet.

What we built

We started building OpenKit in mid-January 2026 and made it public on GitHub a month later as “the platform for your agents”: a CLI, a local server, a web UI and a desktop app, with a small mobile companion for pairing. Its premise was flexibility. Rather than enforcing one workflow, it gave you the pieces to design your own, because nobody, us included, knew yet what the right workflow was.

The core was a worktree manager. Every task got its own git worktree, created straight from a Jira, Linear or GitHub issue, so agents never shared a checkout. Around it:

Port offsetting. Running the same dev server in five worktrees means five processes asking for the same port. OpenKit discovered which ports a project used, then shifted them per worktree at runtime: a Node.js hook patched socket calls, and a native library intercepted bind() and connect() at the libc level so Python, Ruby, Java and Go worked too. No application changes needed.
One registry for agent tooling. MCP servers, skills and plugins were defined once and deployed to whichever agents you used: Claude Code, Codex, Gemini CLI, Cursor, VS Code.
Hooks around agent work. Checks, prompts and skills that ran before an agent started a task, after it finished, when a worktree was created or removed, or when the agent judged a natural-language condition was met.
Terminals, activity and diffs in one place. Agent sessions in the browser, a log of what each one did, a diff viewer per worktree, and a performance page showing what every worktree was costing the machine.

Between going public and late March it shipped 66 releases. We used it every day.

What we learned

Building it taught us what actually mattered, and most of it wasn’t the platform.

Isolation mattered: one task, one worktree, never a shared checkout. Gates mattered: checks that run at fixed points and don’t take an agent’s word for it. Context mattered most of all. An agent does good work when it can find the rules, the decisions and the background on its own, and poor work when that knowledge lives in someone’s head or in a settings screen.

The project’s own history shows the shift starting. In March we removed OpenKit’s own MCP server and made skills, plain instruction files that agents load on demand, the only way it exposed itself to agents. A few days later we replaced a generated task file with a single CLI command that printed an issue’s full context on request. Each time, the simpler, more text-shaped option worked better.

Why we stepped back

A few months in, we had to admit something. The models were improving so fast that a lot of what OpenKit did by hand, they could now do themselves, given the right instructions and the right commands. Every release made the scaffolding a little less necessary.

A platform puts a layer between the agent and the work. That layer has to be learned, configured and kept in sync with agents that change every few weeks. Plain text and plain commands don’t have that problem. A capable agent can read a document, follow a rule and run a script without anything in the middle.

So we concluded that the best orchestration, for now, is plain agents, good documentation, skills and tooling, plus a chat client our agent sessions are driven from, on a phone or a laptop. Everything else is overhead.

What we run today

Everything OpenKit taught us survives, in a simpler form:

Worktrees come from one command that branches from a fresh fetch, sets up env files and dependencies, and opens the PR when the work is done.
Gates are tasks in each repository that run on our own boxes at push and merge (the details are in When CI can’t keep up with your agents).
Context is rule files and docs, with exactly one home per rule: one file of cross-project rules loaded into every session, plus whatever is specific to each repository.
Skills cover recurring jobs: starting a session, serving a dev stack, picking up an issue, cleaning up stale worktrees.
Sessions are long-lived and supervised, so work keeps moving overnight, and whoever owns a decision can make it from a phone, wherever they happen to be.

There’s no app in the middle. When a model gets better, our setup gets better the same day, without anything to upgrade. How an agent-run dev shop actually works describes a normal day.

What it means for you

Two things, if you’re thinking of working with us.

We build ahead of the curve. We were solving agent orchestration while very few people were, and we built real, public software to do it. The problems you’ll meet when you put agents on your codebase are ones we’ve already met.

And we retire our own tools when something simpler wins. OpenKit was a lot of work, and we still stepped away from it because a lighter approach worked better. We’ll make the same call on your project: the right answer over the one we’re attached to.

OpenKit is still public. If you’re curious what agent orchestration looked like before the models caught up, the code and its history are there to read.