One Company Agent or One Per Team? How to Structure AI Roles

Most companies need fewer agents than they expect at the start, and more than one over time. A sound starting point is one agent per clearly defined role: not one per team by default, and not one for the whole company. Add another agent only when its permissions, memory, channels or accountable owner differ from the ones you already have.

Key takeaways

• Count roles, not departments. An agent is a role with defined access, memory and an owner, so the number of agents follows from how many distinct roles you delegate.
• Split agents when permissions, data sensitivity, audience or approver differ. Do not split only because the topic or the team name differs.
• One shared agent is reasonable for a small group with the same access and the same approver. It becomes risky when memory and permissions start to blur across teams.
• Several agents still need shared standards: identity rules, logging, approval boundaries and a named owner for each role.
• Grow in steps. Prove one role, record the requests it cannot handle, then decide for each request whether to extend the role or create a new one.

Why the count is the wrong first question

Leaders often picture one of two shapes. The first is a single company-wide assistant that everyone talks to. The second is a seat for each department, mirroring the org chart. Both are understandable, and both skip the question that actually decides the design: what work are you delegating, what can the agent touch, and who is accountable for it?

The number of agents is a result of those answers. If you start from the number, you tend to build around convenience. A single agent is easy to announce. One per team is easy to budget and assign. Neither guarantees that access is appropriate or that someone owns the outcome.

There are real costs at both ends. A single agent with broad access collects instructions from every team until nobody can predict how it will behave. Its memory mixes conversations that should never meet. A very large set of narrow agents has a different cost: duplicated setup, drifting instructions, several connections to maintain and no clear answer to the question "which one do I ask?"

The useful middle is to treat each agent as a defined role, much as you would treat a new hire. You would not hire one person to be sales support, payroll and facilities coordinator on day one, and you would not hire a separate person for every five-minute task either.

What makes two agent roles genuinely separate?

A role is more than a topic. A workable role description covers the purpose, the channels the agent works in, the tools it can use, what it remembers, where it must stop and ask a person, who owns it, and how you will know it is doing well. Writing that down is the fastest way to see whether you have one role or two. A job description for your first AI agent role is a good template for this exercise.

Two workloads belong in separate roles when they differ in at least one of these ways in a way that matters:

• Permissions: one needs to read billing records, the other must never see them.
• Data sensitivity: one handles ordinary operational notes, the other handles personnel or legal material.
• Audience: one talks to colleagues, the other writes to customers or partners.
• Memory: what one learns should not be available to the other.
• Approver: different people decide whether its actions are acceptable.
• Success criterion: the way you would judge each one is different.

Topic alone is a weak reason. An agent that summarizes meetings and an agent that drafts follow-ups often share the same inputs, the same permissions and the same owner, so they can reasonably be one role with two workflows. Meanwhile, two agents that both "help with customers" may need to be separate if one only drafts and the other can send.

One shared agent or one per team?

Both shapes can be correct. The deciding factor is how similar the teams' access and accountability really are.

A single shared agent tends to work when:

• The group is small and the people already share most of their information.
• The work is similar across users, such as drafting, summarizing and tracking follow-ups.
• The agent needs the same read access for everyone it serves.
• One person can be named as the owner and reviewer.

A per-team agent tends to work when:

• Teams hold different data that others should not see, such as finance, people operations or legal.
• Each team has its own approver and its own definition of good work.
• The tone, vocabulary or process differs enough that one set of instructions would become a compromise.
• Failures in one team's workflow should not affect another's.

The quiet risk of a shared agent is memory. If an agent remembers a sensitive conversation with one person, it can surface that detail when talking to someone else, even without any malicious intent. Instructions telling the agent to "keep things confidential" are not a control. Access decisions should be enforced by the systems around the model, on every request, which is the same principle that sound authorization guidance applies to any software. If the boundary matters, build it into permissions and separate memory, not into a sentence in a prompt.

The quiet risk of per-team agents is sprawl. Each new agent needs an identity, connections, tests and someone to review it. If three teams want nearly identical agents, it is often better to build one well-run role and configure what differs, rather than three loosely maintained copies.

A decision guide for splitting or keeping roles together

When a new request arrives, run it through these questions in order. Stop at the first answer that points clearly one way.

• Does the new work need access to data the current agent should not have? If yes, create a separate role. Do not widen the existing one.
• Does it need the ability to send, publish, pay or change records, when the current agent can only read and draft? If yes, treat it as a separate role with its own approval boundary. The difference between read, draft and send permissions is one of the clearest dividing lines.
• Would the same person approve its work? If a different person or team is accountable, lean toward a separate role.
• Should it remember different things from the existing agent, or deliberately forget some of them? If yes, separate it.
• Does it face a different audience, such as customers instead of colleagues? If yes, separate it, because mistakes cost more and the standard of review differs.
• Can you test and judge it with the same success criterion? If not, a separate role is easier to measure.
• If none of the above applies, add it as another workflow on the existing role, and extend its tests.

Notice what is absent from the guide: the org chart. Teams matter only through the differences they create in data, approval and audience. When those are the same, a shared agent is simpler and cheaper to keep healthy.

What should stay shared across several agents?

Splitting roles does not mean splitting everything. Some things work better when they are common to all agents, because consistency is what makes a group of agents governable.

• Identity rules: each agent should have its own account and credentials, not a borrowed employee login, so that its actions can be traced and its access revoked on its own. The reasoning is covered in why your company agent needs its own identity and accounts.
• A permission standard: the same method for deciding what each role can read, draft and send, starting from the smallest useful access, as described in least privilege for AI agents.
• Logging and review: a common way to see what each agent did, what it asked a person to approve and what failed.
• Escalation conventions: when an agent cannot proceed, it should hand a clear decision to a named person in a consistent format.
• A role register: a single list of every agent, its purpose, its owner and its last review date.

This shared layer is where lightweight governance earns its place. You do not need a large committee. You need a few written rules that every role follows, and a person who can answer for each agent. A lightweight start to AI governance for mid-sized companies lays out how small that can be. Risk frameworks such as the NIST AI Risk Management Framework are a useful reference for what to cover, even if you adopt only a fraction at first.

An illustrative scenario and a plan for growing

The following is an illustrative scenario, not a description of a real company.

A professional services firm starts with one agent for its operations lead. The agent reads meeting notes, drafts follow-ups and proposes updates to the customer records for a person to approve. It cannot send anything on its own. After a quarter, the team trusts it enough to ask for more.

Finance asks for help answering invoice questions from clients. That work touches billing data and involves writing to customers, with the finance manager as approver. Running the decision guide, it needs data the first agent should not have, a different audience and a different approver. It becomes a second role with its own identity and its own memory.

Then sales asks for help preparing proposals. The inputs are the same customer records and meeting notes, the approver is the same operations lead, and the agent still only drafts. It does need a library of scope templates, which is read-only. That request is added as a workflow on the first role, with new tests, instead of becoming a third agent.

The firm ends up with two agents, not because it has two teams asking, but because two roles differ in access and accountability. A plan that produces this outcome looks like this:

• Step one: define a single role with a written purpose, tools, memory, approval boundaries, an owner and one observable success criterion.
• Step two: run it with the smallest useful permissions, ideally with a person approving anything that leaves the company or changes a record.
• Step three: keep a simple log of requests the agent cannot or should not handle, along with who made them.
• Step four: after a period of stable use, take each logged request through the decision guide and decide whether it extends the role or needs a new one.
• Step five: for every new role, give it its own identity, its own memory space and its own tests before it touches real work.
• Step six: review the whole set on a schedule. Merge roles that have converged and retire those nobody uses.

The discipline is in step three and step four. Requests arrive from enthusiastic colleagues, and without a log and a guide, each one gets an informal yes. That is how a company ends up with one overloaded agent or a drawer full of forgotten ones. If you need help choosing the very first workflow, keep it small enough to prove before you plan the rest.

How Be Human handles agent structure

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Additional roles are added only when the differences in permissions, memory, audience or owner justify them, and each one has its own identity and its own review. Managed operations can include monitoring, recurring evaluations, permission review and integration maintenance, so that the set of agents stays understandable as it grows. The service is remote and available in English and Portuguese.

Frequently asked questions

How many AI agents does a small company need? Often one, for one well-defined role. A small team with the same access and the same approver can share an agent safely, and adding a second one makes sense when a new workload needs different data, a different audience or a different person to approve its work.

Should every department have its own agent? Not automatically. Department names are a weak signal. Give a department its own agent when its data, approvals or audience differ from what an existing agent handles, and otherwise add its work as a workflow on a shared role.

Can one agent safely serve the whole company? It can, but only for work where everyone has the same access, such as general drafting or summarizing non-sensitive material. Once the agent needs sensitive data or the ability to act in other systems, a single company-wide agent becomes hard to control, because its memory and permissions have to be broad enough for everyone.

What is the biggest mistake when structuring agents? Widening one agent's access every time a new request arrives. It feels efficient, but it quietly turns a narrow, testable role into a broad one that nobody can fully predict. Create a new role when the decision guide says the differences are real, and give it the smallest access that lets it do its job.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.