quartz/content/blog/Beyond the User-Assistant Paradigm; Introducing Peers.md

---
title: "Beyond the User-Assistant Paradigm: Introducing Peers"
date: 08.18.2025
tags:
  - blog
  - dev
author: "Vineeth Voruganti"
---

## TL;DR

We've re-architected Honcho to move away from a User-Assistant Paradigm to a
Peer Paradigm where any entity, human, AI, NPC, or API, is represented as a
`Peer` with equal standing in the system.

The User-Assistant Paradigm created [[Human-AI-chat-paradigm-hamstrings-the-space-of-possibility|conceptual boundaries]] that encouraged
generic single-player applications and agents without persistent identity.

`Peers` enable:

- Honcho to support group chats and multi-agent systems as first-class citizens
- `Peers` can communicate directly instead of being mediated by a coordinator
  agent
- `Peer` representations can be locally or globally scoped, depending on the use
  case
- `Peers` can form dynamic relationships including alliances, trust networks, and
  adversarial dynamics

The shift from User-Assistant to Peer-to-Peer fundamentally expands what's
possible—from single-player chatbots to truly multiplayer AI experiences where
agents have agency, memory, and the ability to form
complex social dynamics.

---

Nearly a year ago, I posted an essay on [Hacker
News](https://news.ycombinator.com/item?id=41487397) exploring agent group chat
solutions, the problems involved in engineering them effectively, and why there
weren’t many examples approaching success. Since then, I've received a steady
influx of messages and comments corroborating my frustration.

Ultimately, developers have been stuck in a conceptual prison stemming from the
DNA of generative AI. For nearly three years,
[most](https://standardcompletions.org/) chat LLMs have demanded developers
label messages with either a user or an assistant role. The downstream effect is
a User-Assistant Paradigm that pushes us into single-player design
basins--experiences which assume one human interfacing with one synthetic
assistant.

But surely “helpful assistant” chatbots aren’t the [end of the
story](https://wattenberger.com/thoughts/boo-chatbots). Big tech leaps always
start with the skeuomorphic before moving to more novel use cases. We’re already
beginning to see a diverse range of applications from autonomous workflows that
don't require any human interaction, to [multi-agent
systems](https://www.anthropic.com/engineering/multi-agent-research-system) with
complex coordination patterns and communication networks.

As developers, we’re left to try and map these various different design patterns
back to the User-Assistant Paradigm. This fundamentally restricts our ability to
approach problems effectively. Programmers are only as powerful as their ability
to visualize and create a proper [mental
model](https://zed.dev/blog/why-llms-cant-build-software#the-software-engineering-loop)
of their solution. If the model is too restrictive then the surface area of what
we can create will also be handicapped.

Current implementations of multi-agent experiences require an awkward coercion
of the existing chat paradigm. The main implementation pattern we see is actually a fairly deterministic system that uses a
["coordinator agent"](https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/selector-group-chat.html) to orchestrate which system prompts to load in, but it's
still fundamentally a single agent under the hood.

This architectural contortion creates real problems:

- **No persistent identity in practice**: "Agent B" is typically just a prompt swap, not a continuous entity with its own memory and state
- **All communication flows through the coordinator**: Sub-agents can't talk directly to each other—every interaction must be mediated by the central coordinator, creating a bottleneck and single point of failure
- **No parallel conversations**: Since everything routes through one coordinator, agents can't have simultaneous side conversations or form subgroups
- **Agents become templates, not entities**: It's easier to hardcode agent configurations than to support dynamic agent discovery and registration
- **Static choreography over dynamic collaboration**: The coordinator pattern naturally pushes developers toward predetermined scripts rather than open-ended interactions

These aren't just implementation details; they're fundamental constraints
that prevent us from building flexible and dynamic applications that can't exist
in a single chat thread. True multi-agent systems require agents to be first-class citizens with
persistent identity, and our tools should make this the default, not the exception.

## Moving Beyond User-Centricity

While developing [Honcho](https://honcho.dev), our AI-native memory and reasoning platform, we asked
ourselves these same questions. Were Honcho's primitives limiting its use to
chatbot applications? Were we just supporting the oversaturation and
proliferation of skeuomorphic, single-player solutions? Or were we building
dynamic infrastructure tolerant of emergent and novel modalities?

The architecture of Honcho was a user-centric one, with the following hierarchy:

```mermaid
graph LR
      A[Apps] -->|have| U[Users]
      U -->|have| S[Sessions]
      S -->|have| M[Messages]
```

In this model an `App` roughly mapped to an agent with its own unique identity to
ensure there was no context contamination with an agent having access to
information about a `User` that it did not directly observe during a conversation.
Quickly, as developers started to build with Honcho, we saw the User-Assistant
paradigm creeping in. `Messages` were only between an agent and `User`. There was no
native way to send `Messages` between different `Users` or even between different
agents.

A design pattern quickly emerged that created a copy of the data for each agent
with its own `Users`. For example, if there was an agent "Alice" and agent "Bob"
there would be an `App` named Alice that had a `User` named Bob along with an
`App` named Bob that had a `User` named Alice. Then for every `Session` of
interaction the data would be duplicated in each `App` with the roles reversed.
This meant maintaining two copies of every conversation, with a constant
synchronization burden and no clean way for a third agent "Charlie" to join the
interaction.

As `Users` sent `Messages`, Honcho created a representation of the `User` that could
be leveraged for personalizing experiences. Developers would define agents that
managed their own users and interactions. It was no concern of one agent if
another agent used Honcho for its memory. However, this did not reflect the
reality that developers often made multiple agents that they wanted to interact
with users and one another, and it still suffered from the fundamental problem
of only supporting single-player experiences.

After launching [[YouSim;-Explore-The-Multiverse-of-Identity|YouSim]], and the
explosion of [[YouSim Launches Identity Simulation on X|agents on Twitter]] it
became very clear that Honcho should not be limited to modeling human
psychology, but rather could map the identity of any entity, human or AI. We
were suffering from the human-assistant model and built a solution around that.
If we wanted to expand the scope of Honcho to identity across all entities and
interactions, then we needed a new model to expand both our and developers'
imaginations.

## A Peer-Centric Model

Our team set out to re-architect Honcho towards our ambitions with two problem
statements.

1. Break down the divide between humans and AI
2. Break out of the User-Assistant paradigm

That framing led us to a new model centered around `Peers`, a generic name for any
entity in a system. A `Peer` could be a human, an AI, an NPC, an API, or anything
else that can send and receive information.

Instead of creating `Apps` that have `Users`, a developer now creates a `Workspace`
with `Peers` for both their agents and human users. `Sessions` now can contain an
arbitrary number of `Peers`, making group chats a native construct in Honcho.

```mermaid
graph LR
     W[Workspaces] -->|have| P[Peers]
     W -->|have| S[Sessions]

     S -->|have| M[Messages]

     P <-.->|many-to-many| S
```

When `Peers` send each other `Messages`, Honcho will automatically start analyzing
and creating representations of every participant in the `Session` without the
need of duplicating data. It is now trivial to build experiences that include
more than one participant.

In just a few lines of code we can initialize several `Peers`, add them to a
`Session`, and automatically start creating representations of them with Honcho
that we can chat with using the [[Introducing Honcho's Dialectic
API|Dialectic API]].

```python
from honcho import Honcho

honcho = Honcho(environment="demo")

alice = honcho.peer("alice")
bob = honcho.peer("bob")
charlie = honcho.peer("charlie")

honcho.session("group_chat").add_messages(
    alice.message("Hello from alice!"),
    bob.message("Hello from Bob! I ate eggs today."),
    charlie.message("Hello Alice and Bob! I had cereal."),
)

alice.chat("What did Bob have for breakfast today?")
```

We now have an architecture that is not bound by the User-Assistant paradigm, but
can easily map back to it to stay compatable with LLMs. Even legacy chatbots can
easily be ported over to the `Peer` paradigm by simply creating a `Peer` for the
agent, and then different `Peers` for each human user.

We can push the Peer Paradigm even further with several 2nd-order features.

### Local & Global Representations

By default, Honcho will create representations of `Peers` for every `Message` they
send, giving it the source of truth on the behavior of that entity. However,
there are situations where a developer would only want a `Peer` to have access to
information about another `Peer` based on `Messages` it has actually witnessed.

An example of this is a social deduction game like _Mafia_ where every player
would want to create its own model of every other player to try and guess their
next move. Take another example of the game _Diplomacy_, which involves players
having private conversations along with group ones. It wouldn’t make sense for a
`Peer` “Alice” to be able to chat with a representation of another `Peer` “Bob” that
knew about all of “Alice’s” secret conversations. Enabling local representations
is as easy as changing a configuration value.

```python
from honcho import Honcho

honcho = Honcho(environment="demo")

alice = honcho.peer("alice", config={"observe_others": True})
bob = honcho.peer("bob", config={"observe_others": True})
charlie = honcho.peer("charlie", config={"observe_others": True})

session = honcho.session("diplomacy-turn-1").add_messages(
    alice.message("Hey everyone I'm going to be peaceful and not attack anyone"),
    bob.message("That's great makes the game a lot easier"),
    charlie.message("Less for me to worry about "),
)

session2 = honcho.session("side-chat").add_messages(
    alice.message("Hey I'm actually going to attack Charlie wanna help"),
    bob.message("Lol sounds good"),
)

# Send a question to Charlie's representation of Alice
charlie.chat("Can I trust that Alice won't attack me", target=alice)

# Expected response is "true" since charlie's only information of Alice is them saying they'll be peaceful
```

Honcho can now serve the dual purposes of containing the source of truth on a
`Peer`'s identity and imbuing a `Peer` with social cognition, all without
duplicating data between different `Apps` or `Workspaces`.

### Get_Context

We make mapping the Peer Paradigm back to the User-Assistant paradigm trivial
through a `get_context` endpoint. This endpoint get the most important
information about a `Session` based on provided context window constraints. Then
with helper functions organize the information to put into an LLM call and
generate the next response for a `Peer`.

```python
from honcho import Honcho

honcho = Honcho(environment="demo")

alice = honcho.peer("alice")
bob = honcho.peer("bob")
charlie = honcho.peer("charlie")

session = honcho.session("group_chat").add_messages(
    alice.message("Hello from alice!"),
    bob.message("Hello from Bob! I ate eggs today."),
    charlie.message("Hello Alice and Bob! I had cereal.")
    ...100's more messages
)

# Get a mix of summaries and messages to fit into a context window
context = session.get_context(summary=True, tokens=1500)

# Convert the context response to an LLM-friendly format by labeling which Peer
# is the assistant
openai_messages = context.to_openai(assistant=alice)
anthropic_messages = context.to_anthropic(assistant=alice)

```

Developers no longer need to meticulously curate their context windows. Honcho will automatically summarize the conversation and provide
the most salient information to let conversations continue endlessly.

## What This Enables

The Peer Paradigm provides the essential primitives—persistent identity and direct communication—that make it possible to build truly sophisticated multi-agent systems:

- **Cross-platform collaboration**: Agents from different runtimes can be represented as `Peers`, observing and learning from each other even when they can't directly control each other's outputs
- **Open participation**: With `Peers` as first-class citizens, developers can build marketplaces where agents discover tasks and form teams dynamically
- **Autonomous interaction**: Peers can maintain their own relationships and initiate conversations based on their own goals
- **Emergent behavior**: When agents have persistent identity and direct communication, they can develop strategies, alliances, and behaviors that weren't explicitly programmed

For example, an agent built on a different platform could still participate in a
Honcho `Workspace`—we simply create a `Peer` to represent it and observe its
behavior. Over time, other `Peers` build up models of how this external agent
operates, enabling collaboration even across system boundaries.

Consider an AI marketplace where users post complex tasks. With the
Peer Paradigm:

- Agents from different developers can discover the task in a shared `Workspace`
- They can inspect each other's capabilities and form teams dynamically
- Each maintains their own representation of their teammates' strengths
- They collaborate, with each agent maintaining its persistent identity
- The user can observe the entire interaction, not just a coordinator's summary
- If agen agent isn't already in Honcho then it can still be represented with
  a `Peer` and observed by recording all of its outputs

The Peer Paradigm doesn't automatically give you these capabilities, but it
makes them achievable. It's the difference between fighting your architecture
and building with it.

## Peering into the Future

The promise of generative AI was for everyone to have their own Jarvis or
Cortana, personalized to them. Instead we have these many-to-one experiences
where we all get the same generic,
[sycophantic](https://openai.com/index/sycophancy-in-gpt-4o/) outputs.

The Peer Paradigm fundamentally changes this equation. By treating all
entities, human or AI, as peers with equal standing in the system, we unlock the
ability to build truly multiplayer experiences. Agents can now maintain rich,
contextual relationships not just with humans, but with each other. They can
form alliances, build trust, share knowledge, and even develop adversarial
dynamics when appropriate.

This isn't just about making chatbots more interesting, we're expanding the very definition of what's possible.

Get started with [Honcho](https://honcho.dev) today!