How Shuriken started: a tool we built for ourselves

We build software for clients and ourselves. No harness fit how heavily we use AI, so we built our own. Then a programmer asked: why don't we sell this?

FOR US FIRST beside a real screenshot of Shuriken with four chats on their own branches, under "How Shuriken started: a tool we built for ourselves"
Contents

Shuriken began as a harness our company built for itself, because none of the ones we tried fit how heavily we use AI. People ask who's behind it, and they should: you're trusting this tool with your accounts and your code.

We make software for a living#

For years our company has built software and websites for clients. Next to the client work we've always made products of our own. That's our day job, and it still is.

We're not a lab and we're not a startup that set out to build an AI tool. We're a team that ships software every week, for other people and for ourselves. That matters for what follows, because Shuriken was shaped by that kind of work: long days, several projects at once, deadlines that don't move.

AI crept into every day#

We started using AI in our daily work about two years ago, on small things at first: a function, a test, a second opinion on a tricky bug. It grew from there, and today coding agents are part of how almost everything here gets built.

And the more we used them, the more the tools around them got in the way.

No harness fit how we worked#

A harness is the software around a coding agent: where its chats live, which account it runs on, how you start it, follow it and answer it. (We wrote a longer explanation in What is an agent harness?)

Three nested layers. At the centre, the model. Around it, the agent loop, such as Claude Code or Codex, which gathers context, acts and verifies its work. Around that, the harness, which connects the agent to your accounts and limits, MCP tools and their sign-ins, the devices it runs on, and you: approvals, notifications and your phone. Harness runs the agent Agent loop Claude Code, Codex, Gemini CLI… gather context → act → verify → repeat Model Accountsand their limits Deviceswhere it runs ToolsMCPs and sign-ins Youapprovals, phone
The harness is the outer layer: your accounts, devices, tools and you, around the agent.

We tried a lot of them, more than we'd like to count. Some were good at one thing. None fit the way we worked, and the way we worked was heavy:

  • switching accounts: we had several, and a chat that ran out on one had to move to another by hand (log out, log in, paste the context back);
  • hitting limits, always in the middle of something and never at a convenient moment;
  • running many agents in parallel, a handful at a time across different projects rather than one chat;
  • working from anywhere: at the desk, on another computer, or away from the desk checking on an agent from a phone.

Every tool we tried handled one or two of these. None handled all of them together, and it was the combination that ate our time. The long rant about the account part is in We were tired of logging in and out of Claude.

So we built our own#

About seven months before our first build, we stopped looking and started building. Just for us: an internal harness that did what we needed, the way we needed it.

That wasn't a weekend hack. We put real time into it, next to our main projects, and kept putting time in, because a tool you use every day is never finished. When a provider changed something, we fixed it. When something annoyed us twice, we changed it. The people building it were the people using it, so nothing annoying survived for long.

The parts you'd recognise today started there. Chats moving by themselves to an account with room left, which became automatic source switching. Running many agents at once without them tripping over each other, which became parallel agents. Following everything from wherever we were.

Shuriken with four chats in the beacon project, two marked with a branch icon. The open chat asks to paginate the conversation list with a cursor, the agent is replying, and the composer reads Add to the queue.
Shuriken today: several chats in one project, each working on its own branch.

"Why don't we sell this?"#

About four months into building it, one of our programmers asked a simple question: why don't we sell this?

It clicked right away. We hadn't built this because we wanted a product. We'd built it because nothing out there fit, and we'd looked hard. If we had that problem, other people who use coding agents as much as we do had it too. There was a gap, and we had been quietly filling it for ourselves for months.

Rebuilding it for other people#

An internal tool can assume a lot. It can assume you know where every setting lives, because you put it there. It can assume your accounts, your computers and your habits. Strangers have none of that.

For about the next three months we reworked it heavily, asking one question of every screen: would someone who has never seen this understand it? Setup had to work without one of us sitting next to you. A name we'd picked among ourselves had to make sense to someone who wasn't there when we picked it. And what we'd learned the hard way, like keeping your accounts yours and your code on your own machines, had to be built in instead of remembered.

What came out of that is Shuriken.

Where we are now#

Shuriken isn't something we do next to our main work any more. A dedicated part of the company now works only on Shuriken: building it, fixing it, and using it every day on our own projects, the same way it started.

The first builds went out on 29 September 2026, to a small group first, because we'd rather find what breaks with a few people than with everyone. We're still working the way we started: use it hard every day, fix what annoys us, ship small changes often.

If you run more than one coding agent, or more than one account, we built this for people like you, because we're people like you.

Shuriken is open to everyone now. What happened next is in Shuriken is officially launched, in beta, and you can try it today.

Frequently asked questions

Who makes Shuriken?

A software company that has built client software, websites and its own products for years. Shuriken started as its internal harness, and a dedicated part of the company now works only on Shuriken.

Why was Shuriken built?

No harness we tried fit heavy daily use: several accounts, limits in the middle of a task, many agents in parallel and working from anywhere. So we built our own, then rebuilt it for other people.

Is Shuriken a side project?

Not any more. It began as an internal tool we built next to our main projects. Today a dedicated part of the company works only on Shuriken.

Free tools