Skip to content

The agent platform I kept rebuilding

Published: at 09:00 AM

Between August 2024 and April 2025 I started the same project five times. It had a different name each time, and none of them shipped.

Looking at the repositories side by side now, the pattern is embarrassingly clear. It is also the most useful thing I’ve learned about building software for agents.

Five starts

Agent Studio, August 2024. A FastAPI backend for creating and running agents across OpenAI, Anthropic and Ollama, with a frontend. It stopped at a commit called “wip on chat api”.

Super Agent Factory, December 2024. The same idea with knowledge bases, pgvector and LangChain. Nine commits.

Super Agent Studio, Christmas Day 2024. Five commits in one day: auth, Redis, “removed frontend”, “re-initialised frontend”. Then nothing.

Meta Agent, February 2025. One commit and a long planning document for an orchestrator that delegates to specialised agents.

Super Agent and Meta Agent Platform, March and April 2025. A Tauri desktop app that talked to five model providers, with a release pipeline for three operating systems. Then a full orchestration platform: a documentation site, a demo UI, a backend with Keycloak and Postgres, an agent registry that spoke the A2A protocol, human-in-the-loop tasks and a workflow builder. 118 commits in twelve days. The last one was on 28 April.

Every restart was bigger than the one before. Every one of them was the platform: the place where you define agents, chat with them, run them, give them tools, schedule their work and watch what they do. And every one stalled at the point where all of those things had to fit together.

What was actually wrong

I didn’t see it then, but each attempt fused several jobs that have different owners and different lifetimes:

Put them in one product and every decision drags the others along. Changing how agents run means changing the chat UI. Adding approvals means touching the runtime. The scope grows with every restart because the boundaries never get drawn.

The applied version got it right first

In August 2025 I started on what became Superprocess (it was called Periscope for its first seven months). The day-one choices were BPMN to describe the process, Temporal to run it durably, and typed agents as steps inside it.

That split the problem without my noticing. The process owns the work. Temporal owns execution. An agent is a step that takes typed input and returns typed output. Nobody has to design “the platform” because each part has one job.

Then I made the same mistake again

In December 2025 I built AgentPod. It was a cross-platform app for running a coding agent in a Docker sandbox, with a desktop and mobile client, and OpenCode wired in as the agent. It reached v0.0.5 on the first of January and then sat untouched for five and a half months.

When I came back to it in June, the redesign spec opened with the diagnosis: it had “fused two things — a rich cross-platform client and a Docker sandbox substrate — and hard-wired OpenCode as the agent”. It was the old mistake at a smaller scale.

Meanwhile the world had moved on. I was running my own agents on laptops, a VPS and cloud sandboxes, under several different harnesses. No single agent and no single client was going to be the one.

June 20 and 21

On 20 June I started a new repository: a kanban board for agents. The next day I wrote the AgentPod redesign spec, and its key sentence was about the board’s neighbour: AgentPod “does not orchestrate work and does not chat”. Conversation would move to a separate chat client.

The board’s own founding document said the same thing from the other side:

Not an agent runtime. Superpipeline never executes the model, the tools, or the shell.

The board shipped its first release, “First Flight”, the next day. On 29 June I froze the old AgentPod as a git tag, v0.0.4-opencode, removed OpenCode and Tauri from the codebase, and let git history be the archive.

What I have now is not a platform. It is a few products that each own one thing:

In August I moved them into SuperJackfruitLabs and wrote down what they need to share. It isn’t a common codebase or a contract package. It is one identity for a run that follows the work from the card, to the agent, to the machine, to the conversation, to what it cost.

The rename this week

The board was called kaambaan until Wednesday. The rename plan listed three reasons: the name already meant something else, the pun was taken, and it broke the pattern of the other product names. And there was one reason to do it now rather than later:

This is a find-and-replace today.

That’s the whole lesson of the last two years in one line. Boundaries and names are cheap to fix before anyone depends on them, and painfully expensive afterwards. I spent nine months rebuilding one platform because I never drew the boundaries. Once I did, each piece became small enough to finish.


Previous Post
People retain authority
Next Post
Working with a team of agents