The Convergence Gap

There's no question that the making part of our work has gotten easier and faster. A single person can research an idea, stand up a prototype, test a workflow, and revise it in an afternoon, without waiting for anyone to assemble around them.

And obviously, I'm all for it. Small teams can stay close to the problem and follow a question far enough to find out whether there is anything there, and by building we can all make our thinking tangible rather than trying to explain it through documents and meetings.

It's clearly working, and we aren't giving it up. But as more people and agents work this way, a different problem is showing up.

§ 01Making all the work visible

One response to all this independent work has been to build better systems for accessing and tracking it all. Organizations are creating "shared knowledge" platforms that collect project activity, decisions, discussions, research, code, experiments, prototypes, customer evidence, and more.

Agents come in and help organize all that material. They summarize what happened, connect related efforts, retrieve past decisions, and bring context into your conversations.

The result is a shared memory that can be used by both humans and agents. Good, great even! Teams can't coordinate around work they can't see.

But shared visibility only gets an organization so far. What these systems make visible is mostly the artifact: the prototype, the summary, the decision, the finished output. The reasoning that produced it now tends to live somewhere the platform can't reach, inside a prompt, a chat thread, a local file, or one random person's workflow.

So the work gets more visible than it's ever been, while the thinking behind it is more private than it's ever been.

A platform can tell us what happened. It cannot, by itself, tell the organization what to do about it.

§ 02What is all this context for?

The more context we collect, the more I have to ask: what should all this knowledge change?

I mean, if teams are expected to operate independently, why are we collecting all this knowledge? Is the goal simply to make everyone more aware of what everyone else is doing? Or should it change what the organization believes, funds, stops, or builds next?

A small team may run a useful experiment. Another may discover that the original market assumption was wrong. A third may build a technical capability that changes what is possible. An agent may notice that several projects are encountering the same problem.

All of that can be "visible" without ever affecting the direction of the organization.

The way I see it, collecting the work solves one problem: people and agents can find it. It doesn't solve the next one: when should separate work begin to affect one another?

§ 03The missing layer is convergence

Context is great, but the real missing piece is a way for these independent threads to affect the direction of the larger team.

We need convergence.

Convergence is the deliberate point where separate threads bring forward what they have made and learned, compare it with what others are seeing, and decide what changes. It's the moment those independent threads close into a loop, feeding local learning back into the shared direction.

It does not mean placing everyone in every meeting. It does not mean forcing agreement before anyone can explore an idea. It does not require every independent effort to become a large team project.

A convergence point might reveal that Product, Engineering, Design, and Research are working from different assumptions. It might show that several teams have encountered the same problem. It might expose that a local prototype has implications for a wider product or platform direction.

The important part is not that the work was presented. It is that something changes because the threads came together.

A belief changes. A decision changes. An investment changes. A project stops. Two efforts combine. A new question becomes central.

Independent threads produce local learning. Convergence determines what the wider team learns from it.

§ 04Productive fragmentation

Without convergence, organizations can be highly active without becoming much... smarter. Independent teams build. Agents collect, summarize, and connect the output.

Each thread may be fast and effective on its own, but the learning doesn't really ever move between them.

There is a particular way I've seen this fail that is worth naming. One person makes something, and instead of thinking it through together, the next person feeds it into their own thread to consume, summarize, and remix. A new thread appears, but the original reasoning was never questioned.

The artifact gets used, the output changes, but shared judgment goes nowhere, and collaboration gets replaced by ingestion.

The work crossed from one thread into another, but the people and reasoning never converged.

The costs of this compound, with teams exploring the same questions in separate threads without ever realizing it. And decisions don't have a clear trail of the assumptions and tradeoffs behind them, so people sign off on an output without understanding the reasoning that produced it. All that strong "alignment" we thought we were getting with all that context sharing is actually super brittle.

Eventually, the organization returns to familiar plans and discussions. Everyone is moving. Every project has activity. The knowledge system is full. But the organization has no dependable way to decide what all of it means.

The danger isn't disorder, it's fast fragmentation that an org thinks is progress.

The difference is easy to feel when you see it. Flip between the two below.

§ 05Convergence should not happen constantly

The answer is not more coordination everywhere. Independent threads are useful partly because they protect early work from unnecessary negotiation. A small team should be able to test an idea without first gaining agreement from every function that could eventually be affected.

I also think premature convergence weakens exploration, by pushing teams to get consensus before they have any evidence. So the goal isn't constant alignment, it's intentional convergence.

Teams don't need to converge all the time, but they need to know when their work has reached a point where it should connect with other threads.

So when does it matter? A few of the moments worth stopping for:

§ 06Preparing for convergence

Of course, good ol' agents can help us here too. They can identify when threads should connect, they can detect patterns across projects, retrieve relevant history, expose conflicting decisions or assumptions, and bring forward the work that matters.

They can also preserve what happened at a convergence point. Instead of recording only the final decision, they can maintain the reasoning, tradeoffs, and resulting changes so future humans and agents understand why the organization chose a direction.

But, even though an agent can prepare a convergence point, they can't really ensure that the right people engage with the meaning of the work or decide what the organization should do next.

Someone still has to interpret what the separate threads have learned, understand the consequences, resolve tradeoffs, and biggest of all, accept responsibility for the decision.

Which people that get involved will depend on the question. A technical decision may need engineering and security judgment. A product direction may require customer, market, design, and delivery perspectives.

The point is not to get every specialty involved in everything. It's to avoid making consequential decisions inside a thread without the specialist judgment needed to understand their effects.

§ 07Designing for shared direction

The next generation of team platforms should not only help people and agents collect context, search knowledge, and see what everyone is doing. They should help teams recognize when independent work needs to converge.

They should help answer:

• Which independent threads now need to connect?
• What has each one learned?
• Where are they working from different assumptions?
• Who needs to interpret the implications together?
• What changes because of this convergence?
• How is that change carried back into the next round of work?

The image I keep returning to is not a straight process or a central command structure. It is a set of threads that keep closing into loops and opening again.

Humans and agents explore, build, and test independently. Each thread develops its own understanding of the work. At certain moments, the relevant threads meet. What they have made and learned is interpreted together, and the group decides what changes.

The threads separate again, but they do not leave unchanged. Each carries forward a clearer understanding of the shared direction and what the wider team has learned.

Try it: bring the threads together at a convergence point and watch what changes.