One workspace, many models: why I built Workunit

This is the first post on the Workunit blog, so it felt right to start with the reason Workunit exists in the first place. Not a pitch. The actual path I walked to get here.

I started building Workunit in late August 2025. The first commit lives in the repo if you're curious, timestamped August 24th. What pushed me to open a new project that weekend was a feeling I'd been having for months: my AI tooling was getting better, and my workflow around it was getting worse.

Different models, different strengths

I was working across a handful of small projects at the time, jumping between Claude, Codex, and Gemini depending on what I needed. After enough back and forth, a pattern emerged that matched my own taste.

That split worked. The problem was everything around it. Every time I switched models, I had to re-explain the project, the constraints, what I'd already tried, and where I was in the task. I started keeping markdown files next to my code to paste into each session. Within a few weeks the markdown files were their own mess. I'd have project.md, decisions.md, notes.md, and half of them were out of date.

The idea: one workspace all the models can read and write to

I also had a long-standing itch to build a project management tool I actually enjoyed using. Most of them feel too heavy for the way I work, which is usually solo or on small teams, with a lot of context living in my head. So I combined the two itches. A project management tool I'd want to use, with the AI models treated as first-class collaborators that can read from it and write back to it.

The shape that came out of this is what I now call a workunit. It's a single place that captures everything about a piece of work: the problem I'm solving, what success looks like, the tasks it breaks down into, the assets it touches, and the reasoning that accumulates along the way. Once that context lives in one place, switching between models stops being a tax. You point every model at the same workunit, and they all start from the same understanding.

Context atoms: giving agents a place to write to themselves

This is the part I'm most attached to. The markdown files I'd been keeping were mostly my own notes, but what I actually wanted was for the agents themselves to leave a trail. When Claude makes a decision halfway through a task, I want that decision preserved, so that when I come back tomorrow with Codex, it can see the reasoning and build on it instead of undoing it.

So I built context atoms. Every workunit has a timeline of small, typed records that anyone, human or agent, can add to. Each atom is one of five types:

Agents read the atoms when they start work, and they can write new ones when they finish. The result is a living trail of reasoning that survives the chat window. It's the part of Workunit I reach for every day.

MCP made the whole thing click

None of this would matter without a clean way to plug the agents in. MCP, the Model Context Protocol, turned out to be the missing piece. Workunit exposes an MCP server, and any compatible client can connect with one command.

claude mcp add --transport http workunit https://workunit.app/mcp

Once it's connected, an agent can read a workunit, update task status, save a context atom, link an asset, or pull the latest state. I run this setup across Claude Code, Codex, and Gemini every day. The muscle I've built is assigning the right model to the right slice of the work. Codex owns the UI. Claude owns the code and the copy. Gemini handles the tricky review passes. None of them needs a briefing from me. They read the workunit and get to work.

A collaboration tool that happens to work with AI

I want to be clear about what Workunit is and isn't. It's not an AI product that bolted on some project management. It's a project management tool first, built for small teams and solo builders, which also happens to treat AI models as participants. The humans using it get a calm, focused workspace. The AI models using it get structured context. The two sides meet in the middle on the same workunit.

If you want to go deeper, the guides are the place to start. Quick Start walks through creating your first workunit end to end. Core Concepts explains how projects, workunits, tasks, assets, and atoms fit together. MCP Integration covers connecting Claude, Codex, Gemini, and other clients.