Bitfield lives on, in a different way

Bitfield still lives on, but not as the engine everything runs on. We dropped the Bitfield runtime, kept its principles and its code, narrowed what the product is for, stopped forcing every tool to be a plugin, and turned the AI layer into one connection that any AI can join.

What changed, in plain words

Bitfield was the foundation I spent a long time building: a runtime where every piece of software was a plugin, and where every change ran through one shared log. The idea was that anyone could build any tool, package or workflow on top of it.

The product we ship now does not run on that runtime at all. But the thinking behind Bitfield is still in every part of it. On a walk this week I said it out loud: "We are not tied to bitfield architecture, but we can still embed all the principles and the philosophy of it." And then, "so Bitfield lives on, but in a different way."

Four things changed. The runtime is gone. The product is narrower. Tools no longer have to be plugins. And the AI side became one open connection instead of a place you log into.

The runtime is gone, the principles stayed

The biggest single change is that we stopped running on the Bitfield engine. As I put it, "the biggest difference is we're not running it on the bitfield runtime."

The runtime had real costs. Everything went through one log, and that log kept getting slower and heavier. Features would work, then one new change would break things that had nothing to do with it. My frustration at the time was simple: "I was working 10 minutes ago, you did one thing, and now the log is crashing."

What we kept matters more than what we removed. We kept the separation between parts, so one change does not tangle into everything else. We kept the idea that behaviour should be described as data you can change, not hard-coded into the engine. We kept the hundreds of packages that were already written, and they are being moved over one by one. We kept the standard of writing code that stays clean as it grows.

The result is that new features now reach real people far faster, because they no longer have to pass through a runtime that was slowing everything down.

The product became narrower

Bitfield started as something very broad: a studio where anybody could build any package, any tool, for any workflow. That breadth sounded powerful, but it made it hard to say what the product was actually for.

Now it is specific. In my words: "I got deep into building a product that's like a very specific one." It is "specifically tied around, like figuring out what it's worth pursuing and then actually pursuing it."

It is still broad underneath. The same parts can serve cooking, coaching, a business or a book. But the front door is one clear job: work out what you are pursuing, find the single biggest move, and get it done.

Being narrower also means being more opinionated. Every decision starts the way I start them with the people I coach in person: first, what is worth pursuing? Only then, what is the biggest move toward it? That order is built in rather than left to chance. A person can still change the rules for their own account, but everyone starts with the method that works, instead of an empty studio and a blank page.

The question that made all of this possible was a plain one. Did we actually need the runtime to deliver the outcomes we wanted? When we asked it honestly, the answer was no. Everything we cared about could be kept without it.

Tools no longer have to be plugins

This was the change that surprised me most. Bitfield said every tool had to be converted into its own plugin format before it could be used. Looking back, "bitfield was actually constrained because by saying, hey, everything has to be a plug-in to work," I was shutting out almost all of the software that already exists.

Today an AI can simply use a tool that already exists, from an open source project, a command on a computer, or a service with an API. If a tool does a job, it gets described once so any AI can find it and run it. Nothing needs to be rebuilt to fit a special format first. That opened the door to far more than back-end tools: interface parts, written skills, checklists and workflows can all be shared the same way.

The AI layer became one connection

Before, you would sign in and pick which AI to connect, and the product felt like its own separate agent with its own rules. That meant the AI you already use, with everything it knows about you, could not come along.

Now it works the other way round. "We changed it to an MCP." MCP is an open standard that lets an AI app connect to outside tools and data. "Now the AI can connect to the MCP." So any AI app that supports MCP, and a growing number do, can join, bringing its own context, and every one of them sees the same decisions, files and tools.

Instead of wrapping your AI inside our product, your AI joins us.

How to apply this to your own project

Most people who have built something big for a long time face the same choice. Here is how I would work through it.

1. Write down what the old system was really for, in one sentence, without naming the technology.
2. List the principles you believe in, separately from the machinery that carried them.
3. Ask whether each piece of machinery is still the cheapest way to deliver those principles today.
4. Remove the machinery that is not, and keep the principles and any code that still earns its place.
5. Narrow the product to the one job people most need from it.
6. Open the edges, so that what already exists outside can plug in without being rebuilt.

A well-known example of ideas outliving their first home is Unix. The original systems are long gone, but its ideas, small tools that each do one job and can be joined together, live on in Linux and in the Mac. The principles travelled. The first machine did not need to.

The short version

• We dropped the Bitfield runtime and kept its principles and code.
• Features now reach people faster because nothing passes through a slow shared log.
• The product narrowed to one job: find what is worth pursuing and pursue it.
• Tools no longer have to be rebuilt as plugins; any AI can use what already exists.
• The AI side is one open connection, so the AI you already use joins instead of being replaced.