Three Layers of Collaboration: Why They Have to Run at Once

A scene from last quarter, all happening inside ninety minutes.

A logistics founder and our product lead were in a room talking about how dispatchers handle a specific kind of urgent reroute. The founder was sketching on paper. Our product lead was asking the kind of questions you can only ask if you've shaped a dozen products before. Two humans, thinking together.

While they talked, one of our engineers had three agents running on a separate screen. One was generating UI variations for the dispatcher view based on the brief we'd written earlier that morning. Another was checking the proposed data model against the constraints in our integration spec. A third was watching the first two and flagging where their outputs would conflict if shipped together.

By the time the founder finished sketching, the engineer had a working prototype to react to. The founder pointed at one of the variations and said "no, the time-to-pickup needs to be more prominent than the destination." Our product lead asked why. The founder explained an edge case from his fifteen years of running routes. The engineer fed the constraint back into the agents. Eight minutes later, three new variations existed. The founder picked one.

Three layers ran the whole time. Two humans collaborating on what the product should be. Humans collaborating with agents to make options visible. Agents collaborating with other agents to keep the work coherent. None of those layers paused while the others worked. That's the whole point.

What are the three layers of human and agentic collaboration?

The layers have specific names because the distinctions matter.

Human ↔ Human. You (the person who knows the domain, the market, the customers) and our team (the people who've shaped a hundred products) thinking together. This layer has always existed in product development. What's new is what it can do. The barrier between "we discussed it" and "we saw it" used to be weeks. Now it's minutes. So the human-to-human conversation gets to operate at higher resolution and faster cadence than it ever could before. We wrote more about that shift in clients are co-creators, not a source of requirements.

Human ↔ Agent. Humans working with AI agents in real time. Not "the agent generates and the human approves," which is sequential and shallow. The deeper version: humans and agents in a continuous exchange where context flows in both directions, judgment is applied throughout, and the artifact (a design, a piece of code, an architecture decision) is shaped by both sides. We wrote about why this works only when you treat agents like collaborators rather than tools in a separate pillar.

Agent ↔ Agent. The layer most people don't know exists yet. Behind the human-visible work, AI agents orchestrate other AI agents. A code generation agent hands off to a testing agent, which feeds results back to a refactoring agent. Design agents explore variations in parallel. Deployment agents handle infrastructure. This is the layer that makes the speed possible. It's also the layer that makes the quality possible, because agents will run exhaustive checks no human team would have the patience for.

Each layer is doing different work, with different participants, at different speeds.

The diagram is useful because it forces a recognition: the value isn't in any one circle. Every consultancy on earth has the human-to-human circle. Most product teams now have something in the human-to-agent circle. A growing number of engineering shops have something in the agent-to-agent circle. None of those alone is a way of working. The overlap is.

Why are the three layers usually treated as phases?

The most common mistake we see is teams adopting the three layers but running them sequentially.

It goes like this. First, the humans get aligned on what to build. Then, the humans work with AI tools to build it. Then, agentic workflows handle automation, testing, deployment. Each stage is real, each stage uses AI, each stage looks modern. And the result is still waterfall.

This happens because phases are familiar. Most software organizations are built around phase gates: requirements, design, build, test, deploy. When you import AI into that structure, the layers naturally distribute across the phases. Humans collaborate up front. Humans collaborate with agents in the middle. Agents collaborate with each other at the end. Each phase improves a little. Nobody changes what they fundamentally do.

The phase model is what makes the work feel manageable. It's also what makes it slower than it needs to be and worse than it could be. Decisions made in the up-front human-to-human phase get fossilized in a document. By the time anyone notices the document is wrong, the agents are already executing against it. The feedback loop between the layers is broken because the layers don't overlap in time.

The layered model is harder to set up and easier to live in. It requires that humans and agents be in the same continuous exchange. It requires shared artifacts both sides update. It requires giving up the comfort of "we're in the design phase now" because there isn't a design phase, there's a continuous design conversation that runs from minute one to launch and beyond.

Teams that figure this out don't go faster because their agents are faster. They go faster because they stop building the wrong things. The simultaneity catches mistakes when they're still cheap.

Where does most of the value actually live?

The conventional way of answering this question is to argue for whichever layer the person asking is most interested in. Founders want to hear the human-to-human layer is the most valuable. Engineers want to hear it's the agent-to-agent layer. AI vendors want to hear it's the human-to-agent layer. We've watched all three versions of the argument get made.

The honest answer is that the question is wrong. The value doesn't live in any single layer because the layers don't produce value separately.

The human-to-human conversation about which problem to solve is worth almost nothing if the agents can't make a working version of it visible in the next thirty minutes. You'll get stuck in the same loops every product team has been stuck in for thirty years: "I think we need this," "we'll spec it and review next month."

The human-to-agent collaboration is worth almost nothing if there's no shared product thinking informing it. You'll generate fast, beautiful, confidently-wrong software. We've watched enough teams ship into that wall to know exactly what it looks like. We wrote about it in why vibe coding fails.

The agent-to-agent orchestration is worth almost nothing if the humans aren't shaping what it's optimizing for. You'll get an extremely efficient system delivering features nobody asked for to users who don't exist.

The value is in the interaction. When the human-to-human conversation about which problem matters most happens while agents are generating options while other agents are checking the generated options against each other, the feedback loops compress in a way that nothing else does. A domain expert points out a blind spot, twenty minutes later agents have explored the implications, the team converges on a better answer than any of them could have produced alone.

This is the part that's hard to communicate from the outside. Once you've worked this way, the old model feels like one of those time-lapse videos where every step happens in slow motion. Once you've worked this way, it's also hard to go back, which is what we hear from clients more than anything else.

What does this mean for how a team is structured?

Most teams structured for the old way of working have the layers separated by org chart. Product managers handle the human-to-human conversation with clients. Engineers handle the human-to-agent collaboration through their AI tools. DevOps and platform teams handle the agent-to-agent orchestration. Three layers, three teams, three sets of priorities.

The way of working we developed over hundreds of engagements breaks that structure on purpose. Our team has people fluent across all three layers, often in the same hour. The product lead who's deep in conversation with a client one minute is reading the trace of an agent-to-agent workflow the next, because the work demands both. The engineer running multi-agent orchestration also sits with the client to understand why a constraint matters. The roles haven't merged. The boundaries between them have softened, because the boundaries used to be drawn around what each person could operate, and that's not where the boundaries should be in the new model.

The boundary that matters now is judgment. Who knows the domain? That's the human-to-human anchor. Who knows the product craft? That's where humans guide agents. Who knows the technical architecture? That's where agents orchestrate other agents. The judgment stays specialized. The execution stops being.

When all three layers run together, the team's structure starts to reflect the work instead of the work reflecting the structure. The old way of working built org charts that mirrored handoffs. The new way of working builds collaboration that mirrors the problem.

That's the whole pitch in one line. Three layers, running at once. Not because it's elegant. Because that's how the work actually gets done now, and pretending otherwise is the slowest possible way to find out.