Pick one bounded, reversible, recurring task, write the spec as the artifact you review, build the eval first, name an owner, cap the spend, and run it a month before deciding anything.
By JP LeBlanc
Shipping your first agent-owned workstream means moving one bounded, recurring task from a person running it by hand to an agent running it under a gate, with a spec, an eval, a named owner, and a spend cap in place before anything goes live. Do this with one workstream first. Not five, not a platform, not an announcement. One, run for thirty days, before you decide whether to do it again.
An engineer on a platform team once built a prompt chain that turned a week's worth of flaky-test failures into a ranked list of quarantine candidates: pull the CI logs, cluster by failure signature, cross-reference blame history, draft a summary, post it to the channel. An hour of Monday-morning scrolling became eight minutes, and he was right to be proud of it. Eight months later he was still the one running it, by hand, every Monday, and if he went on vacation the list didn't get posted. That's the prompt tax: a real workflow that never became a workstream, because nobody gave it a spec, an owner, or a gate. It stayed a person's Monday morning instead.
Bounded, checkable, reversible, recurring, low blast radius. Dependency upgrades. Flaky-test quarantine. Migration mechanics, the kind where agents already earn their keep. Anything with a specific goal, a mechanical check, and a small enough failure mode that being wrong once costs an afternoon, not an incident review.
The tell that a candidate is ready: a good junior engineer, handed the same ticket cold, would come back with roughly the right thing on the first try. If a strong junior would come back confused, the agent will too, just faster and with more confidence about it, which is worse.
Resist the urge to start with something more impressive. The unglamorous workstreams are unglamorous precisely because they're bounded and checkable, which is exactly the property that makes a first attempt survivable.
Once the task moves to an agent, the diff stops being where you should be spending review attention. The spec is what gets reviewed: the inputs and outputs that prove the work is done, the invariants that can't break, the cases that must not slip through. Write it precisely enough that someone reading it cold, without asking you what you meant, can say definitively whether an output satisfies it.
If the spec needs its author in the room to interpret it, it isn't a spec yet. It's a paragraph doing an impression of one, and it will fail on exactly the workstream you're trying to hand off, because nobody will be in the room every Monday to interpret it.
Not after. This is the step most teams skip, and it's the one that turns "it feels like it's working" into a number somebody can defend in a budget meeting. Pull ten or fifteen real examples from your own backlog or incident history, decide what a pass means, and run the candidate workflow against them before a single instance touches production.
Skip it and the pattern is predictable. The workstream goes straight to broad use because the case felt obvious, and months later somebody sits in a budget conversation with nothing but a feeling to defend the renewal. A feeling can win that room once. It doesn't win it twice, and the difference between those two conversations is the entire case for building evals before rollout rather than retrofitting them once someone in finance asks.
Ownership doesn't transfer to the workstream because the workstream is agent-run. Somebody's name goes on the rota, the same as if a person were doing the work, and that person gets paged if the flaky-test list is wrong or the dependency bump breaks a build. Responsible can be a rotation. Accountable is one name.
Set the autonomy tier to match how reversible a mistake actually is, not how routine the task looks. A wrong quarantine recommendation costs a wasted hour of someone re-running a test. A bad dependency bump that ships unflagged costs more, so it earns a narrower gate even though the ticket reads just as boring on the board. And cap the spend from day one, per workstream, with whoever owns it able to see the number, because an agent-run workstream with no visible cost is exactly the kind of thing that becomes someone else's surprise eight weeks in.
Run it for a month before deciding anything permanent. Watch four numbers: changes shipped per week without a human touching them, the rate at which something bad got through anyway, cost per change, and hours of attention actually returned to the person who used to own this by hand.
That last number is the one worth sitting with. Not hours saved in the abstract, which is a number you can produce for anything. Hours the owner actually got back, measurable in whether they stopped thinking about Monday mornings on Sunday night. The flaky-test engineer never got that back, because the chain he built never had an owner other than him, a spec other than his memory, or a gate other than his own judgment about which steps to trust that week.
Thirty days in, you'll know one of two things. Either the workstream held, in which case you now have a template rather than a one-off, or it didn't, in which case you found out cheaply, on one bounded piece of work, instead of finding out later across five of them at once.