Collective Intelligence and AI, Part 3: What designing for collective intelligence could look like

My previous post ended with a question: if the answer can’t be “work alone, but better” or “add more AI to compensate,” what is the answer? But before getting into that, there’s a counter-argument I want to unpack.

Throughout these posts, I’ve talked about the ways that AI can prevent us from working effectively as teams, referencing examples like NASA’s Apollo mission and Wikipedia as what good can look like. But I also accept that these are more the exception than the rule.

For most people working in large organisations, the experience hasn’t been NASA’s Apollo missions. It’s meetings that should have been emails, decisions getting watered down until they mean nothing, politics that block good ideas, and a coordination tax that exhausts people. The companies I mentioned earlier are remarkable in part because they’re rare. The current default of collective work isn’t collective intelligence, it’s friction. So, when someone says “AI lets one person do what used to take a team”, they’re often really saying: “AI lets one person escape the coordination pain that was producing very little anyway.” That isn’t a fantasy, it’s a reasonable reaction based on what most of us have experienced when working in these companies.

This makes the one-person plus AI story less about selfishness and more like a relief. When you’ve spent significant time in an organisation trying to do good work but feel like the machine is working against you, the prospect of being able to do it alone is actually quite freeing. It’s understandable why that would appeal, and I’m not going to ignore that.

The gap I see is that this treats these features of large organisations as synonymous with all collective working, as if bureaucracy, endless painful meetings and bad management are inevitable when large groups work together. They’re not. They’re symptoms of particular forms of organisation, often inherited from command-and-control structures that were popular in the 20th century for a different type of economy.

The examples I mentioned also aren’t accidents; they are products of intentional design. Designing an organisation that can coordinate TSMC’s thousands of specialists, or systems that can enable Wikipedia’s editorial process, takes effort. Most organisations don’t put this much effort into cultivating collective working and intelligence. If anything, most prioritise efficiency over anything else.

The pains of collective working aren’t inherent to large organisations; they’re a symptom of the way our organisations are designed. But rather than tackling these organisational problems, it can feel easier to reach for AI as a quick fix. Instead, we should be trying to design organisations that make it easier to do collective work, rather than leaving it to chance.

There’s a problem with using AI to escape this pain, which is that it doesn’t work. As a solo founder plus AI scales a business and faces more complex problems, they have three common pains, and they all look pretty familiar to the organisations they thought they’d escaped:

They can try to handle everything themselves, with all decisions and reasoning happening in one head, invisible to anyone who might help.
They can try to keep up with every AI tool’s output, but they can quickly be overwhelmed by the volume of stuff to review.
They can manage at arm’s length, trust the agents to handle it, and discover problems only after they’ve compounded — which is identical to managers who don’t really know what’s happening two levels down, trust their reports, and learn about problems too late.

The one-person plus AI architecture doesn’t solve these coordination challenges; it just changes who the manager is delegating to and often makes the situation worse. Where a team member can raise their hand and say “I think we should rethink this”, an AI agent just does as it’s told.

This story isn’t just being told for solo founders. There’s a similar story reshaping some of the biggest companies in the world: lay off ten thousand people and let AI fill in, treating people like a cost or a friction that technology can swap out, rather than a source of collective intelligence that we should design our organisations to support better.

Layoffs can happen for many reasons, and the “AI did it” framing is sometimes more PR than reality, but the argument being used is consistent. It treats the people who do the work as line items rather than as the sensing, judging, modelling apparatus that made the company capable of doing the work in the first place.

None of this means we should romanticise collective work. Most large organisations are painful, and most of what passes for collaboration isn’t producing collective intelligence, just more meetings. But the answer isn’t to escape collective work entirely; it’s to design it better. AI is probably the most interesting tool we’ve had in decades for trying to make that happen, but we need to think carefully about what that looks like.

There’s no finished playbook for what designing for collective intelligence actually looks like. This area is still very new, the problems are complicated, and most of the experimentation is happening in small ways or behind closed doors. We do know there are directions worth exploring, and it’s worth being concrete about what they could look like.

This isn’t just a tech fix. For this to work, two areas have to work together: the design of the tools themselves, and the design of how people work around them. On one side, we need AI that mediates between people rather than replacing them. On the other, we need practices that use those tools to produce collective intelligence rather than degrade it. Just tackling one of these won’t be enough. At the moment, there’s growing interest in the AI side, but almost no work on tackling the messy problem of how teams need to change.

Imagine a design team has been given a brief for a new product feature. Rather than one designer sitting down with an AI tool to generate explorations on their own, the team builds up shared context together over the course of a week. The researcher has conversations with a few stakeholders and adds the notes to a shared space: what they heard, what stood out, what surprised them. Someone in engineering gives updates on relevant work the team did six months ago that’s connected to this. Other team members add things they’ve noticed, references they’ve encountered, questions they’re holding. AI can dig into context and history: pulling in existing personas, surfacing past attempts at similar problems, finding related material from elsewhere in the organisation, and organising what the team has been contributing so that it’s accessible to everyone. The work isn’t happening in private chats; it’s in a shared place that everyone can see.

When the team comes together for a working session, they’re not starting from a blank page. Everyone arrives with context, the AI has organised what’s been contributed and made the connections visible, and there’s enough on the table to do the real collective work. The session is for refining the brief, identifying what’s still missing, sharing inspiration, working through tensions, and arriving at the next steps and decisions together. It ends with a clearer brief, agreed actions, and clear ownership of what happens next. All of it, the contributions over the week, the working through, the conclusions, stays in the shared space so that the next time the team picks up related work, there’s something to build on rather than starting from scratch.

This shape isn’t unique to design. The same pattern works for a product team scoping a feature, a research team planning a study, a leadership team setting strategy. The specifics differ, but the underlying move is consistent: collective working distributed across time, AI supporting the organising and connecting work, humans doing the judgement, the inspiration and the deliberation, and a shared memory that grows with each cycle.

There are a few things this scenario shows us about how we can design for this.

First, the role of the AI. It isn’t generating the thinking; that’s happening between people, in the researcher’s conversations, the engineer’s recall of past work, and the team’s collective working session. What AI is doing is connective: pulling in context, organising what people contribute, and making relevant information visible. It’s a much more modest role than the default “give me a draft” mode, but it’s more useful for collective work. Generating drafts is the easy part of knowledge work, whereas understanding what to draft and why is the hard part, and that’s where collective intelligence lives. Using AI as connective tissue rather than as a draft engine keeps people engaged in the hard work where it’s most useful, while using AI for the parts it’s actually good at.

Second, all of this is happening in shared space. All of the team’s contributions, the AI’s organising work, the working through, and the outputs are visible rather than in private chat sessions. Everyone can see what others have brought, what the AI has surfaced, what’s being decided and why. This directly addresses one of the biggest costs of current AI tools: thinking has moved into private chats and become invisible to the rest of the team. Bringing the thinking back into shared space, with AI inside it rather than separate from it, is what lets a team build a shared understanding of progress over time.

Third, the working session is for actually doing collective intelligence work, not just sharing information. Because everyone can join with context already, the time together can be spent on what’s really valuable: surfacing tensions, finding the gaps, sharing inspiration, working through disagreement, deciding what to do next. The session has substance because people are building on each other, not just reporting. It’s the kind of meeting people actually find productive, and it couldn’t have just been an email.

Fourth, the team’s variety is preserved and amplified, not flattened. The researcher brings what stakeholders are saying, which no one else can. The engineer brings knowledge of past work. The AI brings what the organisation already knows. Each contributes something independent. This is the opposite of the default mode, where one person’s prompts create AI outputs that the same person then reviews: just one perspective getting amplified rather than many perspectives interacting. The shape of how the work happens determines whether the team has access to the diversity that makes collective intelligence possible.

These are early patterns, and there are more to explore. The wider problem of how to design tools and organisations that produce collective intelligence is open. There are many possible moves available:

Rituals and practices that protect deliberative work from being crowded out
Tools that make different perspectives visible rather than synthesising them away
Ways of structuring teams so the variety in them is actually used
Ways of hiring and composing teams that take social skills as seriously as individual capability
Ways of building shared memory that persists across projects and people

These need genuine experimentation, and probably need to be worked out in the specific contexts of different teams and the work they do.

At the start of this series, I quoted Sam Altman’s vision: one person and 10,000 GPUs. It’s a vivid image, and it’s becoming the dominant story about what AI is for. But it’s not the only one available. The same technology, designed and used differently, could produce a different shape: groups of people whose collective intelligence is amplified by tools that help them think and work together.

This isn’t a fight between AI and humans; it’s a choice about what AI is used for. Both futures are available, but right now the first one is winning. Partly because it has the clearer commercial case in the short term, and partly because the second is harder to build. Articulating what designing for collective intelligence looks like, and then actually doing it, is messier than empowering one person with better tools.

That’s the part I’m most interested in. There isn’t much being said yet about what this can look like in practice, and most of what exists focuses on the tool side without much on how teams need to change around them. If you’re working on tools that enable rather than replace, or on team and organisational shapes that use these tools well, I’d be interested to hear what you’re learning. The shape of this alternative will emerge through people trying things and sharing what they find.

Building teams and groups where they can do their best work and collaborate to overcome challenges has always been something I’ve been drawn to. There’s already enough thinking and practice in this space to be useful, even without a finished playbook. If these patterns are showing up in your organisation, or you’re trying to build teams and tools that don’t produce them in the first place, I’d be interested to talk and work together.