A personal agent and a team agent can run the same instructions on the same model. They are still different systems.
A personal agent answers to one person, who is also its author, its reviewer and its operator. A team agent answers to many people at once.
Each of those people expects it to behave the same way for everyone, to respect what they may and may not see, and to keep working while its author is away. This article is less about how to share an agent and more about what a shared agent has to be: consistent, bounded, careful with memory and owned.
A team agent answers questions a personal agent never faced
Once a team relies on the agent, questions that used to answer themselves each need a deliberate answer.
| Question | Personal agent | Team agent |
|---|---|---|
| Who is asking? | Always the author | Each person signs in, and the agent knows who it serves |
| What may it reach? | Whatever the author's accounts allow | Decided per person and per capability, outside the model |
| Where do its facts come from? | The author's own notes and prompt | Shared notes that someone maintains |
| What does it remember? | One person's chat log | Separate conversations, kept apart from shared knowledge |
| Who notices a failure? | The author, eventually | A named owner, with a record of every run |
| What does it cost? | One person's subscription | Usage and estimated cost, visible per agent |
The rest of this article takes the four questions that change the most.
Everyone should get the same answer
A personal agent only has to be consistent with its author. A team agent has to be consistent across people. In an invented example, the sales lead and the finance lead at a small distributor both ask what revenue was last month. If the definition of revenue lives in whoever wrote the prompt, or in two slightly different prompts, they get two numbers and a meeting to reconcile them.
So a team agent needs its definitions in one shared place, maintained by someone and read by every answer. In Hubzoid that place is the Hub: the agent's instructions, reference notes and procedures, shared by chat, scheduled work and any assistant connected to it. Nobody keeps a private copy of the rules.
Two people who ask the same question on the same day should get the same figure, calculated the same way, with the same source named.
When they do not, the fix belongs in the shared note, not in either person's conversation.
Shared context is not shared access
A team agent handles two kinds of context, and mixing them causes most of the confusion.
- Shared context is what the whole team relies on: definitions, thresholds, policies, procedures and who owns what.
- Personal context is what one person brings to one conversation: the document they are working on, the file they uploaded, how they want this answer laid out. It belongs to that conversation and goes no further.
Access stays personal too. Two people can use the same agent and see different tools, because their permissions differ. A buyer can look up unit costs and a store lead cannot, even though both read the same definitions. In Hubzoid that decision is made in code before a sensitive tool runs, not by the model, and every allow and deny is recorded.
Sharing an agent's knowledge never means sharing its author's accounts.
One person's conversation should not become everyone's knowledge
A personal assistant that picks up its one user's habits over time can be helpful. A team agent that did the same would be a problem, because one person's mistaken aside could become everyone's answer. With a team, three kinds of memory need to stay apart.
- Conversation history belongs to one person and one chat. By default in Hubzoid 1.0.1, administrators cannot open or export other people's chats in the web chat.
- Working state is what a scheduled routine remembers between runs, such as which weeks it has already reported. It belongs to that routine, not to any conversation.
- Learned knowledge is a change to what the whole team's agent knows. In Hubzoid, only a person with the curator permission can save it, and the agent is instructed to do so only when that person asks. Each saved note records who wrote it and when.
The point of that last rule is reviewability. A deliberate, attributed change can be read, corrected and undone like any other edit to the Hub. A team agent that quietly rewrote its shared knowledge from every conversation would be hard to audit and easy to mislead.
A failure now has an audience
When a personal agent fails, its author shrugs and reruns it. When a team's Monday report fails, several people start their week without it, and nobody may know whose job it is to look.
So a team agent needs owners, even if one person holds every role at first:
- The context owner keeps shared notes and procedures current and reviews learned notes.
- The access owner decides who can use the agent and each sensitive capability.
- The operations owner watches runs and failures, keeps backups and plans upgrades.
Naming these roles is what lets the author step away. Hubzoid gives each role a record to work from:
- run history with steps and errors
- a log of access decisions
- usage with estimated model cost per agent in the Console
The records only help if someone is named to read them.
The instructions travel, the assumptions do not
Moving from one person to a team rarely means rewriting the agent's instructions. It means answering, out loud, the questions one person used to answer without noticing: who is asking, what they may reach, which definitions are true, what counts as memory and who looks when something breaks. Answer those, and people who did not build the agent can rely on it.
For the practical side of sharing a personal agent, read from your laptop to your team. For how conversations, working state and learned knowledge are kept apart, see memory and history.