What Changes When an AI Agent Joins Your Team

Adding an AI agent to a team looks like adding a tool. Someone installs it, a few people start using it, and it gets better over time. That picture is wrong in a way that causes problems later. An agent is closer to a new member of the team who works very fast, never takes a holiday, does not remember last week unless someone tells it, and cannot be held responsible in the way a colleague can.

Teams that adopt agents well treat them as participants, which means deciding who owns their work, who checks it, how work moves between people and agents, and what record is kept. None of those decisions happens by default, and each one has a cost if it is left until something goes wrong.

Work that appears from nowhere

The first thing a team notices is that output rises. Drafts, summaries, analyses and first attempts at code arrive quickly, sometimes faster than anyone asked for them. That is useful, and it is also a new load. Work that used to be limited by how long a person took to produce it is now limited by how long someone takes to review it.

The agent's speed moves the bottleneck. A team that does not plan for that finds itself with a growing pile of unreviewed output, some of which is wrong, and no one clearly responsible for deciding which is which.

The useful question is therefore not how much the agent produces but how much review it creates, and who does that review. The answer should be written down, not left to whoever happens to notice a problem.

Ownership: one name per agent

When an agent's output is wrong, a team needs to know who to ask about it. If the answer is "the agent" or "whoever was using it", the problem will sit until it gets worse.

Name an owner for each agent and for each workflow it runs. The owner is responsible for three things: the agent's configuration, including its tools and permissions; the quality of its output over time; and the decision to keep relying on it. This is not a technical role alone. It is closer to the owner of a process, and it needs enough authority to change what the agent may do.

Ownership should be visible. A person who did not set up an agent should be able to find out in a minute who owns it, what it is for, and how to switch it off. Agents that run in the background and belong to nobody are the ones that surface in incident reports.

Review that matches the risk

Not all agent output needs the same checking. A summary of a meeting that a colleague will skim is low risk. A change to a production system, a message to a customer or a figure in a financial report is high risk. Treating them alike either wastes effort on the first or under-checks the second.

A practical approach is to tie the review level to the consequence of an error rather than to the agent's apparent confidence. Agents sound equally certain whether they are right or wrong, so the confidence of the output is a poor guide to how much to check it.

This connects to the approval question in which agent actions need a human to approve them. Review after the fact, of a sample of outputs, is a different discipline from approval before the action, and most teams need both.

Handoffs in both directions

Work moves between agents and people constantly, and the handoffs are where things get lost. An agent receives a task and produces a partial result. A person picks it up and does not know what the agent actually checked. Or a person passes a half-finished piece to an agent, which completes it in a way the person would not have chosen.

A good handoff to an agent states four things: the task and what done looks like; the inputs it may use; the actions it may take; and the point at which it must stop and return to a person. A handoff back to a person should say what was done, what was not, what the agent is unsure about, and where the evidence is.

Without those, the agent answers the task it thinks it was given, and the person accepts the result without knowing what was assumed. That mismatch is a common source of the failures that never throw an error, which we discussed in most agent failures never throw an error.

Coordination between agents

Some teams run several agents, each with a role: one gathers information, another drafts, a third checks. The pattern is attractive because each agent can be simple. It is also easy to overbuild. Each extra step adds latency and cost, and agents that check each other can share the same blind spots.

We have written about why multi-agent consensus collapses into hallucination and about the latency cost of stateful multi-agent loops. The organisational point is simpler: every agent role needs an owner and a handoff, or the chain becomes a place where responsibility disappears.

Research on simulated agent communities gives a useful picture of what coordination can look like. In the generative agents study, 25 language-model agents in a simulated town were given one starting idea, that one agent wanted to throw a party. The agents spread invitations over the following two days, formed new relationships and turned up at the right time. The paper's ablations found that observation, planning and reflection each contributed to believable behaviour. The lesson for teams is not that agents can run a party. It is that coordination emerges from memory and planning, and that a team which relies on it without visible records will not know how the work was actually done.

The record is the team's memory

An agent that does not remember last week, and cannot be asked why it did something, is a poor colleague unless the team keeps the record for it. The log should show what the agent read, what it decided and why, what it changed, and what it left unfinished.

This record does three jobs. It lets another person continue the work without starting over. It makes a mistake auditable, so the team can see whether the problem was the input, the instructions or the agent's reasoning. And it is the only way to improve the workflow with evidence rather than anecdote. A team that cannot read what its agents did cannot tell whether they are getting better.

The record also has to be kept honest. An agent's own summary of what it did is a claim, not a log. The useful records are of actions and inputs, which the runtime can capture, rather than of what the model says it did.

Time horizons and supervision

How long an agent can work without supervision is a practical planning question. The METR study estimates the length of software tasks that frontier models can complete with a 50 percent success rate, finding around 50 minutes for models of early 2025, and a doubling of that horizon roughly every seven months. The authors caution that the measure is about tasks with clear checks, and that a 50 percent success rate is not a standard to rely on.

For a team, the implication is that supervision should be planned around task length and checkability, not around a single view of whether agents are trustworthy. Short tasks with clear outcomes can run with light review. Long tasks with fuzzy success criteria need checkpoints where a person looks at progress, and a defined point at which the agent stops and asks.

What to decide before the first agent starts

1. Who owns each agent, and who can change its permissions.
2. Which outputs are reviewed, by whom, and how much, tied to the cost of an error.
3. The handoff template for work going to and from agents.
4. What log is kept, where, for how long, and who can read it.
5. How an agent is switched off, and who may do it.
6. How you will measure review time and rework, not only output.

Each question is cheap to answer before adoption and expensive to answer after an incident.

A trap to avoid

The most common mistake is to measure success by output and to add agents until output rises. That makes the review load grow faster than the team can absorb it, and the quality of what gets through falls. The second most common mistake is to assume that because an agent is fast, it can be trusted with the parts of the work that are hardest to check.

A better measure is the amount of work that reaches the outcome the team actually wants, with an error rate the team can live with, and with review effort that does not crowd out the work the team is best at. Output is the easiest number to count, and it is rarely the one that matters.

What we do not know

We do not know how the balance between agent output and human review will settle across teams, or whether review effort will fall as agents improve or simply move to harder questions. Most of what is known comes from early adopters, and organisational outcomes depend heavily on the work, the people and the incentives involved. The practical advice is to decide ownership, review and records first, and to measure the review load honestly, since that is where the cost of an agent actually shows up.