---
title: "Multi-Owner Sessions: The Odyssey"
description: "Built in two days, finished in three months. How permissions, sender identity, and real usage shaped multi-owner sessions at Wandero."
canonical: "https://www.wandero.ai/blog/multi-owner-sessions-the-odyssey"
last-updated: "2026-08-25"
---

# Multi-Owner Sessions: The Odyssey

> Built in two days, finished in three months. How permissions, sender identity, and real usage shaped multi-owner sessions at Wandero.

Published: 2026-09-07
Author: Wandero Team
Category: Insights


A client asked us for multiple owners on a session. We said sure. We shipped the base in two days.

Then it took us three months to finish it.

Not because the base was wrong. The base was good: a session gets a primary owner and any number of collaborators, and everyone on the list can fully work the session. Client asked, we delivered, everybody moved on.

Most feature stories stop there. This post is about [the part after](/blog/the-missing-layer-after-launch), because that part is where the actual product lives.

## Where it leaked

A few weeks in, one customer noticed the agent kept signing outgoing emails with an odd signature. Specifically, one person's signature, no matter who was actually driving the session.

From the agent's point of view this was reasonable. A session had one owner, so every message came from that owner, so that was the name to sign with. Now the session had three owners, and the agent had no idea which of them was typing. It picked the only identity it knew.

The customer did what a sensible person does. They fixed it in the place they had access to: the company instructions.

```text
# Company guidelines

- If Anna is writing, sign emails as Anna.
- If Marc is writing, sign emails as Marc.
- If Sofia is writing, sign as Sofia and CC Anna.
- If Marc is writing about a booking, use Marc's booking signature, not the sales one.
- ...
```

The instructions grew. The signatures did not get better, because the agent had no way to know who was writing. We were asking it to follow rules it had no resources to follow.

That is the pattern worth naming. **A gap in one feature does not stay in that feature.** It leaks into whichever feature is closest, as compensation, and the compensation is never done well. Multi-owner sessions were "done", and their missing details were quietly bloating company instructions.

So we embarked on the journey of figuring out the details.

## What we actually did

The details took weeks of proposals, meetings, iterations and, finally, three small groups of changes.

**Permissions.** Only session owners can message the agent in a session. Then we extended the same rule to files: only owners can edit, upload, delete or share the session's files. And the primary owner's personal folders (instructions, memory, skills) are theirs. If a collaborator's turn tries to write into them, the write is refused at the sync boundary and the agent sees that it was not saved.

**Sender metadata.** In a shared session, every message now carries a line naming its sender in the agent's context, and the agent always has the current list of owners with each one's role. When someone edits a file by hand, the agent sees who did it, not just that "the user" did. The signature problem disappears without a single instruction being written, because the agent finally knows who is talking.

**Transparency, both ways.** When owners change, the agent gets a short note about the change with the next message. Users get the same information in the chat timeline: a small pill at the exact point where a collaborator was added or removed or the primary owner changed. Messages in shared sessions show the sender's name and avatar. The session header shows who the primary owner is. File edits show up as pills with the editor's name.

![A shared session: each message names its sender, a pill says Jet Li joined as a collaborator, and the agent answers that the first message was sent by Mariam Alavidze, the session's primary owner.](/blog/multi-owner-sessions-the-odyssey/shared-session-framed.webp)

*A shared session on test. Jet Li asks who sent the first message; the agent knows.*

| Session behavior | In June | Now |
| --- | --- | --- |
| Who can message the agent | anyone who could open the session | session owners only |
| Who can edit and share the session's files | anyone who could open the session | session owners only |
| The primary owner's instructions, memory and skills | writable from any owner's turn | theirs; a collaborator's turn cannot write to them |
| Does the agent know who is typing | no, everyone is "the user" | yes, every message names its sender, and the owner list with roles is in context |
| When owners change | nobody is told | the agent gets a note with the next message; users see a pill in the timeline, live |
| Who edited that file by hand | "the user" | the person, by name, to the agent and in the chat |

In a nutshell: we made some things a little stricter, just a tad, and we surfaced information to both the agent and the user.

So really it was not about having the feature. It was about solidifying it. Giving it meat.

## No grand redesign

As always, the team strived for simplicity, which is sometimes harder than over-engineering.

Every piece above reused something that already existed. The sender line sits in the same context block that already carried file hints for the agent. The ownership events use the same event-marker pattern as the existing "file modified by user" notices. The timeline pills ride on the realtime channel the frontend already had open for session updates. The permission checks are one service method behind the routes that were already there.

Logic was preserved. Nothing was rewritten. We leveraged everything we had and the result reads like it was always meant to be this way.

## The insight that drove it

Here is the thing that became the biggest driver for us.

We have hundreds of multi-owner sessions in production, and around 250 of them are active in any given month. So we looked at how they are actually used.

Our users use this feature, though not as often as you would think. When they do, **they use it sequentially.**

Take Luka and Mariam sharing a session. What we found was: Luka would be messaging, then stop, and Mariam would take over. Not two people typing at the same time in one chat. A handoff. In a 30-day window, out of all those active shared sessions, only nine had more than one human typing at all. Five of those were a single handoff: one person stopped, the other took over. In the other four, someone dropped in for a message or two and the first person carried on. Most collaborators are watchers, added so they can see what is going on.

![Three rows of messages over time. Designed for: two people alternating. What people do: one person messages, stops, the other takes over later. Most shared sessions: one person messages while the other only watches. Beside it: about 250 shared sessions active in 30 days, 9 with two people typing, 5 single handoffs and 4 drop-ins.](/blog/multi-owner-sessions-the-odyssey/session-handoffs.webp)

*What we designed for versus what people actually do. Late-August production data, 30-day window.*

Why did this matter so much? Because our biggest planned change was to bring every owner's personal folders into the [session's sandbox](/blog/how-wandero-works). Every owner's instructions, memory, and skills, all mounted at once, with arbitration rules for when they disagree. We all screeched at that. It meant a giant backend diff, a new cost line on every prompt, and an infrastructurally dubious quest through our mount templates. But it seemed the most logical thing to do, so we were going to do it.

Then the usage told us something simpler. If the right person's folders are in the sandbox, one person's folders is enough. When people hand a session over, the person driving is the person whose context should apply.

```text
/home/
├── company/            # the agency's context, shared by everyone
├── sessions/current/   # this session's files, shared by every owner
├── me/                 # one person's files: the primary owner's
│   ├── instructions.md
│   └── memory.md
└── skills/             # the primary owner's skills
```

The sandbox stayed exactly like this. `me/` is one person, and that person is the primary owner.

We were tempted by over-engineering, faced it, and said no.

## The fix that became a sentence

So, keeping in mind that our users are sequential: we surfaced this in the frontend and said it plainly. When you add a collaborator, the dialog now tells you that the agent will keep using the primary owner's personal files, instructions, memory and skills, not the collaborator's own. When you transfer ownership, it tells you whose context applies from the next run. If you want your files used, make yourself the primary owner.

![Manage owners: Mariam Alavidze marked Primary, Jet Li marked Collaborator, and the add-collaborator note that the agent keeps using the primary owner's personal files, instructions, memory, and skills.](/blog/multi-owner-sessions-the-odyssey/manage-owners-framed.webp)

*Manage owners. The sentence under "Add collaborator" is the wording change.*

Just like that, what could have been a ginormous backend change became a wording change in a dialog.

The transfer button already existed. The personal context already followed the primary owner. The only thing missing was telling people, at the right moment, that this is how it works. Collaborators also stopped seeing their own personal files in the file picker, because the agent never had them anyway. The picker had been promising something the sandbox could not deliver. Now it says so: personal files are not shown here because the agent works with the primary owner's personal context.

## What I take from it

I cannot say that products should only be built around users. Some of what we shipped here, like refusing collaborator writes into someone else's memory, nobody asked for and everybody needed.

But users do love when their expectations are met. And the cheapest way to meet them is usually to find out what they actually expect. Three months of design work collapsed into a few strict rules, a few labels, and one honest sentence, because we stopped designing for the collaboration we imagined and started designing for the handoff people were already doing.

Shipping the feature took two days. Finishing it meant deciding what it means.