Running a team where some members are agents

Here's a hypothetical, made up to show the moment. A small product team has started handing real work to agents. One drafts the weekly customer update. One writes first-pass plans for new endpoints. Another cleans up the changelog before each release. For a few weeks it feels like the team got bigger without anyone being hired.

Then the standup changes. Someone asks about the search filter plan, and the answer is "I think an agent has it." Someone else asks whether the customer update went out, and two people say they assumed the other one sent it. The changelog has two versions, both written overnight from the same commits, and they disagree about what shipped. Nobody did anything wrong, exactly. The work is happening. It's just no longer clear who's doing what, what finished means, or what's ready to go out.

This is an opinion piece about running a team where some of the members are agents, and here's my claim. I think a team like that needs the same basics as any team, just written down harder: one owner per piece of work, a written definition of done, a board everyone reads, and one role that can mark work ready. What breaks first, I think, is the unwritten stuff a human team gets by on.

One owner per piece of work

On Monday I argued that anything an agent makes needs a named person who answers for it before it leaves the team. Running a whole team with agents in it is that idea applied everywhere at once.

Every piece of work gets one owner. Sometimes the owner doing the work is an agent: it drafts the update, it writes the plan. That's fine. But each piece of work also needs a person who's accountable for what ships, and that person should be obvious to anyone who asks. If the honest answer to "who has this?" is "an agent, probably," the team doesn't have an owner. It has a guess.

Human teams get away with fuzzy ownership because people notice gaps. If two engineers both start on the same bug, there's a good chance one of them mentions it at lunch. Agents don't have lunch. They'll each do the work they were given, in parallel, without knowing the other exists. So the owner has to be written next to the work, not carried around in someone's head.

Handoffs and done

The second thing that needs writing down is what "done" means.

Between people, a lot of "done" is implied. You know the update is finished when it's been sent, because that's how it's always worked. An agent doesn't share that history. It finishes when the task it was given looks complete, and that might be a draft in a folder, not a message in a customer's inbox. If done isn't written down, I think you'll keep discovering work that the agent considers finished and the team doesn't.

A written definition of done can be short. "Done means sent to the customer list and linked on the board" is enough. "Done means a person has read the plan against the ticket and said yes" is enough. The point is that it's the same sentence for everyone, including the agent.

Handoffs need the same treatment, with one addition: they should say what was left out on purpose. When one agent's draft becomes another agent's input, or a person picks up where an agent stopped, I think the most useful line in the handoff is "I didn't touch X, deliberately." Without it, whoever picks up the work will reasonably assume the gap is a mistake and fill it.

The board and the stamp

A team with agents in it needs one place everyone reads. Not a channel where updates scroll away, but a board or a plan file that says what's in flight, who owns it, and what state it's in. People read it at the start of the day. Agents read it before they start work. If something isn't on the board, it isn't happening.

The board answers "what's going on?" The other piece answers "what's ready?" I think one role should be the only one allowed to mark work ready to ship. Not everyone with an opinion, and not the agent that produced it. One role, with a clear standard, whose stamp means the work was checked against what was asked. On top of that, anything public gets cleared by a person before it goes out.

That's how we run our own GTM work. Each piece has a named owner, the week runs from a written plan, one role stamps drafts ready, and a person approves every public post before it goes out. None of it is clever. It just means that when someone asks what's ready, there's one answer, and it's written down.

What breaks first

If you're adding agents to a team that already works, here's where I'd expect the cracks to show, in rough order.

Duplicated work. Two agents, or an agent and a person, do the same thing because nobody wrote down who had it. It looks like productivity until you have to reconcile two versions. The fix is boring: one owner, on the board, before work starts.

Stale status. The board says something is in progress, and it finished two days ago. Or it says done, and it never went out. I think status drifts faster on a team with agents because work happens at odd hours and nobody is around to update anything. The fix is to make updating the board part of done, for agents and people alike.

Work nobody stamped. Something ships because it existed and looked finished, not because anyone decided it was ready. This is the one I'd watch most closely, because it's the one that reaches customers. The fix is the stamp: one role, a written standard, and nothing public without a person's yes.

None of these are new problems. Human teams have all three. I think agents just make them show up sooner, because agents produce more work faster and don't fill gaps with the hallway conversations that keep human teams roughly in sync.

The old kind of management, written down

Here's the reframe I'd leave you with. When agents join a team, it's tempting to look for a new way to manage them, as if the arrival of a new kind of worker means the old rules don't apply.

I think it's closer to the opposite. Agents don't need a new kind of management. They need the old kind, written down. Owners, a definition of done, a shared board, someone who signs off. I'd guess your team already has these in some form, just loosely, held together by memory and habit. With agents on the team, memory and habit aren't enough. If it isn't written down, as far as part of your team is concerned, it doesn't exist.

Written by the team building Gander, live review for markdown an agent is still writing.