How to Build Team Agents

Context

Through 2026, most AI agents have been solo tools that cover only the work one person does alone. But much of real work happens between people, and that is where shared agents, which host Nathaniel Whittemore also calls multiplayer AI, are starting to appear. In this Operator's Cut, Nufar Gaspar walks through what it takes to build an agent that a whole team uses. It matters to PMs because the hard parts are not technical. They are agreeing on ground truth, setting permissions, and naming an owner.

The Big Idea

Not every agent should be shared, but the ones that should be need five deliberate decisions: what it does, where it lives, what it knows, what it can touch, and how you run it.

Nufar's point is that the value lasts beyond any tool. The configuration and the knowledge curation are the heavy lifting, and they carry over when better products arrive.

Key Insights

Agent sprawl is the trigger

Nufar describes a three-step pattern in the most AI-forward companies:

• Step one: everyone builds a personal agent and enjoys the productivity boost.
• Step two: an "agent pile" forms. Many agents do overlapping work, each is kept up by one person, and each has a slightly different picture of the company.
• Step three: the company merges some of them into fewer, broader team agents, each with a named owner, used by many people and refined over time.

Each personal agent stops being useful the day its owner loses interest or leaves. Most teams she sees are in step one or two.

Two problems a team agent solves

• The bottleneck expert: one person knows how pricing exceptions or a big customer's setup work. Work waits when they are swamped, they get calls on vacation, and knowledge walks out when they leave.
• Work nobody owns: a customer moves from sales to marketing to customer success. Sales made a promise, marketing runs slightly different messaging, and customer success learns about the promise weeks before renewal. Each team has a piece and nobody has the whole picture.

Using AI in each step does not fix this, because the agents do not talk to each other.

Team agent versus skill library

Nufar uses "team agent" for one agent that many people talk to, with shared knowledge, shared memory and one configuration (instructions, skills, access and owner). A skill is a playbook for one specific task. A team agent handles a wide mix of ad hoc and repeated work and remembers what it learns. A skill library is one ingredient, not the same thing.

Sharing is a dial

There are three settings:

• Private agent: yours, with your taste and access. Nufar keeps her social media agent private because it should only sound like her.
• Shared knowledge, private agents: the team maintains one body of knowledge, and everyone points their own agent at it. Salespeople keep their own prospecting voice but share one picture of the ideal customer and company messaging. This is often the easiest place to start.
• Team agent: one agent, many users, its own job and owner.

If colleagues keep asking to borrow your private agent, that is a sign to share it.

Four archetypes of team agent

Each kind tells you what to watch for:

• Expert agent: one person's or small team's know-how, open to everyone who depends on it. Examples are a data agent, a pricing and deal desk agent, or a compliance agent. Interview the experts and collect their past answers. Involve them from day one, and tread carefully because it can feel like job insecurity.
• Common work agent: many people doing similar work in one shared way. You spot it when three people each built their own version. Examples are team research and meeting prep, or a marketing content agent. The hard part is agreeing a company standard while merging the best of three versions.
• Bridge agent: work that flows between roles, where handoffs break. A customer agent across sales, solutions, customer success and delivery is the classic case. Each function feeds in its own knowledge, and permissions need close attention.
• Chief of staff: owns the team's operating rhythm, such as decisions, commitments, status and onboarding. You spot it when the team repeats itself and new joiners take weeks to find their footing. You must define what it may learn and how it learns automatically.

Start with the expert agent

Asked which archetype is the best first step, Nufar said the bridge agent sounds most attractive but is hardest to execute. She has seen many successful expert agents that add redundancy and relieve bottlenecks. Nathaniel added that an "agentified" internal knowledge hub, such as HR policies through a chatbot, has been an easy early win for many companies.

Shared knowledge is the hard part

Once knowledge is shared, there are more contributors and more contradictions. Agreeing on how work is done, which definitions to use and which pricing policy is real is worth doing even if you never ship the agent. Nufar's four stages are in the frameworks below. She warns that a team agent with poor knowledge can cause "havoc" in the company, because it no longer serves just you.

Mental Models & Frameworks

Signs a team agent is wrong

Nufar gives three signs to wait:

• Taste beats standards: people truly need different answers, or their own voice is the point. Keep those agents private.
• Nobody can own the knowledge: if no one will maintain it, the agent drifts within weeks, sometimes days. Sort out ownership first.
• It complicates more than it simplifies: conflicting needs, tangled permissions or endless coordination mean more work than the agent saves.

She notes that sensitive data and high stakes are missing from the list on purpose. Those are design questions, not reasons to avoid a team agent.

Five core design decisions

• What it does: the roles it serves and its scope.
• Where it lives: the platform and visibility.
• What it knows: the shared ground truth.
• What it can touch: access and permissions.
• How you run it: owner, rules and monitoring.

Nufar used one running example, a bridge-type customer agent. It holds what the company knows about each customer and everything promised to them.

Scope by role, with don'ts

• List each role that will use the agent and what it will come to the agent for. Sales asks different things than delivery.
• Aim for one broad area of work, since team agents should be capable enough to justify their existence. The customer agent could prepare answers to "where do we stand with this customer", flag promises that commit other teams, and draft handoffs.
• Write a team "don'ts" list, which people often skip. Examples: it never makes a commitment on someone's behalf, it never settles a disagreement between people (those go to its owner), it never carries information from one private space into a shared one, and it never discusses one customer in another customer's space.
• Start narrow, with reading and drafting. Widen scope only as trust is earned.

Three ways to host it

• Shared folder: a folder of instructions and knowledge that each person points their own tool at. It is naive but a good stepping stone if the team already uses similar agentic tools.
• Vendor-hosted agent: the vendor hosts it and you configure it. Nufar named Claude, OpenAI's ChatGPT workspace agent, Copilot and Notion as examples.
• Self-hosted agent: something you run yourself, such as OpenClaw or Hermes, or a custom harness. It gives the most freedom and needs the most technical skill.

Her rule is to pick the simplest option that two people will actually use this week. For the customer agent, that is a channel agent in Slack or Teams.

Four stages for team knowledge

• Collect: interview the people who hold knowledge, harvest what is already written in channels, and let AI do the heavy aggregation. Each function contributes its own piece.
• Refine: merge sources, surface contradictions ("you will find five versions of the truth"), date everything, and keep out passwords, notes about people, and one customer's details in another customer's space.
• Approve: whoever owns each piece signs off, and the agent's owner assembles it.
• Maintain: decide what the agent may add to its own memory and what a person must review first. Put upkeep on a schedule, with the agent proposing updates and a person approving.

Whose access the agent uses

• Act as the asker: it only sees what the person asking can see. It is the safest choice and the right one when people have different access levels, but it is often the hardest to build unless the vendor did it.
• Its own account: scoped to exactly what the job needs. It fits when the whole team works on the same shared material.
• One person's login: only for read-only, non-sensitive material, because everyone who talks to the agent effectively gets that person's access. Nufar does not recommend it.

For the customer agent she would use act-as-the-asker, since sales, success and delivery see different things in the CRM.

Four rules for running it

• One owner: one person or a very small group owns priorities, maintains the agent, and decides when two people ask for opposite things. They also set standing instructions.
• Clear rules of engagement: tell people what it does, what it can see, who can see their chats, and how to correct it when it is wrong. Trust grows when people know what it learns and how.
• Decisions where it can see them: an agent only knows what is written somewhere it can reach. Decisions made in private messages or hallways never reach it.
• Keep watching: start with a small pilot group and keep a few test questions to rerun whenever a model, tool, knowledge or instruction changes. Retire the agent if it does not behave as expected.

Decision Principles

Principle: Pick the simplest host

• When: choosing where a team agent lives.
• Why: if people have to learn how to connect to it, adoption suffers. Meeting them in a Slack or Teams channel they already use is more likely to work.

Principle: Invest in ground truth, not tools

• When: deciding how much to build before big vendors ship native versions.
• Why: Nufar says the heavy lifting is configuration and knowledge curation. Pick the one tool closest to your existing stack and do the rest. When better tools arrive, you will already have agreed on the do's, don'ts and use cases. She would not spend energy building your own version of a product like Claude Tag.

Trade-offs & Nuance

Access safety versus build effort

Acting as the asker is the safest access model, but it is the most complicated to execute unless the vendor already supports it. A shared account is simpler, but everyone who can talk to the agent can use its access. Nufar's example is an agent with access to a pricing sheet placed in a channel of 40 people that includes a few contractors. All 40 can now get pricing by asking.

Shared learning versus private learning

An agent that learns is better than a frozen one, but the question is where that memory lives.

• Per person, so the agent evolves from your own interactions.
• Per channel or team.
• Across the whole workspace, where it evolves with everyone in public.

Nufar's one hard line is to never cross customers. She adds that a person's own definition should not quietly become everyone's without agreement.

Visibility of chats varies by tool

Who can see each person's conversation with the agent differs by product, and sometimes you can configure it. In Claude in Slack, everyone in the channel sees what the agent does and can steer it. In many other agents, your chat is private. Nufar says to check this and tell the team before the first real task, because trust is won or lost here.

Common Mistakes

Mistake: Leaking answers into shared channels

• Why it happens: the agent uses the asker's own access, and the asker has every right to ask. The answer then lands in a shared space in front of people who do not.
• Example: Nufar said Anthropic's documentation for Claude in Slack notes that it does not consider who else is in the channel. If you approve your connectors and it fetches everything you can see, others in the channel can see it.
• Better approach: send sensitive answers privately to the asker, not into a shared channel.

Mistake: Ignoring who can ask

When the agent has its own account, everyone who can talk to it can use that account. The agent then knows more than some people who can reach it. Decide who can talk to the agent with the same care you give to what it can see.

Mistake: Letting knowledge go stale

Team knowledge goes out of date quickly, and a wrong team agent affects everyone. Without an approval and upkeep process, the agent's knowledge drifts. Schedule regular update proposals with human review.

Practical Application

Audit your agents for merge candidates

List the agents your team already built and look for the signal Nufar describes: three people who each built their own version of the same thing, or a personal agent that colleagues keep asking to borrow. Those are your first team agent candidates.

Classify a candidate by archetype

• Do: decide whether a candidate is an expert, common work, bridge or chief of staff agent.
• Then: use the matching watch-out. Interview experts for an expert agent, agree a standard for a common work agent, map permissions per function for a bridge agent, and define what it may learn for a chief of staff agent.
• Why it works: the archetype tells you where the project is most likely to fail.

Write the don'ts list first

Before building, write what the agent must never do. Include never committing on someone's behalf, never settling disagreements, and never moving information from one private space to another. Then start with read and draft only, and expand scope as trust grows.

Run the four knowledge stages

Assign each function to contribute its piece. Merge and date it, and surface contradictions. Have each owner sign off. Then set a recurring review where the agent proposes updates and a person approves them.

Launch a small pilot

Start with a small pilot group. Keep a set of test questions you can rerun after any change to the model, tool, knowledge or instructions. Name one owner and tell users what the agent sees, who can read their chats and how to correct it.

Questions to Consider

• Which of your team's personal AI agents are doing overlapping work that a single team agent with a named owner could replace?
• Who on your team is the bottleneck expert whose knowledge, such as pricing exceptions or a key customer's setup, could be captured in an expert agent?
• If your agent joined a Slack channel of 40 people including contractors, who could get information out of it that they should not see?
• Does anyone on your team actually own the shared knowledge an agent would rely on, or would it drift within weeks?

Bottom Line

Team agents are worth building when a team can agree on ground truth and name an owner, and not otherwise. Make five deliberate decisions: what it does, where it lives, what it knows, what it can touch and how you run it. The configuration and knowledge work carries over to any future tool.

Tools & Products

People to Follow

Nufar Gaspar

Works with companies on how they build and use AI agents, and returns to the AI Daily Brief for Operator's Cut episodes. In this episode she gives the four archetypes and five design decisions for team agents.

Nathaniel Whittemore

Host of the AI Daily Brief. He has written about multiplayer AI, or shared and team agents, and helped build the free Multiplayer AI Sprint course.

Notable Quotes

"Some agents should stay yours and private while others should become the teams level agents." (Nufar Gaspar)

"The agent knows more than some of the people who can reach it." (Nufar Gaspar)

"The heavy lifting is always going to be the configuration and the knowledge curation." (Nufar Gaspar)