We're all building the same agent orchestrator

For 2 months, I’ve been building an agent task orchestrator as a side project. Turns out, so has everyone else.

Everyone building the same idea is not news in the AI era. First, everyone was building a “chat with PDF” app. Then along came the “GPT wrappers”. Eventually along came AI meeting note takers, then last year was vibe-coding app builders.

Each wave followed the same arc. Dozens of independent teams converge on an almost identical product, differentiate on vibes, and a handful of winners emerge.

Fast forward, and now it’s agent orchestrators and agent sandbox startups.

How I ended up building the same thing as everyone else

In December, I vibe coded ccqueue: a queue-based task system where agents pull and execute atomic tasks until the queue is empty. Cool, but limited. So I built orca: a client-server approach more akin to traditional task management systems like Linear. Workspaces, projects, dependent tasks. Leases and heartbeats so agents couldn’t claim the same tasks. MCP.

This was also my first small taste of others building the same thing. Shortly after, overseer by @dmmulroy, dex by @zeeg and others popped up. Cool to see others had found similar solutions effective.

But I kept wanting more. What if tasks automatically spawned agents? What if I had a central view for watching all of them? How do I manage agents across multiple devices?

I started building my own app, Wanda. Again vibe coding, with oversight of some data modelling and tech choices but very hands off. Before long I had terminal instances, a view system for different focused and higher level views, DAG workflows, MCP, hacky docker pod spawning, and remote orchestration from my MacBook to my Mac Mini.

Early OrcaPods, an old version from before the rename to Wanda. This is not the current product, it is just where it started.

Tools like Conductor (by @charlieholtz and @jacksondecampos) already existed at this point, pioneering this space with strong UX. For me, my workflow lived in the terminal, so I needed something different.

Why does everyone land in the same place?

I think every single person who has built similar has gone through a version of what I described above. The convergence isn’t a coincidence, but doesn’t necessarily mean we’re seeing early indicators of new patterns.

1. Everyone is hitting the same friction using the same CLI tools, and feeling the same limitations. Claude Code, Codex and others are opinionated and not agnostic.
2. Existing tools don’t really solve this new paradigm well. Existing IDE’s were made for single-stream development.
3. We are still at a point with models where we want visibility and control. As models improve, this might reduce.
4. Claude Code has weird terms. Some are taking the risk implementing claude via ACP or Agents SDK, but terminals are safe for now.
5. Building with LLM’s makes everything seem easy. Code is probably poor but it’s simple to do and works so things just ship.

Everyone is walking across the same patch of grass, creating a new path. I don’t think this means that we’re finding the “final form” or “future of software development”. I think more-so, 30 people/teams have all found their own better way to manage the current state of software development.

• “I’m already using worktrees, let’s connect that to the instance.”
• “I’d like to see the diffs.”
• “I’m running commands/scripts constantly, I’m going to add a way to manage them.”
• “I don’t want to switch to my browser.”

Next thing you know, you’ve built git integrations, diff views, runnable commands and added a browser. Repeat this a handful of times and we’ve all landed on a very similar setup.

The shared feature set

I think there’s a foundation that everyone converges on, then sprinkles their own taste on top. Regardless of whether they’re open source, VC funded, or an incumbent like Cursor or JetBrains.

If you want to join the party and build your own, they all come down to roughly this:

• Environment & execution: Local and remote instances/SSH, Docker, sandboxing, terminals, runnable scripts/commands per instance.

• Agent control: Agent integrations (via PTY or UI), task management, MCP for the whole app, a view system to switch between single-thread and multi-agent views.

• Developer workflow: Workspaces, worktrees and git integration, built-in code editor, diff/review mode, knowledge centralisation (skills, rules).

• Extended features: Mobile app, embedded browser with interactive highlighting.

Wanda latest clips. Recorded shortly after writing this blog post.

Most of this is trivial with agents doing the work. The hard part is strong foundations, followed by novel features and customizability.

What’s still missing

At this point, I am not in the game of building this for other users. Once another solution fits my workflow, I’ll jump ship immediately.

• Plugin/extension system. It’s a core concept of traditional IDE’s. Clear way to develop a rich community.

• View system, and better high level views. Sidebar with 1 chat, or terminal tabs, is not our only option. Wanda has canvas and carousel views. This is basic, but it’s a start.

• Task management. I don’t want to connect my Linear. I want to set up my own task list that isn’t being broadcast to my team.

• Remove the need for a standalone code editor. Built in code reviews is a good start, but need more of this.

• Attempts at novel or futuristic workflows.

I’m guilty of not experimenting enough myself with Wanda but did try ideas like views and DAG workflows (later removed).

Looking ahead

Everyone has a preferred way of working, so there doesn’t have to be 1 winner here. History has shown us that developers will pick what suits their workflow best. VSCode vs JetBrains vs Neovim. Power vs simplicity. Extensibility vs opinionated. Pretty UI vs embedded in terminal.

Cursor are by far the furthest ahead with most of these features (and quality), but their business interests align differently (a non-agnostic tool). I hope that the labs don’t lock us down into a single workstream (love you guys, but looking at you, Anthropic).

A year ago, building these apps would’ve been possible, but much more time intensive and since Claude Code was so early, we couldn’t have envisioned the need. If models improve to the same degree, we could see a completely different paradigm rendering this useless. Who really knows.

Where that leaves me, and Wanda

For now, I’ll continue adding things to Wanda for my own workflow, until one of these other solutions finally convinces me. I have other stuff I want to build instead.

Good luck to the rest of you trying to win this space. I would love to see some of these solutions experiment more, after mastering the foundations.

Since so far, we all truly have just built the same thing.