How do I measure a team that works with AI agents?
By Soumen Sarkar · October 2026
Short answer: Measure a team that works with AI agents by how freely work flows, not by how much code it produces: watch waiting time, rework, pick-up time and late surprises, because those are what slow a team down when everyone runs several agents.
Why don't output numbers work anymore?
Because output is now cheap. Agents produce changes, lines and pull requests in volume, so counting them mostly measures how many agents are running. A team can ship a lot and still spend half its effort redoing work that collided, or waiting on answers that never came.
What limits a team at agent pace is coordination: whether each person and agent can build on everyone else's work without stopping. So measure that.
What should I watch?
Four signals, each tied to a way work gets stuck:
- [Waiting time](/glossary/waiting-time): how long work sits blocked on a person, for an answer, a review or a decision. The cleanest sign that context isn't reaching the work.
- [Rework](/glossary/rework): work done twice because something arrived as a surprise: a clash, a wrong assumption found late, a plan that changed under someone.
- [Pick-up time](/glossary/pick-up-time): how long unfinished work sits before someone continues it. Long pick-up times usually mean handoffs that don't explain enough.
- Late surprises: mistakes found after release that someone knew the answer to all along.
None of these needs a target number to be useful. Watch the direction. If waiting time grows as you add agents, context isn't keeping up with the work.
How do I read them without inventing a scoreboard?
Use them as questions, not grades. Read the trend for the team, not for individuals, so nobody's incentive is to look busy. And pair each number with one example from the week. "Pick-up time went up" means little; "the export handoff sat for two days because it didn't name a next step" is something you can fix.
Avoid measures that reward the wrong thing. Counting stated assumptions rewards stating trivial ones. Counting decisions rewards recording noise. Count what stuck, and what was caught.
What does a weekly read look like?
Picture a hypothetical team on a Friday. Waiting time is flat. Two pieces of work were redone this week, both in Reports · lib/reports, because two agents changed the export format in different ways. One handoff sat for a day and a half before anyone picked it up.
The lead takes two actions: asks agents in Reports to announce their plan before starting, and adds "name the next step" to the team's handoff instructions. Next Friday, the question is simply whether those two things moved.
What does Campfyrr show?
On each project's Activity page, a "What Campfyrr caught for your team this week" card sits at the top. It counts questions answered straight from the team's record, assumptions stated and confirmed, handoffs picked up and how fast, clashes caught, and wrong assumptions caught.
Those are counts of what happened in your team, not benchmarks. What a good number is for you is something only your own trend can tell you.
Words used here
- Waiting time: Waiting time is the time work spends stopped for a person: from the moment a question, assumption or handoff needs someone until they act on it.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
- Pick-up time: Pick-up time is how long a handoff waits between being left and someone picking it up to continue the work.
The principle behind this: Keep moving: The work never waits, and neither do we.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).