People Work in Teams, AI Assistants in Silos

As I was waiting to start a recent episode of Live with Tim O’Reilly, I was talking with attendees in the live chat. Someone asked, “Where do you get your up-to-date information about what’s going on in AI?” I thought about the various newsletters and publications I follow but quickly realized that the right answer was “some chat groups that I am a part of.” Several are on WhatsApp, and another on Discord. For other topics, there are some Signal group chats. Yes, the chats include links to various media sources, but they are curated by the intelligence of the people in those groups, and the discussion often matters more than the links themselves.

Later that day, I asked my 16-year-old grandson how he kept in touch with his friends. “I used to use Discord a lot,” he said, “but my friend group has now mostly migrated to WhatsApp. I have two groups, one with about 8 good friends, and a second one with a bigger group of about 20.” The way “friend group” has become part of the language for younger people is a tell. Groups matter.

A WhatsApp group is also how I keep in touch with my extended family. (Actually, there are several overlapping family groups, each with a slightly different focus and set of active members.) And there’s a Facebook group that my wife and I use to keep in touch with neighbors in the remote town in the Sierra Nevada where we spend our summers.

I’m old enough to remember the proto-internet of the mid-1980s, when Usenet groups were how people shared information, formed remote friendships, and built communities of interest. Email, which grew up as a sibling of Usenet, also developed some group-forming capabilities. Listservs (mailing list managers) were and still are a thing, but they were a sideshow compared to the fecundity of Usenet. Google Groups remains as a 25-year-old relic of that era, underinvested in and underused.

Later on, I used Twitter to follow the people I cared about and those whose work and ideas I wanted to keep up with. After Twitter made it difficult to see the feed of people I wanted to follow, replacing it by default with a timeline of suggested posts, I pretty much stopped using it. I still used Instagram to follow my friends and family; it used to be the first thing I checked every morning when my grandchildren were little and far away. But now, the people I want to follow are hard to find there too, buried by algorithmic suggestions, and so I visit the site only intermittently. Social software (the original name that Clay Shirky gave to applications like FriendFeed and systems like RSS that allow a user to curate a list of “feeds” to follow) gave way to social media. A multiplexed feed of content from the people I have chosen is social software, group-forming and empowering to individuals; an algorithmically curated feed of content that someone else thinks I will like is social media, divisive and disempowering.

For technology to do its best work for people, it has to provide support for groups. They are a fundamental part of the human social experience. But serving groups is hard. Consumer technology companies discover this opportunity, then abandon it with regularity, only for someone else to discover it again. We’ve all had this experience, I think. I am reminded of a marvelous passage from the Wallace Stevens’s poem “Esthétique du Mal”:

The tragedy, however, may have begun, 
Again, in the imagination’s new beginning, 
In the yes of the realist spoken because he must 
Say yes, spoken because under every no 
Lay a passion for yes that had never been broken.

There is a passion for groups that has never been broken. We’re going to keep reinventing them until every platform owner realizes that they are an essential part of the landscape and sticks with them. They are not just a way to attract users before abandoning them as part of the cycle of enshittification.

There is still a chance to get this right for AI. The imagination’s new beginning is cropping up at all levels, from LLMs themselves, where the advantages of hyperscaling seem to be slowing, reducing the likelihood of a winner-takes-all outcome, to protocols like MCP and A2A, to AI applications for teams.

AI Tooling for Teams?

In the enterprise world, there have long been products explicitly serving the needs of teams (i.e., groups), from Lotus Notes through SharePoint, Slack, and Microsoft Teams. 20 years ago, Google Docs kicked off a revolution that turned document creation into a powerful kind of group collaboration tool. Git and GitHub are also a powerful form of groupware, one so fundamental that software development as we know it could not operate without it. But so far, AI model and application developers largely seem to have ignored the needs of groups, despite their obvious importance. As Claire Vo put it to me in one recent conversation, “AI coding is still largely a single-player game.”

It is possible to share the output of AI, but most AI applications are still woefully lacking in the ability to collaborate during the act of creation. As one attendee asked on my recent Live with Tim O’Reilly episode with Marily Nika, “What are some tips on dealing with the fact that we are currently working in teams, but in silos of individual AI assistants?” We are mostly limited to sharing our chats or the outputs of our AI work with each other by email or link. Where is the shared context? The shared workflows? Claire’s ChatPRD (AI for product management) apparently has an interface designed to support teams, and I have been told that Devin has some useful collaborative features, but as of yet, there is no full-on reinvention of AI interfaces for multiplayer interactions. We are still leaning on external environments like GitHub or Google Docs to make up for the lack of native collaboration in AI workflows.

We need to reinvent sharing for AI in the same way that Sam Schillace, Steve Newman, and Claudia Carpenter turned the office productivity world on its head back in 2005 with the development of Writely, which became Google Docs. It’s easy to forget (or for younger people never to know) how painful collaborative editing of documents used to be, and just how much the original Google Docs team got right. Not only did they make user control of sharing central to the experience; they also made version control largely invisible. Multiple collaborators could work on a document simultaneously and magically see each others’ work reflected in real time. Document history and the ability to revert to earlier versions is likewise seamless.

On August 26, I’ll be chatting with Sam Schillace, Steve Newman, and Claudia Carpenter on Live with Tim O’Reilly. We’ll be celebrating the 20th anniversary of Writely/Google Docs and talking about how they developed its seamless sharing, and what that might look like today for AI.

What we really need is the ability to share context among a group. And that means not just a shared set of source documents but also a shared history of everyone’s interactions with the common project, and visibility into the channels by which the group communicates with each other about it. As Steve Newman wrote to me, “If I’m sharing that particular AI instance with a group, it should have access to the data that’s relevant to the group.”

In this article, I’m going to revisit some past attempts at designing for the needs of groups and make a few stabs at thinking out loud about them as provocations for AI developers.

Lessons from the Unix Filesystem

Maybe I’m showing my age, but so many ideas I keep going back to come from the design of the Unix operating system (later Linux.) But I’m not the only one. Back in 2007, the ever-insightful Marc Hedlund wrote:

One of my favorite business model suggestions for entrepreneurs is, find an old UNIX command that hasn’t yet been implemented on the web, and fix that. talk and finger became ICQ, LISTSERV became Yahoo! Groups, ls became (the original) Yahoo!, find and grep became Google, rn became Bloglines, pine became Gmail, mount is becoming S3, and bash is becoming Yahoo! Pipes. I didn’t get until tonight that Twitter is wall for the web. I love that.

I have a similar suggestion for AI entrepreneurs. Yes, rethink everything for AI, but figure out what to keep as well as what to let go. History can teach us a lot about what patterns are worth keeping. This is especially important as we explore how to make AI more participatory and less monolithic.

The Unix filesystem, which persists through Linux and is thus an integral part of the underlying architecture of the technological world as we know it, had a way of thinking about file permissions that is still relevant in the world of AI. (The following brief description is for those who are unfamiliar with the Unix/Linux filesystem. Feel free to skip ahead.)

Every file is created with a default set of permissions that control its access and use. There are separate permissions specified for user, group, and world: A file can be private so that only the person who created it can read and/or write to it, or if it is an executable file such as a program, run it. A file can belong to a group, identified by a unique numeric group ID in a system file that names the group, gives it that unique numeric ID and an optional encrypted group password, and lists the members who can read, write, or execute files belonging to it. Or a file can have “world” access, in which anyone can read and potentially write to it or run it. Every file thus not only has an associated owner (usually but not always the creator) but potentially also an associated group owner, who controls membership in the group.

This explicit framing of three levels of access seems important, rather than leaving group access as something that is sometimes available and sometimes not. I also like that Unix had a “little language” (umask and chmod) for compactly viewing or modifying the read/write/execute permissions for each level of access.

A file that is user readable and writable versus one that is, say, world readable but not writable is an easily understood distinction. But there’s this whole underexplored middle in what permissions can be given to members of associated groups. The chief function, as far as I remember it, was to allow for certain files to be editable or runnable only by members of a group with administrative access. But this is really only the tip of the iceberg of possibilities, as we shall see.

One of the drawbacks of the original Unix filesystem is that the members of groups had to be explicitly defined, and a file can only be assigned to one primary group at a time. While a user can belong to multiple groups, a file itself is associated with a single owning group. More modern versions of the system, like Linux, work around this limitation by providing Access Control Lists (ACLs), which make it possible to define specific permissions for multiple users and multiple groups on a single file or directory. Groups in systems like WhatsApp and Signal and Discord and Google Groups also use an ACL-type approach. Access rights are usually controlled by an administrator. This draws hard boundaries around groups and makes ad hoc group-forming more difficult.

Lessons from Open Source Software

People think that free and open source depend on a specific kind of license. I have always believed that while licenses are important, the essential foundation of open source software is the ability of groups to collaborate on shared projects. There are countless stories of software developed by collaborative communities—notably Unix itself—that came about despite proprietary licenses. Yes, the open source Linux took over from proprietary versions of Unix, but let’s not forget that the original development was done not just at Bell Labs but at the University of California, Berkeley and other universities and companies around the world. This happened despite AT&T’s proprietary license and long before Richard Stallman wrote the GNU Manifesto or Linus Torvalds wrote the Linux kernel.

There were two essential innovations that enabled distributed collaboration on shared software projects outside the boundaries of individual organizations.

The first is what I have called “the architecture of participation.” Software products that are made up of small cooperating units rather than monoliths are easier for teams to work on. When we were interviewing Linus Torvalds for our 1999 essay collection Open Sources, he said something like “I couldn’t have written a new kernel for Windows even if I had access to the source code. The architecture just wouldn’t support it.” That is, Windows was monolithic, while Unix was modular.

We have to ask the question: What is the architecture of participation for AI?

Years ago, I wrote the first version of the Wikipedia page about Kernighan and Pike’s book The Unix Programming Environment because that book so fundamentally shaped my view of the programming world and seemed like it had such profound lessons for all of us. Kernighan and Pike wrote:

Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can’t be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools.

What allowed that combination is the notion that every program produced its output as ASCII text, which could then be consumed and transformed by other programs in a pipeline, or if necessary, redirected into a file for storage. The behavior of the programs in the pipeline could be modified by a series of command line flags, but the most powerful features came from the transformations made to the data by a connected sequence of small utility programs with distinct powers.

Unix was the first operating system designed by a company that was, at its heart, a networking company. Unix was all about the connections between things, the space between. The small pieces loosely joined, end-to-end model became the paradigm for the internet as well and shaped the modern world. It was easy to participate in the collaborative development of Unix. New tools could be added without permission because the rules for cooperating applications were already defined.

MCP is a fresh start on creating an architecture of participation for AI at the macro level. The way I see it, pre-MCP the model for applications built with AI was hub-and-spoke. That is, we were in a capital-fueled race for the leading AI model to become the centralized platform on which most AI applications would be built, much like Windows was the default platform in the PC era. The agentic vision of MCP is a networked vision, much like Unix, in which small, specialized tools can be combined in a variety of ways to accomplish complex tasks.

(Even pre-MCP, we saw this pattern at work in AI. What is RAG but a pipeline of cooperating programs?)

Given the slowdown in progress in LLMs, with most leading models clustering around similar benchmarks, including many open source/open weight models that can be customized and run by corporations or even individual users, we are clearly moving toward a distributed AI future. MCP provides a first step toward the communications infrastructure of this multipolar world of cooperating AIs. But we haven’t thought deeply enough about a world without gatekeepers, where the permissions are fluid, and group-forming is easy and under user control.

There was a second essential foundation for the collaborative development of Unix and other open source software, and that was version control. Marc Rochkind’s 1972 SCCS (Source Code Control System), which he originally wrote for the IBM System/370 operating system but quickly ported to Unix, was arguably the first version control system. It pioneered the innovation (for the time) of storing only the differences between two files, not a complete new copy. It wasn’t released publicly till 1977, and was succeeded by a number of improved source code control systems over the years. Git, developed by Linux creator Linux Torvalds in 2005, has been the de facto standard for the last 20 years.

The earliest source code repositories were local, and change files were sent around by email or Usenet. (Do you remember patch?) Git was a creature of the internet era, where everything could be found online, and so it soon became the basis of one of the web’s great assemblages of collective intelligence. GitHub, created in 2008 by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett, and Scott Chacon, turned the output of the entire software industry into a shared resource, segmented by an inbuilt architecture of user, group, and world. There are repositories that represent the work of one author, and there are others that are the work of a community of developers.

Explicit check-ins, forks, and branches are the stuff of everyday life for the learned priesthood of software developers. And increasingly, they are stuff of everyday life for the agents that are part of the modern AI-enabled developer tools. It’s easy to forget just how much GitHub is the substrate of the software development workflow, as important in many ways as the internet itself.

But clearly there is work to be done. How might version control come to a new flowering in AI? What features would make it easier for a group, not just an individual, to have a shared conversation with an AI? How might a group collaborate in developing a large software project or other complex intellectual work? This means figuring out a lot about memory, how versions of the past are not consistent, how some versions are more canonical than others, and what a gift it is for users to be able to roll back to an earlier state and go forward from there.

Lessons from Google Docs

Google Docs and similar applications are another great example of version control at work, and there’s a lot to learn from them. Given that the promise of AI is that everyone, not just the learned few, may soon be able to develop complex bespoke software, version control for AI will need to have the simplicity of Google Docs and other office productivity tools inspired by it as well as the more powerful mechanisms provided by formal version control systems like Git.

One important distinction between the kind of version control and group forming that is enabled by GitHub versus Google Docs is that GitHub provides a kind of exoskeleton for collaboration, while Google docs internalizes it. Each Google Docs file carries within it the knowledge of who can access it and what actions that they can take. Group forming is natural and instantaneous. I apologize for subjecting you to yet another line from my favorite poet Wallace Stevens, but in Google Docs and its siblings, access permissions and version control are “a part of the [thing] itself and not about it.”

Much like in the Unix filesystem, a Google doc may be private, open to a predefined group (e.g., all employees with oreilly.com addresses), or open to anyone. But it also provides a radical simplification of group formation. Inviting someone to collaborate on a Google doc—to edit, comment, or merely read it—creates an ad hoc group centered on that document.

My aspiration for groups in AI is that they have the seamless ad hoc quality of the community of contributors to a Google doc. How might our interactions with AI be different if we were no longer sharing a fixed output but the opportunity for cocreation? How might an ad hoc group of collaborators include not only humans but their AI assistants? What is the best way for changes to be tracked when those changes include not just explicit human edits to AI output but revised instructions to recreate the AI contribution?

Maybe Google already has a start on a shared AI environment for groups. NotebookLM is built on the substrate of Google Drive, which inherited its simple but robust permissions architecture from Google Docs. I’d love to see the team there spend more time thinking through how to apply the lessons of Google Docs to NotebookLM and other AI interfaces. Unfortunately, the NotebookLM team seems to be focused on making it into an aggregator of Notebooks rather than providing it as an extension of the collaborative infrastructure of Google Workspace. This is a missed opportunity.

Core Versus Boundary

A group with enumerated members—say, the employees of a company—has a boundary. You are in or out. So do groups like citizens of a nation, the registered users of a site or service, members of a club or church, or professors at a university as distinct from students, who may themselves be divided into undergraduates and grad students and postdocs. But many social groups have no boundary. Instead, they have a kind of gravitational core, like a solar system whose gravity extends outward from its dense core, attenuating but never quite ending.

Image generated by Google Imagen via Gemini 2.5

I know this is a fanciful metaphor, but it is useful.

The fact that ACLs work by drawing boundaries around groups is a serious limitation. It’s important to make space for groups organized around a gravitational core. A public Google group or a public Google doc open to access for anyone with the link or a Signal group with shareable invite links (versus the targeted invitations to a WhatsApp group) draws in new users by the social equivalent to the way a dense body deforms the space around it, pulling them into its orbit.

I’m not sure what I’m entirely asking for here. But I am suggesting that any AI system focused on enabling collaboration take the Core versus Boundary pattern into account. Design systems that can have a gravitational core (i.e., public access with opt-in membership), not just mechanisms for creating group boundaries with defined membership.

The Tragedy Begins Again?

The notion of the follow, which originally came from RSS and was later widely adopted in the timelines of Twitter, Facebook, and other social media apps, provides an instructive take on the Core pattern.

“Following” inverts the membership in a group by taking output that is world-readable and curating it into a user-selected group. We take this for granted, but the idea that there can be billions of people posting to Facebook, and that each of them can have an individual algorithmically curated feed of content from a small subset of the other billions of users, only those whom they chose, is truly astonishing. This is a group that is user specified but with the actual content dynamically collected by the platform on behalf of the user trillions of times a day. “@mentions” even allow users to invite people into their orbit, turning any given post into the kind of ad hoc group that we see with Google Docs. Hashtags allow them to invite others in by specifying a core of shared interests.

And of course, in social media, you can also see the tragedy that Wallace Stevens spoke of. The users, each at the bottom of their personal gravity well, had postings from the friends they chose drawn to them by the algorithmic curvature of space, so to speak, when suddenly, a great black hole of suggested content came in and disrupted the dance of their chosen planets.

A group can be defined either by its creator (boundary) or collectively by its members (core). If those who control internet applications forget that groups don’t belong to them but to their creators, the users are forced to migrate elsewhere to recreate the community that they had built but have now lost.

I suspect that there is a real opportunity for AI to recreate the power of this kind of group forming, displacing those who have put their own commercial preferences ahead of those of their users. But that opportunity can’t be taken for granted. The race to load all the content into massive models in the race for superintelligence started out with homogenization on a massive scale, dwarfing even the algorithmically shaped feeds of social media. Once advertising enters the mix, there will be strong incentives for AI platforms too to place their own preferences ahead of those of their users. Given the enormous capital required to win the AI race, the call to the dark side will be strong. So we should fear a centralized AI future.

Fortunately, the fevered dreams of the hyperscalers are beginning to abate as progress slows (though the hype still continues apace.) Far from being a huge leap forward, GPT-5 appears to have made the case that progress is leveling off. It appears that AI may be a “normal technology” after all, not a singularity. That means that we can expect continued competition.

The best defense against this bleak future is to build the infrastructure and capabilities for a distributed AI alternative. How can we bring that into the world? It can be informed by these past advances in group collaboration, but it will need to find new pathways as well. We are starting a long process by which (channeling Wallace Stevens again) we “searches the possible for its possibleness.” I’d love to hear from developers who are at the forefront of that search, and I’m sure others would as well.

Thanks to Alex Komoroske, Claire Vo, Eran Sandler, Ilan Strauss, Mike Loukides, Rohit Krishnan, and Steve Newman for helpful comments during the development of this piece.

Read More

Artificial Intelligence, Deep Dive

Radar