Your work and the team's work

Ownership answers a practical question: if the person who set this up leaves, who can keep using and managing it? A conversation you start in the app is yours and private. Other resources may begin as yours or let you choose the business while you create them.

A team assistant does not make your conversation shared. Work the assistant does inside your conversation stays with you too.

Who can see a conversation is set when it starts and does not change. To let colleagues read one of your chats, share it. To change who a conversation is for, start a new chat.

Mobius shows one of these labels anywhere ownership matters:

Label	What it means
Only you	You own it, and only you can reach it
Shared by you	You still own it, and you shared it with your organization
Shared with group	It is shared, but the agent that contains it limits it to that agent's audience
Team	The organization owns it for everyone who has the required role
Someone else's	An administrator can govern this private configuration without reading its content

Your role still matters. Owning a routine does not let you edit routines unless your role permits it. Ownership decides which rows are in your reach; roles decide what you may do with rows you can reach.

Mine, shared with me, and team

Lists organize work with the same three views. Some pages show them as filters; others, including Routines, show the groups together:

• Mine or Yours includes your private work and work you shared while keeping ownership.
• Shared with me or Shared with you includes colleagues' shared work and work shared with an agent group you belong to.
• Team includes resources handed to the organization.

An agent can narrow a resource but cannot widen it. For example, a shared skill inside a four-person agent reads Shared with deal team, not shared with the whole organization. A private row stays private even when its agent is for everyone.

Share or hand over

Use Share with team when colleagues should be able to use something while you keep ownership. Use Hand over to team when the resource should belong to the organization instead. A routine's form calls the same choice The business. Both changes cross the personal-to-team boundary and require organization administration. A custodian with build access can still make their own shared resource private again.

Mobius confirms any change that expands the audience. It refuses an un-share when a wider assistant still has a standing assignment to the resource. Nothing becomes shared just because a related assistant or resource changed.

Assistants work differently. An assistant is an individual, group, or team assistant from the moment it is created, and that never changes. To share a individual assistant, make a team version of it; see who can use an assistant.

Organization administrators can transfer configuration to another active member. The target must be a real person who can belong to the organization; agents and API clients cannot own ordinary resources.

What administrators can and cannot see

Private conversations and their output remain private from Owners, Admins, and provider technicians. They cannot discover the conversation, read its title, inspect its files, use it, or transfer it. There is no hidden support or break-glass read.

For private configuration, such as a routine, skill, table, or computer, an administrator can see its name and lifecycle metadata so they can transfer or delete it. They cannot read its instructions, rows, or activity through that administrative view.

When someone leaves, Mobius shows configuration by name and requires an explicit choice for each item. Conversations stay where they are and appear as counts only. Private conversations and output are sealed without exposing their names or content. Mobius records the earliest planned deletion date; automated deletion is not part of the current release.

For each named configuration resource, the administrator chooses Transfer to person, Hand to team, or Delete. Those choices preserve an ownership decision; they do not preserve every account permission automatically.

An individual assistant is never handed to someone else, because its chats and memory are one person's. The administrator chooses Keep for the team or Delete. Keeping it replaces it with a team assistant, named after it with "(team)", that has its instructions, tools, skills the team can use, and company accounts. If an earlier team assistant already has that name, the new one is "(team 2)", and so on. Its chats and memory are not copied.

An assistant's routines go with it and need no choice of their own. If the assistant is kept, they move to the team assistant and are handed to the team like any other routine: paused until someone takes them on. If it is deleted, they are deleted too.

Someone who leaves loses their group assistants as if a manager had removed them. A group assistant always has a member; if they were its last one, an administrator adds someone, who becomes a manager, or deletes it.

A transferred or team-handed routine loses its saved account bindings and is paused until someone binds accounts suitable for its new owner and resumes it. Private sharing confirmations are revoked because they belonged to the former owner's consent. Deleting a routine cancels future runs.

A routine already owned by the business does not depend on its creator's individual custody. It can still depend on named responsible people, managers, followers, and exact account grants. Review those separately before somebody leaves; Mobius does not choose a replacement person or account.

API shape

Public resource responses use the same vocabulary as the product:

• owner.kind is person or team; owner.id is present only for a person.
• visibility is private or organization.
• container is either null or the agent that further narrows reach.
• posture is the effective label for the current caller.

Use PATCH /v1/resources/{resource_type}/{resource_id}/ownership to share, un-share, hand over, transfer, or detach a container. Audience-expanding changes require confirm_audience_expansion: true. Conversations (session) are refused with 409, because their audience is fixed when they start. Someone outside a private row's reach receives the same 404 response as if the row did not exist.

Exact request and response shapes are in the interactive API reference.

Next

• Decide who an agent is for.
• Learn how roles and permissions limit operations.
• See how conversations work in agent sessions.