Most teams already use AI. The problem is that everyone uses it alone.
One developer has a prompt that writes great release notes. Someone in support has a chat thread that drafts perfect replies. A PM keeps a document of instructions they paste into a chatbot every Monday. None of it is shared, none of it is consistent, and when that person goes on leave, the workflow goes with them.
A shared agent fixes that. Instead of ten private assistants, the team gets one agent with the same instructions, the same data, and the same rules, available to everyone who needs it.
In this guide, I'll walk through how to build your team's first one: how to pick the right job, set it up safely, choose a platform, and roll it out without it turning into another tool nobody uses.
Personal Agent vs Shared Agent
A shared agent is not just a personal assistant with more users. Once a whole team depends on it, the design questions change.
| Personal agent | Shared agent | |
|---|---|---|
| Who uses it | One person | A team, channel, or department |
| Instructions | Lives in one person's head or chat history | Written down, versioned, owned |
| Data access | Whatever that person can see | Scoped to what the whole team should see |
| Output quality | Judged by one user | Has to be consistent for everyone |
| When it breaks | One person notices | The whole workflow stalls |
| Owner | The user | A named person responsible for upkeep |
The last row matters most. A shared agent without an owner slowly drifts out of date until people stop trusting it.
Step-by-Step: Building Your First Shared Agent
1. Pick one repetitive job, not a vision
The biggest mistake is starting with "an AI assistant for the whole team." That's too vague to build and too vague to judge.
Start with one job that already happens every week and follows a pattern. Good first candidates:
- Standup or weekly summaries from tickets, commits, or channel activity
- Triage of incoming bugs or support requests into the right queue
- First drafts of release notes, changelogs, or customer replies
- Internal Q&A over your docs, runbooks, and onboarding material
A simple test: if you can't describe the job in one sentence, it's too big for a first agent.
2. Write down what "good" looks like
Before touching any tool, collect three to five real examples of the output you want. Paste in last week's best release notes or the triage decisions a senior engineer made.
These examples become your instructions and, later, your test cases. Without them, every teammate judges the agent against a different picture in their head.
3. Decide where the agent lives
Put the agent where the team already talks. If your team works in Slack, a web app nobody opens will die quietly. If work lives in Jira or Teams, start there.
This single decision usually narrows your platform options to two or three. I cover those in the next section.
4. Connect only the data it needs
A shared agent sees what you give it, and everyone who uses it can potentially surface that data. So scope carefully:
- Connect the specific channels, projects, or folders the job needs
- Avoid private channels, HR folders, and anything with credentials
- Prefer read-only access until the agent has earned trust
When in doubt, start narrower. Adding a source later is easy. Explaining why the agent quoted someone's salary is not.
5. Write instructions like an onboarding doc
Treat the agent's instructions the way you'd brief a new hire:
- Role: what it's for and who it serves
- Inputs: which sources to use, and which to ignore
- Output format: structure, length, tone, with an example
- Boundaries: what it should never do, and when to hand off to a human
Keep the instructions in a shared, versioned place, not inside one person's account.
6. Set permissions and an owner
Decide three things explicitly:
- Who can use it (a channel, a group, the whole org)
- Who can edit it (usually one or two people)
- Who owns it (one named person who reviews it monthly)
Most platforms separate "can use" from "can edit." Use that. A shared agent that anyone can quietly rewrite becomes unpredictable fast.
7. Pilot with a small group
Roll it out to three to five people for two weeks. Ask them to flag every bad answer, not just the dramatic ones. Feed those back into the instructions.
8. Measure something simple
You don't need a dashboard. Track one or two things:
- How often people actually use it each week
- How much of its output gets used with light edits versus rewritten
If usage drops after the first week, the agent isn't saving time yet. Fix that before expanding.
Where to Build It
You don't need to write an agent from scratch for your first one. Most teams already pay for a tool that can host a shared agent, and engineering teams have a dedicated option too. Pick based on where your team works, not on which model is trendiest.
| If your team lives in | Option | How sharing works |
|---|---|---|
| Slack | Claude Tag (Claude Team and Enterprise, in beta) | One agent per channel that anyone there can @-mention; admins control which tools, data, and channels it can access |
| Microsoft Teams / M365 | Copilot Studio | Publish the agent to Teams, then share it with teammates or submit it to your org catalog |
| Jira / Confluence | Atlassian Rovo agents (paid Cloud plans) | Agents built in Rovo Studio run on your team's Jira and Confluence data, metered by Rovo credits |
| Google Workspace | Gemini Gems | Shared like a Google Drive file; recipients can use, edit, or copy the Gem |
| ChatGPT Business / Enterprise | Custom GPTs | Share invite-only, by link, or with the whole workspace, with "can chat," "can view settings," or "can edit" permissions |
A few notes from comparing these:
- Chat-native agents (Slack, Teams) get adopted fastest because nobody has to open a new tab.
- Gems and custom GPTs are the quickest to set up, but they work best for reusable instructions plus documents, not for agents that act across your tools.
- Rovo and Copilot Studio go deeper into their own ecosystems, which is great if your work already lives there and limiting if it doesn't.
Sharkly: for engineering teams sharing coding agents
If your team's first shared agent is a coding agent, the platforms above only solve part of the problem. Tools like Claude Code and Codex are powerful, but they usually run on one developer's machine, in one person's session. The rest of the team can't see what the agent is working on, who assigned it, or whether anyone reviewed the result.
That's the gap Sharkly is built for. It's a shared workspace where people and AI coding agents work from the same task board.
In practice, that means a team can:
- Assign tasks to coding agents the same way they assign them to teammates
- Run several agents in parallel, each in its own isolated worktree
- Keep context, progress, and results together in one shared workflow
- Add human review before agent work is accepted
- Connect Jira, so agent runs stay traceable in existing project workflows
This maps neatly onto the steps in this guide. The task board gives the agent a clear job, the workspace makes ownership visible, and the review step keeps a human in the loop.
One distinction matters: Sharkly doesn't replace your coding agent. It adds the team layer of assignment, coordination, and review on top of tools your developers already use. According to Sharkly's own guide, it's free for organizations of up to 5 people, and agents don't take up seats.
For a small engineering team, that makes it an easy way to run a first shared-agent pilot without a budget conversation.
If none of these fit, frameworks and agent SDKs let you build your own. For a first agent, though, the platform you already pay for is almost always the right call.
Common Mistakes to Avoid
- Starting too broad. "Help the team with anything" produces an agent that's mediocre at everything. One job first.
- Connecting everything. More data is not better data. Irrelevant sources make answers noisier and raise the risk of leaking something sensitive.
- No owner. Instructions go stale, sources move, and nobody notices until the answers are wrong.
- Letting everyone edit. Separate who uses the agent from who changes it.
- Skipping the human check. For anything customer-facing or irreversible, the agent drafts and a person approves.
- Measuring nothing. If you can't say whether it saves time, you can't justify expanding it.
Final Thoughts
Your first shared agent doesn't need to be impressive. It needs to be useful, trusted, and owned.
Pick one job your team repeats every week. Write down what good looks like. Put the agent where people already work, give it only the data it needs, and assign someone to keep it healthy.
Get that right once, and the second and third agents become much easier, because your team will already know how to brief, test, and trust them.
One job. One owner. One place. That's how teams move from personal AI to shared AI.
Top comments (1)
🤩