The Coordination Problem in Human-Agent Teams
As agents do more work, coordination gets harder, not easier
Everyone building with agents has spent the last year talking about capability. The models are better. They feel more adaptive. They can code, research, write, and take action, and a lot of us are already working faster because of it.
But, I think we’re about to run into a different pain point. Many of us are already feeling it.
The first wave of AI usage was mostly personal. Each person had their own assistant. The agent helped you write code, you research a topic, you clean up a document. It was powerful, but it was still basically an extension of one human.
The next phase looks different. Agents aren’t just helping individual people anymore. They’re starting to operate inside the team. They pick up tasks, write code, generate output, create follow-on work, and move things forward while the rest of the organization is doing something else. At that point, they stop feeling like a better tool and start feeling more like a teammate.
Running a human-agent team feels a little like playing quarterback when half your receivers are invisible. You know the play. You know where they should be. You know when the ball is supposed to come out. But when it’s time to throw, you’re guessing. You can’t really see who’s open, who changed direction, or whether somebody already broke the route off and is doing something else entirely.
If an agent is acting on your behalf, the rest of the team needs to know what it’s doing. Not in some vague way. Literally. What is it working on right now? What decisions did it already make? Why did it choose that path? What code did it write? What output did it produce? Is it blocked? Did it finish and quietly spin off two more threads of work?
In theory, you can ask the agent. In practice, that doesn’t really hold up. Sometimes the agent doing the work is buried inside a Codex or Claude Code session. Sometimes it’s a sub-agent you don’t have direct access to. Sometimes the work is technically visible, but only if somebody wants to read through terminal output, scrollback, or a long chat log. That’s not really communication. That’s reconstruction after the fact.
I run into this pretty often now. I’ll wrap up for a while with an agent still working, which still feels a little magical. Then I come back a few hours later and realize I’ve lost the narrative. I don’t have the thread in my head anymore. Now I’m re-reading terminal output, scanning chat history, or asking the agent to catch me back up on what happened while I was gone. It works, but it doesn’t feel especially efficient.
And the problem gets worse as soon as you move from one operator to an actual team.
If I’m working through agents, how does the next person know what I have in flight? If product wants to jump in, where do they go? If leadership wants to understand momentum, risk, or where time is actually going, how do they see that without living inside the harness too?
A lot of this comes directly from my own Clarabit discovery work. Clarabit started as a homegrown platform I built called LaunchPad. At the beginning, it was closer to a kanban board and task manager for me and my agents. Then I wanted better docs, especially a markdown editor with Google Docs style comments that agents could read, resolve, and add to. Then I kept running into adjacent problems, agent monitoring, context management, deployment key management, workspace isolation, session tracking. Over time it stopped feeling like a task system and started feeling more like a shared workspace for me to work alongside agents and other people.
That evolution connects pretty directly to the Dark Factory model. Once software starts getting built this way, the bottleneck shifts. It isn’t just about whether an agent can produce output. It’s whether the humans around that work can still see it, understand it, and coordinate around it.
The recurring issues weren’t random. They kept clustering around the same things. Visibility into what agents are doing. Session tracking. Context management. Audit trails. Workspace isolation. Better ways to understand why an agent made a choice, especially after the immediate working context is gone. Not because those are nice enterprise features to add later, but because once agents start operating inside a real organization, communication and coordination become first-order problems.
You can see it in the product direction pretty clearly. One thread is agent visibility and session tracking, a single place to see what every agent is doing across projects, whether it’s moving, stalled, blocked, or done. Another is context management, not just giving an agent access through a CLI, MCP server, or API, but helping people understand what context the agent had when it made a decision. Another is workspace and secret isolation, making sure the right agents have the right context and nothing more.
Communication is the backbone of a functioning company. Shared awareness matters. Clean handoffs matter. Trust matters. Traditional teams already struggle with that. Human-agent teams make it stranger because some of your teammates are non-human, some of the work is happening inside opaque systems, and a lot of the people responsible for outcomes aren’t sitting in the harness all day.
And just exposing the platform through a CLI, MCP, or API doesn’t solve that by itself. That mainly gives agents a way to act inside systems that were designed around human work patterns. Useful, yes. But it doesn’t create better points of communication between humans, agents, and the rest of the org.
There’s also a subtler problem underneath all of this. With a human teammate, you can usually sit down and ask why they made a choice. You can get the reasoning behind a tradeoff. With agents, that thread is often much harder to recover. Maybe the sub-agent context is gone. Maybe the session ended. Maybe all you have is the output and a fuzzy sense that it seemed reasonable at the time.
A lot of what teams need here is simple to describe and hard to build. What is in motion? Why did it move that way? What context was used? What changed? What matters now? Who needs to know?
If one person becomes the interpreter between leadership, teammates, and a cloud of agents, then that person becomes the bottleneck. The company didn’t become AI-native. It just created a new dependency around the person closest to the harness.
That’s a big part of the Clarabit thesis for me.
The opportunity isn’t just helping one person get leverage from one agent. It’s helping real teams operate when work is being done by a mix of humans and agents, and when both sides need to be visible to each other.
I don’t think we know the ideal org chart for an AI-native company yet. I don’t think we know the perfect communication patterns either. But I do think this is where the real work is. Not just making agents more capable, but making organizations actually able to work with them.
Related reading: