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.
Last month, for the first time, one of our customers’ agents reported a blocker.
Not into a log file nobody reads. Into the team’s digest – the same place its human teammates report theirs. The agent had a job, ran a task as part of that job, hit something it couldn’t resolve, and 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 building for them. That morning the joke stopped being one. Part one of this series ended by saying the next turn – the agent with a whole job of its own – was already starting. This is what starting looks like.
To be clear: an agent isn’t equal to the people on the team, and this post won’t pretend otherwise. It’s software with a job – and software with a job needs the same coordination loops as anyone else who has one. That, it turns out, is the entire difference between agents that ship real work and the roughly nine in ten that don’t.
Single-player was the warm-up
Part one made the case that you’re already on a human-agent team: everyone runs their own AI, each person is a cyborg, and each cyborg is the conduit of context between their private sessions and everyone else. Single-player mode. The human is the bottleneck.
Multiplayer is a different arrangement entirely. The agent gets a job of its own – triaging tickets, drafting the release notes, watching the pipeline – and works it whether or not you’re at your desk. Multiple people depend on its output. Nobody is “operating” it. The question stops being how do I use this thing and becomes how does this thing work with the rest of us – which is a coordination question, and almost nobody is answering it.
The model isn’t the problem
Roughly nine of ten enterprise agent deployments fail to ship real work. That squares with everything else we know: MIT’s NANDA study found 95% of enterprise gen-AI pilots produced no P&L impact (Fortune, 2025), and recently Scale AI’s Remote Labor Index put the failure rate on real autonomous work at 97.5%.
The industry’s diagnosis has mostly been: the agent needs to know more. Hence the memory gold rush – Mem0’s $24M, Interloom’s $16.5M, [Granola’s $125M Series
C](https://techcrunch.com/2026/03/25/granola-raises-125m-hits-1-5b-valuation-as-it-expands-from-meeting-notetaker-to-enterprise-ai-app/), all betting the fix is a better hippocampus. Part one covered why that’s pointed the wrong way for cyborgs – an agent that can read every byte still can’t tell you which of three open PRs is the real plan. The multiplayer version of the same mistake is worse, because now nobody’s even watching.
Run the failure cases back and capability is rarely the killer. The agent that spent all night building a feature the team descoped on Tuesday didn’t lack memory – the decision happened after its last sync, and nothing existed to tell it. The agent that duplicated a human’s work didn’t lack context – it lacked a place where the human’s intent was visible. Memory is not intent. Memory looks backward at what happened. A team runs on what everyone intends to do next, and on the accountability of reporting back against it. Perfect recall doesn’t make a good teammate. Showing up does.
Coordinating AI agents means the same loops, not a side channel
Part one laid out the two coordination loops that keep a team coherent – the big-picture loop tying plans to progress, the ground-level loop keeping teammates in sync – and the Continuous Coordination methodology behind them. We won’t restate that here.
What matters for this post: look at how agents get deployed today, and you’ll find them outside both loops. They’re bolted onto a work-tracking tool, dumping output into a channel, their state buried in run logs and a dashboard someone checks when things smell wrong. Coordinating AI agents this way means a human standing between every agent and the team, translating – which is single-player mode wearing a trench coat.
The fix is almost embarrassingly simple to state: put the agent in the same loops as the people. 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. It shows up in the digest between two human teammates, not in a separate agent console someone has to remember to open.
Incumbents can’t really follow us here, and it’s worth being plain about why. Bolting an agent into an execution tool speeds up the fragments – more tickets touched, more docs drafted – while the loops stay open. Closing both loops for people and agents in one system is a different architecture, and it’s the one Steady is built on.
Standups for agents, on an actual Tuesday
Concretely, the agent participates in the coordination the team already does – no new ritual, no babysitting dashboard:
- It checks in. Intent first – “here’s what I’m picking up and why” – results after. That’s the standup, minus the meeting.
- It updates goals. Goals for agents aren’t separate agent OKRs; the agent posts progress to the team’s goal, so the big-picture loop stays current without a human transcribing.
- It raises blockers forward. Into the digest, where a teammate sees it in the morning – not into a log, where someone finds it in a post-mortem.
One of our customers runs an agent named Charlie this way. Because Charlie checks in like everyone else, the team can see exactly where it drifts – so they tune its prompts the way you’d coach a junior teammate. The loop is what made the agent worth investing in. If you want to try this today, agents connect over MCP, API, or CLI, and the Steady Playground has open demos to poke at.
Speed is why this stopped being optional
Part one did the arithmetic on drift at 20mph versus 80mph. Multiplayer raises the stakes again: the misaligned agent isn’t just fast, it’s unattended – the pileup happens overnight, at volume, with nobody in the car. That’s the story under every “vibe slop” and wasted-token headline.
Which is why autonomy has to be earned, and the loop is how agents earn it. An agent that declares intent and reports back builds a record you can check – and a record you can check is the only rational basis for approving fewer of its actions over time. You’re not extending human-style trust to a piece of software; you’re trusting a loop with a track record. Trust the loop, loosen the leash. (Where that leads – approval gates coming off entirely – is the last post in this series.)
The record is the point
One more thing happens when agents join the loops, and it’s the quiet one that matters most. Every check-in and every goal update – human or agent – lands in one shared record of what the team intended and what it accomplished. That record is why one trading firm runs 35 teams on it and ships 3X faster, and why another customer went from one team to 25 across 20 countries. It compounds. And in a world where the models doing the execution are rented by the token, the coordination record is the layer your team actually owns.
Your agents are already working. The only question is whether anyone – including them – knows what the rest of the team is doing.
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 →