Building teams of software agents

Software agents stopped being a demo and started being a workforce. The shift wasn't the moment they could chat — it was the moment they could carry real, recurring work: answering, monitoring, routing, flagging. Work that used to need a human in the loop, every time.

I've spent the last stretch turning a collection of models into something closer to a team — each one with a role, a narrow job, and a clear handoff. The lessons were less about the models and more about what a good manager already knows.

Names and roles, not channels

The change that mattered most was giving each agent a job, not just a prompt. A scoreboard of generic assistants helps nobody. Split the work by function — one for the accounts, one for the front line, one for the machines — and suddenly each one gets good at a small thing, and the sum starts to look like a department.

The handoff is the hard part

The failure mode isn't a dumb agent. It's a pile of agents with no way to know who owns the next step. Designing the handoff — the moment one agent finishes and the next one takes over — is where a fleet of assistants becomes an operation.

A smart agent you can't route is a toy. A group of narrow agents with clear handoffs is a team.

Human at the edges

For anything with real cost — a payment, a promise, a public statement — a human still signs off. The agents shrink the distance between signal and action; the human stays the one who owns the outcome. That split is the whole design.

It only makes sense if you've first decided to own the systems they run on, and chosen the tools well.