Three agents, one job

Most of our projects at Starbourne start the same way: we walk into a company and find three different AI agents doing the same job three different ways.

Here's how it happens. Somewhere in the operation there's real pain. A buyer in manufacturing reconciling emails against the ERP by hand. A billing lead in healthcare spending half their week on claim denial rates. The pain is genuine, it's been genuine for years, and it's exactly the kind of work AI is suddenly good at. So someone decides AI will fix it.

Usually several someones. Independently, with the same idea, at roughly the same time.

They build agents on top of Claude. Some stop at a prompt and a spreadsheet export. Some go all the way — custom software, deployed, real users, the whole nine yards. And taken one at a time, every one of these projects is a success story. Something that used to eat a person's week now happens in minutes. The demo lands. The team feels great, because building is fun. Leadership gets to say we're AI native now, and means it.

Then you zoom out. Duplicate dashboards. Homegrown systems moving in different directions, each with its own definition of the data. Three agents doing one job — and the job still doesn't have an owner. The mess didn't get solved. It multiplied. The company traded one set of legacy problems for three new ones, built faster than legacy ever was.

We've started calling this agent sprawl. It's not the tool sprawl of the SaaS era, where the waste was mostly unused licenses. This sprawl is made of things that work — each agent demos well, each has a champion, each is somebody's proof that the company is moving. That's what makes it hard to see as a problem, and harder to unwind.

Let's be precise about what the problem is not. Experimentation is not the problem. Experimentation is how this starts, and it should start there — scattered, bottom-up, close to the pain. The people building these agents are the best thing the company has going. The trap isn't that three people built three agents. The trap is staying there. Nobody takes it the last mile. Nobody asks: which of these three is actually right? Do we need three, or one that works? What does "works" even mean for this company?

Why nobody walks the last mile

The last mile doesn't get walked for reasons that have nothing to do with technology.

Building is fun; consolidation is politics. Standing up a new agent is a green field and a demo at the end. Consolidating means putting three colleagues' projects side by side and telling two of them theirs is done. Nobody wakes up wanting that meeting, so the meeting never happens.

Nobody owns the question. Each agent was born inside a function, so each one has an owner — but the comparison across them belongs to no one. There's no role whose job it is to notice that procurement, finance, and ops just built the same thing three times. The org chart has an owner for every agent and no owner for the job.

Demos and systems are judged by different standards. A demo is judged by what it can do; a system is judged by who relies on it and what number it moves. Most of these agents were only ever held to the first standard. Ask what the denial rate did, or what the PO cycle time did, and the room goes quiet — not because the answer is bad, but because nobody defined the answer as the goal.

Sprawl serves the narrative. Twelve running pilots make a better slide than one boring system quietly booked against a KPI. As long as activity is the thing being measured, activity is what compounds.

And the last mile is the steepest. This one is more forgivable, because it's not politics — it's capability. The experiments live at the edges of the real systems: a spreadsheet export here, an email digest there, copy-paste at the boundary. That's not laziness; it's where a small team can build. Finishing the job means writing back to the system of record — a decades-old ERP with no usable API, an EHR where every touch has HIPAA implications, a workflow where the audit trail isn't optional. That takes integration and compliance infrastructure — auth, permissions, logging, validation — that a functional team spinning up an agent in a sprint doesn't have and usually can't get. So each agent plateaus as a read-only sidecar: it drafts the answer, and a person still carries it into the system that counts. Three agents, stuck at the same wall.

What the work actually looks like

The work we end up doing on these engagements is rarely building a fourth agent. It's walking the last mile the org couldn't walk itself, and it has two movements: strategy, then implementation.

Strategy is the deeper dig. The instinct is to start by comparing agents. We start by asking what the company is actually trying to accomplish — the business goals, and what's genuinely holding people back. The experimentation already happening is the best diagnostic you could ask for: every homegrown agent is a flag planted on a real problem by the person closest to it. But it's a partial answer by construction, because it happened decentralized — each builder solving their local problem, nobody holding the whole. Underneath the three invoice agents there's usually a deeper layer: the fragmented data that made reconciliation manual in the first place, the approval flow nobody thought to question. The strategy work is digging down to that layer and aligning the team on a common objective — so that "works" has one definition instead of three.

With the objective set, the mechanics get almost procedural. First, inventory — there are almost always more agents than anyone thought: the three everyone knows about and a few more living in someone's browser tabs. Then turn the objective into a benchmark — a set of real cases from the company's own history, with known right answers, scored on the outcome that was the point all along: the denial rate, the cycle time, the hours returned. Not capability — consequence. Run every candidate against it, and "which agent is right" stops being a debate between champions and becomes a score. Often the winner is a composite: this agent's retrieval, that one's workflow, the third one's uncanny prompt that turns out to encode a decade of tribal knowledge from the person who wrote it.

Then the step that makes the rest real: kill the others, visibly and generously. Credit the builders — they found the pain and proved the approach; fold what they learned into the survivor. But retire the duplicates in the open, because every zombie agent left running is a fork of the truth waiting to happen. This is, candidly, the step that's easiest for an outside team to carry: we have no stake in which agent wins, and no history with whoever built it.

Implementation takes the shape the objective demands. The benchmark picks the winner, but it doesn't dictate the build. Sometimes the winning composite really is the system, and the work is hardening it. Sometimes the prototypes proved the demand but none of them has the bones, and the honest move is building fresh — keeping what the benchmark validated, replacing what it exposed. And where the system lives matters as much as what it does: deliver it into the surfaces people already use — inside Claude or ChatGPT, where the team already works, or a purpose-built operational layer like Damon when the job is running a plant. A unified system that shows up as one more tab to check is just a fourth agent with better branding.

Finally, give the system that emerges what the experiments never had: an owner, a number it's accountable to, and real plumbing into the systems of record. That last one is usually where most of the engineering lives — the ERP or EHR integration, the permissioning, the audit trail the experiments were never in a position to attempt. It's also the piece that changes what the agent is: the moment it can complete the transaction instead of drafting it, it stops being an assistant with an audience of one and becomes infrastructure the company runs on. That's the difference between a pilot and a system.

The part that compounds

Zoom all the way out and this is just what incoherence looks like at ground level — the thing we've argued before: a pile of disconnected optimizations doesn't add up to a company that changed. And the fix isn't a policy memo; it's a mechanism — a function whose actual job is to harvest the experiments, consolidate them, and ship the winner for real.

The companies getting this right aren't the ones experimenting less. They're the ones who close the loop: let a hundred agents bloom, then evaluate, consolidate, and put one into production with a name on it and a number under it. Do that a few times and the wins start stacking instead of competing.

Experiment fast. Consolidate faster. Ship for real.