Ask three good engineers to fix the same bug and you get three shapes of answer. One reads the whole module before touching anything. One writes a failing test first. The third patches it, runs the suite and sees what screams. A pipeline is you deciding which of those ko is, before it starts.

Every agent you have used gets shaped by asking nicely. You write a longer system prompt, you add "do not refactor unrelated files" in capitals, and it drifts anyway. Knockout shapes behaviour by taking capabilities away. A planner whose step lists only Read, Glob, Grep, Lsp cannot drift into implementing, because Write is not on the table. You get a plan back. Not half a patch and an apology.

From there each step carries its own model, its own system prompt, its own temperature, its own retry budget and its own spend cap, plus a transition rule that decides where the job goes next. A verifier that emits tests_fail routes back to the implementer. Loop protection caps any one step at three visits so a bad branch cannot drain a wallet overnight. Design it as a drag-and-drop graph, edit the JSON directly, or work the card view. Whichever you pick, the loop is yours to change.

Nothing in the pipeline machinery knows what code is. A step is a model, a prompt, a tool list and a rule about what happens next, which is the same shape whether the work is a database migration or a lease agreement. So the same ko binary that shipped your billing endpoint this morning can argue both sides of an MSA this afternoon. Ten pipelines seed to your account on day one, covering coding plus legal, finance, business, research, HR and creative work. Type /pipeline to switch mid-session and your conversation history carries over.

Nobody puts their principal engineer on the job of running npm test and reading the output. Every single-model agent does exactly that, on every step, because it only has the one model. Reading a codebase and checking whether a suite went green are jobs a cheap model does perfectly well, and they are most of the tokens in a real session. Point each step at the model that fits the work it does, and the expensive one only gets billed for the thinking that was actually hard.

The second task in a session is cheaper and faster than the first, because the plan step is reasoning over a codebase it has already read rather than starting cold.

You explain your codebase to an agent on Monday. On Tuesday you explain it again, in the same words, to the same tool. Every agentic CLI works this way and everyone has quietly accepted it as the cost of the format. Four things below are what ko does instead, and none of them are the same mechanism.

Six complaints we heard often enough to build against.

Starting from an empty directory is the worst way to start. A wizard asks five to ten questions about the business, the audience and the tone, turns the answers into a project design and hands you a template id. ko build tp_abc123 picks it up and starts building.

Per token, with the running total ticking in the status bar about four times a second while a model streams, so you can hit ESC on a run that is going nowhere and pay only for what already came back. Before any platform-billed call, ko estimates the worst case and refuses to start a request that could outrun your balance.