There is a stage in every serious Claude Code deployment where someone writes a script to orchestrate agents: run these three in parallel, feed the output into that one, stop if the budget is exceeded. It works, it feels clever, and it becomes a maintenance burden roughly four weeks later. The tooling has caught up, and hand-rolling this is now usually the wrong call.
Why teams build them in the first place
The need is real. Once you are running more than one agent, you want control over sequencing, concurrency and spend, and for a while the only way to get any of that was to write it yourself.
Running independent tasks concurrently rather than waiting for each in turn
Passing the output of one stage into the next without a human in the middle
Capping token spend before an unattended run becomes an expensive surprise
Retrying failures without restarting the whole pipeline from the beginning
Every one of those is a legitimate requirement. The question is whether they justify a bespoke runtime that only one person in your team understands and nobody else wants to inherit.
What it actually costs to own one
Orchestration code sits in the worst possible position: critical enough that failures stop work, obscure enough that nobody wants to maintain it, and coupled tightly to whatever the tooling looked like on the day it was written.
The recurring bill is upgrade friction. Every change to the underlying tools risks breaking assumptions the script made, and the person who wrote it has usually moved on to something else. For an Australian team paying $160,000 to $200,000 a year per engineer, a few days of unplanned maintenance each quarter is real money spent on plumbing nobody wanted.
What native workflow features cover
Sequencing, parallelism, budget limits and phase boundaries are now largely available without custom code. The specifics change release to release, which is precisely the argument: features that move should be maintained by the people shipping them.
Before writing anything, check what the current tooling does natively. A surprising share of hand-rolled orchestration is reimplementing something that shipped in the interim and nobody noticed, because the team stopped reading release notes once their script worked.
When writing your own is still right
If your orchestration has to interleave with systems the tooling knows nothing about, a deployment pipeline, an approval queue, an internal scheduler, then some glue is unavoidable and appropriate.
The distinction is glue versus runtime. Code that connects an agent to your existing systems is normal integration work. Code that reimplements scheduling, concurrency and budgeting is a runtime, and runtimes are expensive to own.
The failure mode nobody plans for
Custom orchestration tends to fail quietly. A stage errors, the wrapper swallows it, and the pipeline reports success with half the work missing. That is considerably worse than a loud crash, because it can run undetected for weeks.
Whatever you build or adopt, make partial failure noisy. An orchestration layer that cannot distinguish between finished and abandoned is not saving you time, it is deferring the discovery of a problem to a less convenient moment.
Budget controls are the part worth keeping
If you take one thing from a hand-rolled setup into a native one, make it the spend cap. Unattended agent runs are the single most reliable way to generate an unexpected invoice, and the failure is silent until the bill arrives.
Set a hard ceiling per run and per day, and have it alert rather than merely stop. A run that halted because it hit a limit is information about your workload, not just an inconvenience to be raised and forgotten.
A reasonable migration path
Do not rewrite everything at once. Take the newest pipeline, rebuild it on native features, and run it alongside the existing one for a fortnight to compare behaviour and cost before switching over.
If it holds up, migrate the rest as each one next needs maintenance. That way the work happens when you were going to be in the code anyway, rather than as a project nobody wants to fund on its own merits.
Write down why it exists
Whatever survives as custom code should carry a short note explaining what it does that the native tooling could not, and when that was last checked. Six months later that note is the difference between a confident deletion and a nervous rewrite.
It also makes the annual review trivial. Someone reads the note, checks whether the gap still exists, and either closes it or leaves it for another cycle.
What not to conclude
Native features are not automatically sufficient for every case, and this is not an argument that custom code is always wrong. It is an argument that the default has flipped: assume the tooling handles it, verify, and write your own only where it genuinely does not.
The broader lesson applies well beyond agents. Building infrastructure that a vendor is actively shipping is a race you lose slowly, and the cost shows up as maintenance rather than as a decision anyone gets to review.
If your team has accumulated orchestration scripts nobody wants to touch, book a short call and we will look at what the tooling now handles natively.
