This is the second of a 3-part series on human-agent teamwork. Part one covered “single-player” mode, in which team members run their own agents independently. This article covers “multi-player” mode, in which autonomous agents join teams. Part three takes the long view: what teams look like once human-agent teamwork is the default, not the exception. We’ll link to part three here once it’s published.
Earlier this year, one of our customers’ agents reported a blocker.
Not into a log file nobody reads. Into the team’s shared daily update – the same place its human teammates report their blockers. The agent monitors and maintains the customer’s IT infrastructure. When it encountered an issue it couldn’t resolve, it said so. A person picked it up the next morning, the way you’d pick up any teammate’s blocker.
We’d been half-joking about standups for agents since we started deploying them internally. That morning the joking stopped.
An agent isn’t equal to the people on the team. But it is software with a job. And software with a job needs the same coordination loops as anyone else who has one.
Single-player was the warm-up
Part one of this series made the case that you’re already on a human-agent team. Everyone runs their own AI. Each person is a cyborg, carrying context between private agent sessions and the rest of the team. Single-player mode.
Multiplayer is different. The agent gets a job of its own – triaging tickets, drafting release notes, watching the pipeline – and works whether or not you’re at your desk. Multiple people depend on its output. Nobody is sitting there operating it.
The question changes from how do I use this thing to how does this thing work with the rest of us.
Memory is not intent
Most multiplayer agent projects still don’t ship real work. MIT’s NANDA study found 95% of enterprise gen-AI pilots produced no P&L impact (Fortune, 2025). Scale AI’s Remote Labor Index put the failure rate on real autonomous work at 97.5%.
The usual diagnosis is that the agent needs to know more. Give it more memory. Open a bigger context window. Connect another source.
Run the failure cases back and the problem is often simpler. The agent that spent all night building a feature the team descoped on Tuesday didn’t lack memory. The plan changed after its last sync. The agent that duplicated a human’s work didn’t need a bigger context window. It needed to see what the human was about to do.
Now turn that around. Before the agent starts, it declares what it’s about to do and why, based on real-time pull of context from the team. A person can glance at that intent, spot a wrong turn, and stop it before the agent spends the night producing the wrong work. That’s how you keep humans in the loop without making them approve every action.
Memory tells the agent what happened. Declared intent tells the team what is about to happen, before a wrong turn becomes an overnight token bill, a week of throwaway work, or damaged infrastructure.
Put agents in the same loops
Most agents sit outside the team’s coordination loops. They’re bolted onto a work-tracking tool, dumping output into a channel, with their state buried in run logs and a dashboard someone checks when things smell wrong. A human still stands between every agent and the team, translating. That’s single-player mode wearing a trench coat.
Instead, put the agent in the same loops as the team. It declares intent before it works. It reports what it did and what it couldn’t do. It updates the goal it’s contributing to. Its update appears alongside those of its human teammates, not in a separate agent console someone has to remember to open.
Standups for agents, on an actual Tuesday
Here’s how this works on a normal Tuesday. The agent participates in the same async standup as the rest of the team. No new ritual, and no separate place to check.
- Before it starts, it checks in. “Here’s what I’m picking up and why.” That gives everyone a chance to spot a conflict, add missing context, or stop the work before it starts.
- As it works, it updates the team’s goals. The agent connects its progress to the same goal as everyone else, so the team can see whether all that activity is moving the plan forward. No human has to translate or transcribe.
- When it gets stuck, it raises the blocker where people will see it. A teammate can pick it up in the morning and get the agent moving again. The failure doesn’t sit buried in a run log until the post-mortem.
By the time the team starts its day, the agent’s work isn’t a mystery. They can see what it planned to do, what it accomplished, and where it needs help – the same things they’d expect to know about any teammate.
Speed is why this stopped being optional
Part one compared team drift at 20mph with team drift at 80mph. Multiplayer raises the stakes again. The misaligned agent is unattended. The pileup happens overnight, at volume.
Autonomy has to be earned, and the team loop is how agents earn it. An agent that declares intent and reports back builds a record you can check. That record gives you a rational basis for approving fewer of its actions over time. You trust a loop with a track record, then loosen the leash.
The record is the point
Every check-in and every goal update – human or agent – lands in one shared record of what the team intended and what it accomplished. One customer runs 35 teams on that record and ships 3X faster. Another grew from one team to 25 across 20 countries.
The models doing the execution are rented by the token. The coordination record is the layer your team owns. It compounds with every turn of the loop.
Steady is the human-agent teamwork OS – it keeps people and agents coordinated automatically by running team-wide loops of intentions and accomplishments. Put an agent in the loop.