The problem I was actually trying to solve
I had a window. Life was about to get busy, and I had a few weeks of clear air to push my own work, my own observability platform, as far as I could.
The constraint wasn’t ideas. I had hundreds. The constraint was time, and the fact that I wanted to build enterprise-grade software, not a pile of demos. By that I mean three things at once: every line of shipped code traces back to the originating idea, the process is disciplined enough that requirements precede plans and plans precede code, and the release is shippable rather than “demo-ready.”
I was coding with Claude and getting things done at a speed that genuinely unsettled me. Features that would have taken three months in my CTO days were appearing in fifteen minutes, written, tested, working. Wonderful. Also a problem, because the bottleneck stopped being can the code get written? and started being do I know what I’m asking for? and can I keep up with what’s already been delivered?
And there were two more problems stalking the first one.
Money. The moment I hooked agents up to a real workflow, I was burning through tokens fast enough to instantly justify upgrading to Claude Max. If I wasn’t careful, I was going to be running a startup-sized AI bill out of my own pocket. Worse, the per-feature cost was completely opaque to me. I knew I was spending money. I had no idea on what.
Privacy. Every prompt I sent to Anthropic or OpenAI contained a piece of my product. Architectural decisions. Schemas. Algorithmic choices. The quiet competitive moat of any software product lives in details exactly like those, and I was happily uploading them to a third party in exchange for code suggestions. That’s a trade-off I’m comfortable with for my own side projects. It is categorically not a trade-off a healthcare client, a defence contractor, a bank, or a serious startup with a real moat should be making without thinking very carefully about it. And many of them are not.
So the actual problem I was trying to solve was this:
How do I take vague ideas and turn them into shipped, enterprise-grade releases, fast, without losing the plot, without an AI spend that eats the project, and without leaking my code to whoever’s hosting the model this week?
What I built to answer that is kaos-control.
Why raw Claude alone isn’t the answer
Sitting down with Claude Code (or Cursor, or any of the new agentic IDEs) and just vibing works for an afternoon. It does not work for a project.
After a week of going hard on a new project, I had a directory full of features I half-remembered, decisions I couldn’t reconstruct, and a roadmap that lived entirely in my head and my browser tabs. Some features overlapped. Some contradicted each other. Several were 80% done and abandoned because I’d had a better idea on the train.
This is the same trap I watched developers fall into for twenty years before AI showed up. The classic good developers don’t write things down problem, except now the developer is a robot that doesn’t sleep and writes faster than you can read.
The agentic IDE wave addresses the coding part of this. It does not address: where ideas come from and how they’re captured; how a vague idea becomes a clear requirement; how requirements get planned, broken down, and assigned; how multiple agents coordinate on related features without trampling each other; how releases get cut and what goes in them; how tests get written, run, and approved; how you trace a line of code back to the idea that asked for it; which model should do which job; what each job costs you; and whether your code is leaving your machine at all.
It also tends to want root access to your laptop and breaks every time it updates. That’s fine for tinkerers. It’s not fine if you’re trying to ship something serious.
What kaos-control actually is
A single Go binary. About 250 MB. Embedded web UI. SQLite for the index and release metadata. Everything else is flat markdown files with YAML front matter, sitting in a git repo, committed by agents and humans on every change.
Run it on your laptop, your Linux box, or a Tmux session you SSH back into from the kitchen iPad. It’s deliberately a small-team tool, three or four people at most, not fifty.
The shape of it:
A lifecycle. Every piece of work is one of three things: a new feature idea, an enhancement to an existing feature, or a defect.
Three. That’s the trick.
Most ticketing systems start by giving you nine types and twelve custom fields and you spend more time configuring the tool than using it. Three is enough. Each piece of work walks through configurable stages: capture, requirements, planning, frontend / backend / DevOps work, tests, release. Each stage produces a markdown artefact. The artefacts are the work.
Roles, played by agents or humans. Requirements analyst, planner, frontend developer, backend developer, QA / test developer, DevOps, product owner, reviewer / approver, tech writer. You decide for each role whether it’s a human or an agent. You can have an agent draft requirements that a human product owner approves; you can have a human lead developer write plans that agents implement; you can have agents run tests that a human QA lead signs off. The role contract is the same either way: produce the artefact. No “blah blah blah, I’ll write it later.” If it isn’t written down, it didn’t happen.
Lineage. Every artefact knows its parent. The defect knows which feature it belongs to. The feature knows which idea it came from. The test knows which feature it tests. You can pull up a release and see every artefact that fed into it, all the way back to the casual sentence on the train that started it.
This is the bit I haven’t seen anywhere else, and it’s the thing I’d most struggle to give back.
Multiple views over the same data. A list view for grinding through work. A Kanban for planning, with a blocked column that doubles as the human work queue, anything sitting in blocked needs a person to look at it. It’s where the agent loop hands back to you, and on a healthy board it stays the smallest column. A Gantt for the people who, fairly or not, want a Gantt. A 3D graph for clustering features into releases visually, where features cluster around the releases they belong to and unscheduled work waits to the side. Same artefacts, different lenses.
One-shot capture. When somebody emails you “we should have icons with purple elephants,” you paste it into a box and hit generate. The system uses the project context to figure out whether it’s a feature, an enhancement, or a defect; writes a proper artefact with reproduction steps or acceptance criteria; fills the metadata; gives it a slug; and links it to related work it found on the way through. The vague-thing-in-an-email problem, solved in fifteen seconds.
Different models for different roles. Inside the same project you can run Opus on the requirements analyst and the planner where thinking quality dominates, Sonnet on the developers where speed and cost matter, and Haiku on the QA executor where the work is mostly did the result match the expected result?This is the hinge of the cost and privacy story below.
A methodology that travels with the work. The discipline (ask questions before assuming; produce artefacts at every stage; commit on every change; prefer Opus for thinking, Sonnet for doing; run cheap models for cheap work) is encoded in CLAUDE.md files inside the project. Any agent, kaos-control’s own or interactive Claude Code in the same directory or the next AI tool you plug in tomorrow, reads it and follows the same rules. The methodology is the product as much as the binary is.
Obsidian-compatible storage. Because the artefacts are just markdown with YAML front matter, you can mount the project in an Obsidian vault and edit on the train, on the iPad, in any tool that understands markdown. Git captures every change either way.
What it looks like to put a feature through it
Concretely. I had a real feature on my list, make the agent run logs human-readable instead of raw JSON blobs. Here is what the lifecycle did with it.
Capture. I opened the project, hit new idea, typed two sentences in my laptop voice: “the agent log dump is unreadable JSON, I want a parsed, human-readable version with the raw JSON one click away.” The system generated a proper feature artefact: title, slug (agent-log-readable-view), type feature, area frontend + backend, severity enhancement, links to two related artefacts it had noticed (one about agent observability, one about the workflow board needing better diagnostic surface). It filled the front matter automatically.
Requirements. I assigned it to the requirements analyst, configured to use Opus. The analyst came back with a markdown artefact full of clarifying questions, inline. Like an email thread, the way I used to make junior developers do it twenty years ago because that habit beats everything else I’ve ever tried for nailing scope. Should the parsed view show every JSON event or aggregate by phase? Should the raw view be a modal, a side panel, or a separate route? What’s the expected log size at the 99th percentile? I answered each one in a few words. The analyst regenerated the artefact into a proper requirements doc.
Planning. I assigned to the planner, also on Opus. The planner produced three plans: a backend plan to parse the JSONL stream into a structured representation, a frontend plan for the new view, and a test plan listing the cases. Each got its own artefact. Each was linked to the parent feature.
Development. Backend developer (Sonnet) and frontend developer (Sonnet) ran in parallel, each in its own agent process, each committing to git on every change. They followed the methodology in CLAUDE.md: ask if uncertain, produce a small commit per logical change, write the docstring before the function. The artefacts in the repo updated as work progressed; the Kanban view showed the cards moving.
Tests. Test developer (Sonnet) generated test cases against the test plan, which had been written before the development plans were implemented. Test executor (Haiku, because did the result match the expected result? really doesn’t need a frontier model) ran them. Failures opened defect artefacts automatically, linked to the parent feature, assigned to the right role.
Release. Once the artefact cluster around agent-log-readable-view was green, feature complete, tests passing, no open defects, I moved it into the May release in the 3D roadmap view by clicking on the cluster. Done. Every artefact, from the original two-sentence idea on, is in git, traceable.
The end-to-end was about four hours of agent time and maybe forty minutes of mine, mostly in the requirements stage, where my judgement is most valuable and where I refuse to let the agents skip the questioning phase. The previous time I’d shipped something of comparable shape, three months of CTO life with a developer, a tester and a manager all in the loop, it took six weeks.
Cost and privacy are the same story
Most “AI dev team” articles skip this part, and it’s the part that matters most if you actually have to pay the bill or sign the data-handling agreement.
The same lever solves both. Inside kaos-control, every role can be configured to use a different model and (on the roadmap) a different provider. The role contract is do this work and produce these artefacts; the model behind it is a configuration choice, not an architectural one.
The cost lever: model per role. Opus for the requirements analyst and the planner, where thinking quality dominates and a wrong answer costs you a week. Sonnet for frontend and backend development, fast, solid, dramatically cheaper per token. Haiku for QA and test execution, where you don’t need a frontier model to answer did the result match the expected result? The cost ratio between Opus and Haiku has historically been ten to fifteen times; even at today’s narrower five-times ratio, putting Haiku on tasks that don’t need Opus is the difference between a sustainable bill and a panic.
The privacy lever: provider per role. Today: Anthropic’s API and Ollama for local models. Coming: an OpenAI-compatible interface that lets you point at OpenAI, Google, OpenRouter, NVIDIA’s hosted endpoints, your own self-hosted inference, anywhere a sensible API lives.
That gives you tiered privacy on the same workflow. Public-tier work (research, brainstorming, public-API integration) can go to a hosted model where the quality is highest. Sensitive-tier work (your business logic, your data schema, your clever stuff) goes to a local model running on hardware you own. Air-gapped work, if you really need it, runs entirely on a single machine. kaos-control is a single binary; pull the network cable; the workflow keeps going.
The hardware story is more accessible than people realise. A Mac with enough RAM can run gemma4:31b (a 31-billion-parameter open-weights model) over Ollama, fast enough to handle the QA tier, the test-execution tier, and a lot of the dev tier in real time. More memory, bigger models. That’s a one-time hardware cost in the low thousands at most, against an AI bill that for an active team easily runs to that range per month. The moment you can keep your sensitive work local, the privacy story and the cost story become the same story.
Token observability. Every agent run logs the full conversation as JSON, including the per-call token counts. The next release will surface a per-feature, per-release cost in the UI, so you can answer the question what did this release cost us? in dollars, not vibes.
Burn-down awareness. Because the system can see how much budget the provider says you have left, the workflow can degrade gracefully. If you’re out of premium tokens for the day, plan more, code less. The “I need to be productive on the train” mode is mostly idea capture and prioritisation anyway, both of which are nearly free.
Where kaos-control sits next to the agentic IDE wave
People are going to ask how this relates to OpenCode, OpenClaw, Hermes Agent, Paperclip, Cursor, and the rest of the Claude-Code-likes.
The honest answer: kaos-control is above them, not next to them. It’s a workflow engine. The agentic IDE wave is full of brilliant tools for the write the next chunk of code problem. They mostly assume you already know what to write. kaos-control assumes you have a vague idea on the train and need a system to walk it from there to a release.
You can, and I do, use Claude Code interactively inside the same directory kaos-control manages. The CLAUDE.md file makes both flows follow the same methodology, so an interactive afternoon with Claude doesn’t produce work that’s incompatible with the agent runs.
What kaos-control adds that the IDE wave doesn’t: structure (every piece of work is captured, classified, planned, built, tested, released, by default not by discipline); coordination (multiple agents running in parallel against a shared repo, with roles, gates, and reviews, not a single agent doing a long monologue); and cost and privacy as first-class concerns (choose the model per role, choose the provider per role, run locally when you have to).
If your problem is “the next twenty lines of TypeScript,” use Cursor. If your problem is “I have eighty ideas and a contract that starts in six weeks and I need to be a one-person dev shop without losing my mind,” that’s the problem kaos-control was built for.
Who this is for
This is for lead developers introducing AI agents into a real team workflow without giving up code review, tests, release discipline, or the option to keep certain code off third-party servers.
It’s for CTOs and tech leaders off the tools for a while who want to read documents and approve things rather than tinker with an AI IDE.
It’s for founders and entrepreneurs running a one-person dev team who need structure to keep track of what they’ve already built.
It’s for product managers and product owners who want vague ideas captured faithfully and traceable artefacts to show stakeholders.
It is explicitly not for people who want a frictionless “vibe-code an MVP in an afternoon” experience. kaos-control imposes process on purpose. The process is the point. (although you still get an MVP in an afternoon)
What kaos-control isn’t
It isn’t an IDE. Use Claude Code, Cursor, your favourite tools; kaos-control sits next to them, not in their place.
It isn’t a SaaS. It runs locally. Your code, your artefacts, your git history, your machine. (That’s not just a deployment choice; it’s the privacy story in one sentence.)
It isn’t a “fire all your developers” pitch. It’s the opposite. It assumes you have a small number of senior people whose time is precious, and tries to multiply them by giving them an agentic team that follows process. The people walking into development shops announcing software engineers will be obsolete in 90 days are not the people who actually ship software.
Where it lives, what licence it’s under
kaos-control is going out under AGPLv3 (the strongly-copyleft GNU licence), with a dual-licence option for organisations that can’t accept AGPL terms. That’s deliberate. I believe in open source. I do not believe in spending two years of evenings building something so a hyperscaler can rehost it as a paid service and never contribute back.
If you’re a CTO, a product manager, a founder, a lead developer, anyone who has felt the gap between I have an idea and we shipped it, give it a try. Pull it down, point it at a project, watch an idea walk through the lifecycle. If it helps you ship enterprise-grade software with less time, a smaller AI bill, and your code still on your own hardware, that’s the entire goal. If it doesn’t, tell me why; the issue tracker and contributing guide live in the repo. When the inbound volume justifies it I’ll add an agent role inside kaos-control itself for triaging incoming pull requests, and dogfood that one too.
kaos-control lives at https://github.com/kcsinclair/kaos-control. Install details in the README, binary release coming. Issues and contributing guide are in the repo.
A good developer releases. A good writer publishes. This is me releasing.
Reducing the friction of turning ideas into traceable requirements and then shippable code. I have lost count of the number of projects where I have tried to do this using governance and frameworks, with varying levels of success or failure. Admittedly, all the "agents" were humans and all the tools were big budget SaaS offerings but a change in form factor for the "agent" doesn't mean the challenge has gone away.
The fact that this tool enables you to focus on ideas and innovation rather than managing the mechanics of product creation is a massive step in the right direction. Thank you for sharing Keith, i'm looking forward to giving this a spin.