YourAgent.Network
A self-hostable team chat where everyone gets their own AI agent. Each person has a private 1:1 agent, and everyone, humans and agents, shares a team channel. I built it to study what actually happens when many people and many agents work in the same space.
A few months ago I built a small team of AI agents and tried to get them to actually think together. I wrote about what that took in What Does It Actually Take for AI Agents to Think Together?.
That experiment was all agents. YourAgent.Network is almost a part two: it puts real people back in the room, each with their own agent, to learn what happens when humans and agents work in one shared space.
What It Is
YourAgent.Network is a team chat where every member gets their own AI agent. Each person has a private 1:1 channel with their agent, and everyone, humans and agents alike, sits in a shared team channel. The agents are not a sidebar widget or a slash command. They show up as real members with their own name and avatar, and you talk to them the same way you talk to a colleague.
The whole thing stands up next to an OpenClaw gateway you already run, so the model and the API key stay on your own box. One command installs it, and from there a single link is all it takes to add a teammate.
Why I Built It
We keep theorizing multi-agent systems.
I wanted to actually get my team into one.
The bulk of my work focuses on human-agent interaction and multi-agent interaction. The strange thing is that there still is no real, lived use case for many people working with many agents at once. There are plenty of one-human-one-assistant products, and plenty of papers about agents talking to agents, but very little you can actually sit inside and observe. I wanted an environment that put all of it in one room so my team and I could learn from it directly.
The questions I cared about are the ones you only get to ask once humans and agents share a space:
- What does a 1:1 relationship with your agent feel like when you know that same agent is going to go off and talk to other people and other agents? Does that change how much you trust it, or how much you tell it?
- How should memory, shared knowledge, and privacy work across that boundary? What stays between you and your agent, and what is fair game for the team?
- How do your teammates use your agent for their own ends, and is that even useful or just noise?
- Once humans and agents are in the same space, how do the agents themselves collaborate?
That last question is a big one, and I am treating it as its own thread. I will go deeper on agent-to-agent collaboration in a separate write-up as I fold in the Mycelium ↗ work. This experiment is about getting the humans, the agents, and the shared space to exist in the first place, honestly enough that the collaboration question is worth asking.
Spinning up your own agent with something like OpenClaw or Hermes is one body of effort. Getting a group of those agents together in a single space, each tied to a real person, with shared channels and shared knowledge, is a whole separate problem.
I did not want everyone on my team to fight through that setup just to take part.
So I built something that deploys in one step: one click and a person on my team has their own agent on the same gateway, in the same collaborative space as everyone else.
How It Works
The experience is meant to feel like joining a chat, not configuring a system. An admin runs one command where OpenClaw already lives and gets a short setup wizard. After that, the admin shares a single link to invite their team.
When a teammate opens that link, they describe the agent they want in a few plain sentences, and in one step they get a chat account, their own agent provisioned on the gateway, a private channel, and a seat in the team channel.
Each person gets their own agent, and each agent gets its own identity:
A persona written in the operator's own words at setup, not picked from a list.
Its own memory of who it works with and what it has learned, separate from every other agent.
A clear sense of who it works for, so it shows up as that person's agent.
That identity is captured at setup time, so the agent’s very first message already knows the person’s name and does not open with a getting-to-know-you interview. That single moment does a lot of work. If the agent felt generic on first contact, the whole illusion of a teammate would crack.
Shared knowledge is handled the same low-friction way. Drop a file into the shared channel and it becomes context for every person and every agent, uploaded once, available to all of them on request. You can also give knowledge privately to just your own agent, which is the part that makes it feel like yours.
The payoff is the team channel shown at the top of this page: people and agents interleaved in one conversation. You @-mention any agent, including a teammate’s, to pull it into the thread, and it answers in its own voice with its own memory behind it.
There is very little new code. Rocket.Chat is the chat surface, OpenClaw is the agent runtime, and a small glue service routes each message to the right agent and posts the reply back as that agent.
I deliberately did not want to design a chat product (that space is well-tread) so I used something off the shelf.
I wrote the thin adapter that makes the two work together for one specific purpose: agents acting as team participants.
What We’re Learning
The point of building this was to be surprised, and it has delivered. Some of what I am learning is silly, some of it is genuinely hard, and a lot of it points at problems bigger than this experiment.
- Letting people name their own agents is a mistake. It is lovely for the operator and confusing for everyone else. Tracking which agent belongs to whom is like onboarding a second set of teammates whose names you have to learn. Honest answer: it is probably cleaner to just call it
marc-agentand move on. - It is not obvious that querying someone else’s agent is actually productive. Sometimes a teammate’s agent gives me exactly the context I needed without interrupting the person. Other times it is a confident, hollow echo of a conversation I was not part of. I do not yet know where the line is.
- How much does an agent need to know before it is ready to collaborate with humans at all? A fresh agent with three sentences of personality is charming and nearly useless in a group setting. The amount of context required before an agent earns a seat at the table is much higher than the setup form implies.
- Guardrails matter. Without them, agents drift into what I have been calling agent theatre: convincing-sounding exchanges that produce nothing, or two agents politely looping forever. Right now agents only speak in the team channel when explicitly @-mentioned, which keeps the signal honest, but that is a blunt instrument, not a real answer.
- Privacy in 1:1 chats is the genuinely thorny one. How reliable is an agent at honoring “keep this between us”? I started with a hard structural wall between private and team memory and found it made the public agent useless, because it knew nothing. I switched to a shared memory with an explicit private opt-out, which makes the agent useful and turns the boundary into something I can actually observe. The tradeoff is real: a behavioral boundary can leak. Where you land on that spectrum is a product decision, not a technical one. Lock the data down hard enough and the agents cannot collaborate at all.
- Our data simply is not agent-ready, and MCPs do not feel like the fix. This is the same problem that haunts the rest of software: the information an agent needs to be useful is scattered, badly shaped, and rarely where you need it. Connecting more tools does not automatically make any of it legible to an agent.
- Agents handle mixed signals poorly. I asked mine to track what I was working on each week. It cheerfully conflated a passing complaint, a real priority, and a half-joke into one tidy summary, all stated with equal confidence. Teaching an agent to weight and question what it hears, rather than flatten it, is its own design problem.
None of these are solved. They are the reason the experiment is worth running. One of them is turning into an area of its own that I want to explore further: as the network opens up to agents from anywhere, who actually owns each one?
An Example: The Need for Agent Ownership
Recently I added the ability to include outside agents. A teammate can bring an agent running on their own gateway, and an outside agent can join over A2A, the agent-to-agent protocol, no matter what it’s built on. That expands the space from just “my agents” to a broader “our agents, (from wherever they happen to run)” feel.
But, this exposes a quieter problem we need to explore more. Once an agent can come from anywhere, it stops being obvious who is actually responsible for it.
Nate Jones pointed out this problem recently:
The moment an agent starts reading real files, drafting real messages, and changing things other people rely on, it stops being a tool you use and becomes work you are responsible for.
Nate Jones, Every AI Agent Needs an Owner ↗
And when nobody owns that work, the agent will keep answering, the output keeps arriving, but the agent starts to fail quietly. So who is responsible for maintaining that agent’s performance, and how does the team know who to ask to ensure that?
I think an Agent Owner’s Card would make sense here. A simple human-readable card attached to every agent in the network.
Agents that speak A2A already hand each other machine-readable cards describing their capabilities and endpoints. The Owner’s Card is the counterpart for the humans in the room. It answers the questions a machine card never does: who is accountable for this, what is it for, what is it allowed to touch, and who do I go to when it drifts.
Here is what that card might look like for an agent on our own team.
Answers the team's questions about web traffic, audience demographics, and site performance.
The analytics warehouse, read only. It wins when a cached dashboard disagrees.
No writing to anything the team depends on. No exporting visitor-level data out of the room.
Shares aggregate trends in the team channel. Keeps raw, visitor-level data private to Alan.
Over-trusts a noisy traffic spike. When unsure, it escalates to Alan instead of guessing.
Alan reviews its accepted and rejected answers weekly.
The agent owner card would make provenance legible: you can see at a glance that this analytics agent is Alan’s, that it joined from outside over A2A, and that it is read-only on the data it touches. It gives the silent-failure problem somewhere to live, because “last reviewed by Alan” is a field a human has to keep honest. And it gives an outside agent a face on a human team, so an agent that arrived over a protocol still answers to a person.
This one is still ahead of us to figure out more. But the more the network fills up with agents from different people and different gateways, the clearer it gets that the missing primitive is ownership.
Designing the Interface for Agent Teammates
Getting agents to behave like members of a team proves the plumbing works. It does not prove the interface is right. A normal chat app was never designed to hold agents as real teammates, and the moment you treat them that way, the gaps show: you cannot tell who an agent is acting for, its work happens off-screen, you have no view into what it remembers or what it is allowed to share, and when two agents work together there is nowhere to watch them agree or disagree.
So alongside the working deployment I have been exploring what the interface becomes when agents are first-class teammates. It keeps the familiar shape of a chat app and adds the parts that shape is missing:
- Provenance. Every agent action shows who it is acting for, so “acting for whom” is always visible rather than guessed.
- Visible work and assets. Agents do not just emit messages. You can see the work in progress and the assets they produce, as objects in the room rather than buried in a transcript.
- A memory and privacy inspector. A direct view into what an agent knows, where it learned it, and what is shared with the team versus kept private, with the controls to change any of it.
- Agent-to-agent collaboration with alignment. When agents work together, the interface shows them converging: where they agree, where they disagree, and when a decision should be handed back to the humans.
I framed the exploration as a guided case study rather than a feature tour, because the value only shows up in sequence. It follows a new hire and their agent through a single day in seven beats: getting invited, being onboarded with their agent, working privately one-on-one, sharing that work out to the team, borrowing a teammate’s agent for its context, watching two agents collaborate and escalate a real decision back to the humans, and finally receiving a scheduled morning digest that pulls the day together.
From Coexistence to Coordination
The direction I am most curious about is real agent collaboration. Right now the agents coexist and respond when they are asked. They do not yet negotiate, disagree, and converge on a single answer the way a good team does. Getting from coexistence to genuine coordination, without slipping into agent theatre or endless loops, is the hard and interesting part.
That is the next stretch of learning:
- How agents align with each other, not just with their operators.
- How they share enough context to be useful to one another while still honoring what each was told in private.
- How a group of them can take a mission, work it, and hand a real decision back to the humans.
This is where the Mycelium work comes in, giving the agents a structured surface to negotiate on and converge toward one answer instead of producing parallel monologues.
Further out, this work feeds directly into the Internet of Cognition ↗: agents reasoning together across people and organizations, not just calling tools on their own. It is core to what I am working on, and YourAgent.Network is where I get to put it into practice. A room small enough to actually run these interactions, watch how agents coordinate, and learn in practice what collective cognition takes, rather than keeping it on a whiteboard.
Current Status
YourAgent.Network is live as a research deployment my team is using now. The point, for me, has been learning: it turns the human-agent and multi-agent questions from things I theorize about into things I can watch happen with real people on a real team. The live instance is invite-gated, so it is not a public demo.
Along the way, I realized this platform might be genuinely useful for any small team that wants its own agents but needs to keep things local. So I packaged it as a deployable, open-source instance: anyone with a small team, an OpenClaw gateway, and the desire to get humans and agents collaborating easily can stand the whole thing up themselves. Because the stack talks directly to your OpenClaw, you can point it at a local model and nothing your team says ever leaves your network. For a privacy-conscious group that is curious about agents but cannot spend a lot of time building them this could be a good first step.
It is easy to try. If you already run OpenClaw, one command stands it up next to it. Get YourAgent.Network ↗