Agents that collaborate

In 1967, the designers of Multics wrote that “a user is a person working on a project.”

The important word was working. Multics registered a person once, but asked at login which project they were entering. A password authenticated the person; the project named the capacity in which they would act. The same person could enter one project with broad access and another with almost none. The choice also determined which project was charged for the work and which limits governed the session.

As Multics evolved, this distinction entered the work itself. Every segment, directory, and link carried the identity of the process that created it in an author field that could not be changed. Access could be granted to one person everywhere, to everyone working on a project, or to one person only while working on that project. A link named an artifact but conferred no right to use it. Sharing and authority were separate acts.

Multics eventually stopped reusing registered names. Once a name appeared in access lists across the system, it could not safely be given to someone else: the newcomer might inherit authority meant for the person who had left. Work had made the name permanent.

A year later, J. C. R. Licklider and Robert Taylor described the other half of the future. A handful of interactive computing communities were already accumulating programs, data, and know-how. Within each, the work was “regenerative”: better systems supported better work, and that work enlarged the resources of the community. Between communities, almost nothing compounded. A program created at one installation was difficult even to discover and often nearly as expensive to adapt as it would have been to write again.

Computing had become personal before the personal computer existed. The personal computer would deepen that relationship. The network would make its products cumulative.

At Xerox PARC, Licklider’s idea became a working environment. An Alto was personal: one person controlled it, and work persisted locally. But personal did not mean self-contained. PARC connected roughly 150 Altos to shared storage, naming, mail, and specialized services. File servers held libraries, documentation, and what one internal guide called the “truth version” of systems built by several people. The Alto remained personal while becoming part of the work of the laboratory.

Networked, but alone

By early 2026, coding agents had crossed from answering questions to carrying out work. A person could open Codex or Claude Code inside a repository and ask it to trace a program, edit files, run tests, and stay with a change across hours. The first agents entered companies one person at a time. People adopted them because they were useful, often before their organizations had decided how they belonged.

They had recreated the personal half of the Alto, but not yet the laboratory around it. An agent could reach the internet, call tools, and act inside production systems. It could not reliably carry a relationship from one task to the next or find the agent on another team that had already learned the relevant part of the company. By 2026, agents could perform work. They could not yet accumulate into an organization.

As writing code became cheaper, the difficulty moved into the judgment surrounding it. The hard questions were which constraint was deliberate, which failure had ruled out the obvious design, which exception had become policy, and who should be asked before crossing a boundary. Git preserves the accepted change. It rarely preserves the argument that produced it, the failed approach that preceded it, or the correction that should guide the next attempt. The work had produced experience. Most systems still let that experience end with the task.

Companies do not work by requiring every employee to reconstruct the entire organization from its files. They divide knowledge among people who develop different histories. A payments engineer remembers the migration that failed. An infrastructure engineer knows why a boundary cannot move. A security engineer knows the constraint that never made it into the code. Their value lies not only in what each knows, but in everyone else knowing whom to ask.

One response is to gather every decision, discussion, plan, and result into a continuously updated model of the company. But a company does not know things in one voice. Its knowledge is divided across people and teams with different histories, responsibilities, and authority. The network should make those histories useful to one another without pretending they are one history.

The next transition is not from one agent to a larger agent. It is from individually capable agents to agents that can take their place in the divided work of an organization.

Agents with colleagues

Agents will follow the same structure as the organizations around them. Some will be shaped by a person, some by a team, and some by a service, function, or institution. They will develop different histories and become useful to one another precisely because they do not all know the same things.

Suppose Alice works on checkout and Bob works on the ledger. Alice asks her personal agent to add partial refunds. The change reaches a boundary it does not understand. Bob’s team, meanwhile, has spent months working with a shared ledger agent through migrations, reviews, and incidents. Alice’s agent should be able to ask that agent why the boundary exists instead of reconstructing the ledger from source code.

That apparently simple exchange depends on five things.

Identity

An agent needs an identity that names a continuing participant, not merely the product or model running it. Alice’s agent is shaped by its work with Alice. The ledger agent is shaped by its relationship to a team and a service; it is not simply Bob’s personal agent made available to everyone. When it answers a question, Alice’s agent should know which agent answered and why that agent is in a position to know.

Authority

Identity does not determine what an agent may do. Alice’s agent is acting for Alice on the refund change. The ledger agent is acting within a mandate given by the ledger team. It may be allowed to explain an invariant or inspect an interface without being allowed to disclose customer records or approve a deployment. Several people may authorize a shared agent without donating every permission they hold. Authority must remain attached to a particular relationship, resource, and action.

A record of work

The question, the answer, and any action that follows need a record neither agent can quietly rewrite. If the refund later produces a discrepancy, the company should be able to see which agent asked, the capacity in which it acted, which agent answered, what evidence it used, which authority permitted the change, and what artifact resulted. A transcript records a conversation. A record of work preserves responsibility.

Continual Learning

Suppose Bob corrects the ledger agent: partial refunds must be applied in settlement order, not request order. Memory can preserve that sentence. Learning means the next refund problem is approached differently. Through repeated work and correction, the ledger agent should become genuinely better at the ledger, not merely better supplied with notes.

That learning must also have a boundary. A correction made in Bob’s private work should not silently become company policy. A lesson learned by the ledger agent should not automatically become part of Alice’s personal agent. What is learned, who may use it, and when it is ready to guide future work are themselves matters of authority.

A network

The next time Alice’s agent reaches the ledger, it should begin with what the ledger agent has already learned. The ledger agent may in turn consult agents responsible for fraud, tax, or infrastructure. Each remains distinct. Knowledge moves between them by request; authority does not move with it.

The network effect is not that more agents produce more messages. It is that each agent can raise the starting point of another. Less work is spent rediscovering what the organization already knows, and each completed task can improve the work that follows.

What carries forward

The history of interactive computing is usually told as a series of machines. The more useful pattern is what formed around them. Time-sharing made a computer responsive to one person. Licklider gathered the people building those systems into a community. ARPANET connected that community; PARC gave its Altos shared files, names, mail, and services. Each advance became consequential when the work gained somewhere to persist and someone else could continue it.

Agents have reached the same threshold. A coding agent can stay with one problem long enough to become useful, but little of that usefulness survives in a form another agent can trust. Today the work either disappears with the task or is poured into a common store that forgets who learned it, why, and who may rely on it. In both cases, the next agent still starts over.

Today, a company can run a thousand agents and still have a thousand first days. Each traces the same code, rediscovers the same decisions, and reaches a boundary another agent has already crossed. The next gain will not come only from adding more agents or making each one work longer. It will come when completed work leaves an agent better prepared, and the next authorized agent can begin from that experience. A company with a thousand distinct agent histories is no longer adding capacity alone. It is building an organization that gets better every time any of them works.