Done means done done.
Agents unlock new possibilities. Months of work now land in days. But you are the one holding it together. Watching sessions. Checking that what you designed is what got built. Remembering which skills to run, in what order, and where they get inserted. Every single time.
Runtime is a harness built out of that manual work. The skills, the subagents, the tools, and the judgement about when each one runs.
The time goes into the design, and into what done has to look like. The build workflow gets laid out once, then runs that way every time, and shows where it stands without anyone asking.
The first done: the right things got built.
The second done: it works as designed.
I built Runtime so my own team could go faster. I am pulling it out now so it runs on anyone's laptop. Some of what follows is still being built.
I am the one watching.
I spend an unhealthy amount of time staring at session screens, trying to keep up with what is going on. Looking for the right moment to insert a skill, or a correction, or an adversarial review. Keeping track of whether the right things are being built, in the right order.
And all of it runs on a budget. How much context is left. Whether to compact or clear, and when. Which model each task is worth, and how much thinking is enough before it turns into waste. The same skill does not always want the same answer. It depends on where in the build it runs.
In my experience, managing a coding agent is like managing a brilliant developer who is endlessly curious and easily pulled off course. Something interesting appears and it gets chased. Hours later there is real work on the screen, and it is not the work that was asked for.
Tell a person what not to do and they hear it. Tell a session, and “do not do this” can come back as “do this”. And what gets built the wrong way stays: half finished work on a branch nobody closed. Writing five thousand lines on a blank page costs almost nothing. Getting four hundred of them deleted takes a battle with a stubborn agent.
The developer has one advantage. Ask a person what they are working on and the answer costs nothing. Ask a session and it can spend hundreds of thousands of tokens reading itself back before it answers, and the answer still might not be accurate. So I open a file instead, and half the time the two do not agree, with no way to tell which one to believe. The status question costs the work it is asking about.
Now run several sessions at once, and never look away from one for longer than five minutes. Did that one skip a phase? Is that one still on the job? I hold all of it in my head.
Staring at coding sessions does not scale. Yelling at them is not healthy.
You design. Then you hit go.
Start at the end. What does this have to do for the business? What does a person need to get done? Then work backwards into how.
That is where your time goes now. The design. The plan. The UI mockups. And what done has to look like, written before there is any code to grade against it.
Get smart once on how to sequence your build workflow. After the design and the plan, what belongs in code, in compile, in test and in push. And what runs instead when a step comes back differently than you expected. Then it runs that way every time.
Runtime keeps the work on the job. In order, head down, on what was asked for and nothing else.
Not everything will work. What matters is that you are told, instead of it being buried.
Three things you stop guessing about.
Where the build stands.
Every card, every stage, on one board. You do not interrupt a session to ask, and you do not read through files to piece it together.
Whether the right things got built.
A gate at every stage checks the work against what the card said it had to do. The agent that did the work never gets to mark it done. A second one, working fresh, confirms it.
Whether it works as designed.
The observer drives your running app in a real browser and holds it to the same criteria. A green test says a test passed. This shows what your software did, across the browser, your application logs and your cloud on one timeline.
What I am working on now.
Stopping on a real error instead of carrying on past it. A ceiling on how many times a loop can run. A clear line for what good enough looks like, so a session knows when it is finished. It is designed to tell you when something did not work, and getting that right every time is the work in front of me.
The observer goes out first.
It opens with a scan that reads your code and builds a graph of it. What runs, and what nothing has ever reached.
Then the branch view. A subway map of every branch and worktree, so you can see where your code actually is. Not only what reached the repository, but what an agent wrote and left behind when it stopped, and how much of it there is.
Then the functional side. The browser, your application logs and your cloud on one timeline, so what went wrong is one line in one place instead of three tabs and a guess.
It installs as a plugin and brings its MCP server, hooks and skills with it. Built for Claude Code and Codex, for Anthropic and OpenAI models. Runtime runs locally on your machine.
The field notes and white papers go out with them. What I found while building each piece, and how the harness handles it. Some of it is published guidance, built so it happens the same way every time. Some of it I have not found written down anywhere.
All of it under Apache 2.0.