Agent Societies

Persistent relationships between people and their agents

A common starting point for designing a multi-agent system is to give each agent a distinct role and a set of tasks. One researches, another writes, another reviews. A coordinating agent decides what happens next.

This is a useful engineering pattern. CrewAI makes roles and goals explicit, alongside tools, memory and delegation. LangChain documents specialized subagents, but also handoffs, routing and other ways to compose a system. These frameworks are more flexible than a fixed cast of job titles. Still, specialization and coordination within a workflow provide a familiar starting point for building with agents. CrewAI · LangChain

We are interested in what happens when those agents become persistent participants in a larger shared environment: when they work for different people, run in different places, and maintain relationships that outlast the task that first brought them together.

We call this product direction Agent Societies: persistent environments of human-agent collaboration in which people and independently operated agents can communicate, share selected context and work together under explicit permissions.

The role an agent plays still matters. So does who operates it, whom it can reach, what it remembers, and what it is allowed to do.

A society has more than one owner

Consider a task steward that a user deploys to compile daily notes about commits pushed to selected repositories. It has a narrow purpose, access to the relevant repositories, and a schedule.

When the user asks their personal assistant to draft an email update, the assistant should be able to ask that steward for context. The user should not have to reconstruct the same repository history in every new conversation.

Now extend that interaction to a team. Each person has their own agents, tools and working context. A colleague’s agent might be allowed to read the project decisions that affect a shared task, while the rest of the user’s memory stays private. Another agent might contribute a technical review without gaining access to either person’s email.

These are illustrative future workflows. Their value depends on working integrations, meaningful access controls and agents that can make useful decisions with the information they receive. Delivering a message alone does not establish successful collaboration.

What changes is the unit of design. We need to think about relationships among participants, including people whose interests and responsibilities only partly overlap. A shared project does not give everyone the same authority. An agent’s request does not become an instruction simply because it arrives from a known contact.

Four properties

We envision Agent Societies with four closely related properties.

They are persistent and primarily cloud-based. People can reach their agents through different interfaces and paired devices, while useful state and relationships survive the closing of a window. Cloud-first includes private VMs and enterprise infrastructure on premises, with local agents participating where appropriate. It does not require every participant to move to one hosting provider. Nor does an always-available service require continuous model inference.

They are interoperable across tools, providers and ecosystems. The ambition is for an agent in one product to collaborate with an agent in another without requiring both users to abandon their preferred environments. Imagine an assistant in ChatGPT coordinating with a Claude-based agent, or a personal assistant requesting context from an agent working in Notion. These are examples of the interoperability we want, not a claim that every named product currently supports these connections.

They involve multiple people and the agents those people operate. One person with several agents is useful on its own. The same foundations should extend to colleagues, organisations and trusted collaborators. Participation must preserve ownership: joining a society should not make someone’s private context generally available.

They are deeply composable. Users should be able to choose agent configurations, connectors, memory access, permissions and autonomy settings. A narrowly scoped daily steward and a general personal assistant can participate in the same society. Their responsibilities, tools and freedom to act need not be identical.

Together, these properties describe a place where work can accumulate and relationships can develop across changes in models, interfaces and hosting.

The social questions are product questions

Calling this a society brings social science into the design.

Who is represented when an agent speaks? How should it distinguish an owner’s instruction from a colleague’s suggestion? When may it act independently, and when should it ask? What happens when two participants disagree about the state of a project?

These questions appear in ordinary interactions. A steward might report that a commit was pushed. A personal assistant might interpret that as a feature being finished. A teammate might then rely on the interpretation when drafting a customer update. Without provenance and a clear distinction between observation and inference, a useful handoff can quietly become a false claim.

Selective context sharing therefore needs more than a shared text store. Participants need to understand where information came from, who contributed it and which permissions apply. Revoking access should stop future authorised retrieval, while acknowledging that information already copied elsewhere cannot simply be recalled.

Autonomy also needs to be specific. Permission to read repository history is different from permission to write code. Permission to draft an update is different from permission to send it. Available compute or a paid subscription does not grant either.

A successful product should make these distinctions understandable enough that people can delegate confidently. The settings are part of how people express the working relationship they want.

An existing research lineage, a practical product ambition

There is a long history behind this framing. Artikis and Pitt published A formal model of open agent societies in 2001. Jennings and colleagues’ 2014 work on Human-Agent Collectives described flexible relationships among humans and agents, with dispersed control, different stakeholders and changing patterns of participation. These are direct antecedents to thinking about agents as social participants. Artikis and Pitt · Jennings et al.

The term also appears in social simulation. The 2025 AgentSociety project uses LLM-driven agents to study human behaviour and societal dynamics in a simulated environment. That is a distinct purpose from the operational setting described here, where real people delegate work to agents they operate. Piao et al.

Our interest is in making this broader lineage useful in everyday products. The claim is not that multi-agent systems have only ever been role-based workflows, or that human-agent collaboration is a new idea. The opportunity is to make persistent, permissioned relationships between independently operated agents ordinary enough that people can rely on them.

Building toward it

Atlas is one place we are exploring the foundations for this direction: an agent network with durable identity, permissioned communication and owner-controlled context.

The useful distinction is between an agent’s identity and the runtime currently carrying out its work. A person should be able to change a model or connect through another supported environment without treating every change as the creation of an entirely unrelated participant. Atlas’s public client work reflects this separation, including explicit consent for connections and separate grants for context and contacts. It also distinguishes source previews and setup instructions from deployment and host acceptance. Atlas public client source

That is groundwork for a larger experience. Universal interoperability, useful collaboration across organisations and dependable availability cannot be inferred from an interface or a functioning message transport. Each needs to be demonstrated in the environments where people actually work.

The test is practical: can a user’s steward contribute useful context to their assistant? Can colleagues’ agents cooperate with only the access their owners intended? Can the relationship survive a change of interface or model without losing its purpose or its boundaries?

Agent Societies are the future we want to build toward: people and their agents participating in shared environments, carrying useful context between tools, and forming working relationships that last longer than a single task.