A Shared Team AI Identity Changes How You Lead

A private AI chat is something one person does alone. Nobody else sees the prompt, the wrong first answer, or the three tries it took to get something usable. A shared AI in a team channel is the opposite. Everyone sees it.

That single difference, visibility, is the part a leader now has to manage, and it is not the part most governance conversations are about.

When Anthropic launched Claude Tag on 23 June 2026, it moved the unit of AI collaboration from the private conversation to the shared channel. In Anthropic's own description, within a given Slack channel there is one Claude that interacts with everyone, so anyone can see what it is working on and pick up the conversation from where the last person left off. It remembers relevant information from the channels it is in and can plan out tasks to complete later. Anthropic says tagging Claude is now one of its main ways of getting things done, with 65 per cent of its product team's code created by an internal version of the tool.

The access questions that raises, which channels it sits in, what it can reach, what it may do on its own, matter and are covered in governing the shared AI teammate as a surface. This piece is about the other half, the half no permission setting fixes. A standing AI identity that the whole team can see changes how the team behaves in front of each other. That is a leadership problem, and it lands before the tool is anywhere near a regulator's concern.

What actually changes when the AI works in the open?

Three things move the moment an AI identity becomes shared and visible, and each of them is a human dynamic rather than a technical one.

The first is that the AI's mistakes become public. A private chatbot's wrong answer is seen by one person, who quietly fixes it and moves on. A shared AI's wrong answer sits in the channel, drafted in front of the whole team, sometimes half-built into something a colleague then picks up. The error is not worse, but it is witnessed, and witnessed errors carry social weight that private ones do not.

The second is that ownership blurs. In a private workflow the person at the keyboard is obviously the person responsible for what they send. In a shared channel, one person tags the AI in, another refines its output, a third takes the result into a client email. When something is wrong, the honest answer to who owns this is unclear, and unclear ownership does not stay unclear for long. It resolves, usually onto whoever was nearest the send button, which is the dynamic covered in when the AI gets it wrong, who carries it. A shared identity makes that resolution both more likely and less fair, because more hands touched the thread.

The third is that the AI becomes a visible voice in the room. It answers quickly, in complete sentences, with a confidence that reads as authority. In a private chat you weigh that confidence yourself. In a channel, everyone reads it at once, and the group has to decide out loud whether to agree with the machine. That is a new social situation, and how a leader handles it sets whether the shared AI sharpens the team's thinking or flattens it.

Who owns what the shared AI says?

Start here, because it is the question that will arrive first and hardest.

The rule that holds up is simple and needs saying before the first public error, not during it: the AI never holds accountability, and a named human owns any output that leaves the channel. This is not new law. It is the same standard you would apply to a junior's draft. The AI drafting in the open does not change who answers for the work, but it does make people feel it might, which is exactly why it has to be said plainly.

The subtlety a shared identity adds is that the nearest-human answer is now ambiguous by design. Anthropic built Claude Tag so that work is picked up mid-task by whoever is free. That is the feature. It also means that when a draft goes wrong, three people can each reasonably say it was not really theirs. Left alone, that ambiguity does not protect anyone. It concentrates the blame on the person who happened to be last, and it teaches everyone else to avoid being last. Neither is what a leader wants from a collaboration tool.

Decide ownership the way you would decide decision rights on any AI-enabled workflow: in advance, by name, per kind of output. For anything the shared AI helps produce that a third party will see, one person owns release. Tagging the AI in is not ownership. Refining its draft is not ownership. Being the one who took it out of the channel and into the world is.

Here is a message a leader can post in the channel in the first week to set that ownership norm. It is meant to be said in your own words, not pasted verbatim, but the shape matters.

Team norm for [CHANNEL_NAME] and [SHARED_AI_NAME]:

- [SHARED_AI_NAME] produces drafts, never final decisions.
- Whoever takes a piece of its work to [EXTERNAL_AUDIENCE] owns that piece,
  including checking it. Tagging it in or tidying it up is not ownership.
- If its draft is wrong, that is normal and expected. Say so in the channel.
  Correcting it in the open is the behaviour we want, not a fault.
- When you are not sure who owns something it drafted, ask before it leaves
  the channel, not after.

Does a visible AI change how openly people speak?

This is the quieter risk, and the one most likely to be missed because it leaves no error to point at.

Amy Edmondson's work on psychological safety, first set out in Administrative Science Quarterly in 1999 and developed in The Fearless Organization in 2019, defines it as a shared belief that a team is safe for interpersonal risk-taking, where people feel able to raise questions, concerns, ideas and mistakes without fear of embarrassment or punishment. Her finding is that teams learn better when that belief holds. A visible, persistent AI identity in a channel can push against it in two specific ways.

The first is performance. When people know their thinking is on display, next to an AI whose output looks polished, some stop thinking out loud and start posting only finished-looking contributions. The messy half-formed idea, the one that turns out to matter, goes unsaid because it will sit in the channel next to the machine's clean prose. The channel gets tidier and the team gets less inventive.

The second is anchoring. The shared AI answers first, fast, and with fluency that reads as certainty. Once its answer is in the channel, disagreeing with it is no longer a neutral act. It is disagreeing in front of everyone with something that sounds authoritative, and quieter members will simply not do it. The AI's confident wrong answer can then stand unchallenged, not because the team agreed with it but because the social cost of the first objection was too high.

Neither of these is inevitable, and both are within a leader's control. The lever is the same one covered in setting your team's AI norm by how you use it: the team copies what the leader does, not what the policy says. If the leader treats the shared AI as a first draft to argue with, visibly corrects it on a low-stakes task, and thanks the person who spots its error, the visible surface becomes a place where challenging a confident answer is normal. If the leader defers to it, so will everyone else.

A short list of what to watch for in the first month, none of which shows up as a system alert:

• The channel goes quiet on half-formed ideas and fills only with finished-looking posts.
• Nobody has disagreed with the shared AI in the open, on any task, which is a red flag rather than a sign it is always right.
• Credit for good AI-assisted work is claimed loudly while responsibility for its errors goes unclaimed.
• People start addressing the AI to make a point to each other, using it as cover rather than as a tool.
• The most junior members stop tagging it in, having learned that being last on a wrong draft is unsafe.

A worked example

Consider a mid-sized operations team, call it [TEAM], that turns on a shared AI identity in its main planning channel. In the first fortnight, output rises and the channel feels faster. Then a weekly status summary the AI drafted goes to [SENIOR_STAKEHOLDER] with a figure that was never true. Three people had touched the thread: [PERSON_A] tagged the AI in, [PERSON_B] tidied the draft, [PERSON_C] forwarded it.

The instinctive move is to ask who sent it, which lands on [PERSON_C] and teaches the team that forwarding is dangerous. The leadership move is different. Because ownership was named in week one, [PERSON_C] already owned release and the check that went with it, and the leader takes the public accountability for the workflow that let an unchecked figure travel. The conversation in the channel is about why the check was skipped and how the shared draft looked finished enough to trust, not about who to blame. The next week, the leader deliberately catches the AI in a small error in the open and says so, and two quiet team members follow with corrections of their own. The visible surface starts doing the opposite of suppressing candour.

Nothing in that example is a feature toggle. All of it is how the leader chose to treat the shared identity in front of the team.

Do this Monday

1. Name who owns a shared AI output before you use it in anger. For any work the AI helps produce that leaves the channel, one named person owns release. Post it in the channel in plain words.
2. Post the ownership and drafts-not-decisions norm. Use the message above, in your own voice. Say that questioning the AI is expected, not a challenge to whoever tagged it in.
3. Model one open correction this week. Catch the shared AI in a small, low-stakes error and fix it in the channel where everyone sees, then thank whoever helped. This one act sets more norm than any document.
4. Ask the AI to hedge, not assert. Set its channel instruction so it flags uncertainty rather than answering everything with the same confidence. A prompt for this is below.
5. Watch for the quiet signals for a month. Run the short list above at your regular team check-in. Silence toward the AI is data, not comfort.
6. Revisit the norm once, out loud, at week four. Ask the team what the shared identity has changed about how they talk to each other, and adjust the norm from what they say.

Here is the channel instruction to give the shared AI itself, so its own behaviour supports candour rather than working against it.

Operating instructions for [SHARED_AI_NAME] in [CHANNEL_NAME]:

- Open drafts by stating what you are unsure about before what you are sure of.
- When a request is ambiguous, ask one clarifying question rather than
  guessing confidently.
- Label anything you could not verify as unverified, in plain words.
- Present options with trade-offs, not a single recommendation, unless asked
  for one directly.
- Never imply that your output is final or approved. It is always a draft for
  [TEAM] to decide on.

The judgement boundary

Some of this cannot be delegated, to the AI or to a setting. Whether the team feels safe to disagree with a visible machine is set by how the leader treats that machine in public. Who owns a shared output is a decision only a leader can make and make stick. What the team learns from the first public error, that errors are workflow problems to fix or that they are people to find, is decided in the leader's first three sentences after it happens. None of that is in the admin console. All of it is in the room.

What genuinely sits with the tool is narrow and worth keeping narrow: drafting, remembering the channel's context, and carrying a task forward while people do other things. Useful, real, and not the same as judgement. The moment a shared AI's confident output starts standing in for the team's own thinking, the leader has a dynamics problem the vendor cannot solve. Catching that early, and naming it, is the job.

Bottom line

A shared AI identity moves the AI from a private tool into a visible member of the team's conversation, and that visibility is what a leader now manages. Its mistakes become public, ownership of its output blurs across the several hands that touched a thread, and its fluent, confident answers can quietly anchor a discussion so that dissent never surfaces. None of those is fixed by an access setting, and all of them are shaped by how the leader behaves in front of the team. The workable moves are small and early: name who owns any output that leaves the channel before the first error arrives, make explicit that the shared AI produces drafts rather than decisions and that questioning it is expected, and model one open correction so the team learns that disagreeing with a confident machine is normal. Whether a standing, visible AI sharpens the team's thinking or flattens it is not a property of the tool. It is a property of how it is led.

References

• Anthropic, "Introducing Claude Tag", 23 June 2026.
• Amy C. Edmondson, "Psychological Safety and Learning Behavior in Work Teams", Administrative Science Quarterly, vol. 44, no. 2, 1999.
• Amy C. Edmondson, The Fearless Organization, Wiley, 2019.