Adding a Second AI Agent: What to Reuse and What to Separate

Add a second AI agent by sharing what describes your company and separating what grants access or holds private context. Approved knowledge sources, house style, tool connector definitions and logging can be reused. Credentials, permissions, conversation memory, channels and budgets should belong to each agent, so a mistake in one cannot travel to the other.

Key takeaways

• Share what is true for the whole company: policies, reference documents, tone and approved tool definitions.
• Separate what grants power or holds private context: accounts, credentials, permissions, working memory and channels.
• Copy a skill, do not share it live, when the second agent needs a similar procedure but with different risks.
• Give each agent its own owner, its own success criterion and its own budget, even if one team runs both.
• Add the second agent only after the first has a stable record, because every weakness in the first will be inherited.

Why does a second agent change the design?

The first agent is usually built as a single bundle. One set of accounts, one memory, one list of tools, one person who knows how it all fits together. That works because there is nothing to compare it with. The moment a second agent arrives, every item in the bundle becomes a decision: does it belong to the company, to the role, or to one agent?

If you skip that decision, the second agent tends to be cloned from the first. Cloning is fast, and it quietly copies everything: the broad permissions granted during early testing, the memory full of one team's habits, the connection to a mailbox the new role has no reason to read. Months later nobody can say why the sales assistant can see finance folders.

The better frame is that you are no longer running an agent. You are running a small set of roles on shared infrastructure. A one-page picture of that infrastructure helps, and the architecture map for leaders is a good way to draw it before you decide anything. If you are still deciding whether the work belongs in a new role at all, the article on one company agent or one per team covers that earlier question.

What can the second agent safely share with the first?

Sharing is not the problem. Unplanned sharing is. These are the things that are usually safe, and often wise, to reuse, provided the access to them is read-only or otherwise controlled.

• Company reference knowledge: product descriptions, policies, glossaries, brand guidelines, approved templates. One maintained source is better than two that drift apart.
• Tone and writing rules: the way the company speaks should not depend on which agent is answering.
• Tool connector definitions: how the company talks to its calendar, document store or ticketing system can be written once. What each agent is allowed to do through that connector is a separate matter.
• Logging and audit format: if both agents record actions in the same structure, one person can review both without learning two systems.
• Evaluation method: the way you test the first agent (a fixed set of realistic tasks and an agreed definition of a good result) can be reused, with new tasks for the new role.
• The model provider relationship: contract terms, data handling commitments and regional choices are usually company-level, not agent-level.

A useful rule: share anything that would be embarrassing to find inconsistent. If a refund policy appears in two places and the two versions disagree, customers will notice. If it lives in one maintained place that both agents read, they cannot disagree.

Shared knowledge still needs care about what goes into it. Retrieval from a common library means the second agent can surface anything in that library, so documents that are meant for one role should not sit in the common pool. Guidance on how context is assembled for agents, such as Anthropic's piece on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), is a good reminder that what an agent can see shapes what it does.

What must stay separate?

The separate list is shorter but matters more. Each item here either grants the ability to act or holds information that was shared in confidence.

• Accounts and credentials. Each agent should sign in as itself, with its own identity, not with the first agent's login or a person's. When an agent acts, you want the record to say which one. Delegated access standards such as [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2) exist so access can be granted, scoped and revoked per party.
• Permissions. Start the second agent from nothing and add what the role needs. Do not start from a copy of the first agent's rights and subtract. The principle of granting only what is needed is a standard part of [authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).
• Working memory. What an agent learned from a conversation with a customer, a manager or a supplier belongs to that role's context. A shared memory means one agent can repeat to a colleague something told to another in private.
• Channels. A role that answers customers should not also listen on the internal leadership channel. Give each agent its own entry points so it is clear who is speaking and who is being spoken to.
• Write access and irreversible actions. Anything that sends, pays, deletes or publishes needs its own approval boundary per agent.
• Budgets and usage limits. If both agents draw on one allowance, a busy week for one silently starves the other. Separate limits also make it obvious which role is costing what. The article on usage limits and budget alerts shows a practical setup.

The common thread is blast radius. If one agent receives a malicious instruction hidden in an email or a web page, separation limits what that instruction can reach. That is the same reason guidance on prompt injection stresses limiting what an agent can do, not only what it is told.

How do you decide, item by item?

When an item is unclear, ask these questions in order. The first question that gets a yes tells you what to do.

• Would a mistake with this item be hard to undo, or would it affect someone outside the company? Then separate it.
• Does it contain information given to one role in confidence, such as customer details, personnel matters or negotiations? Then separate it.
• Does it grant the ability to act, spend, send or change records? Then separate it, and grant the minimum.
• Is it a procedure that both roles follow, but with different risk levels? Then copy it, and let each copy evolve under its own owner.
• Is it a fact about the company that should read the same everywhere? Then share it, from one maintained source.
• Is it a format or a method, such as log structure or test approach? Then share it.

The word copy in the fourth question is deliberate. A shared skill sounds efficient, but when two agents depend on one live instruction set, a change made for one role changes the other without anyone deciding that. A copy has a cost, because you maintain two. It also gives each owner the right to change their own agent. If a change does need to reach both, treat it as a formal request. The process in how to request and approve changes fits this well.

A step-by-step plan for adding the second agent

This sequence keeps the first agent stable while the second one is built. It assumes the first agent already has a defined role and a record of how it performs.

• Step one: write the job for the new role in a short paragraph. State what it does, what it never does, who owns it and how you will know it works.
• Step two: inventory the first agent. List its accounts, knowledge sources, tools, skills, channels, memory and limits, so you know what exists before you decide what to reuse.
• Step three: classify each item as share, copy or separate using the questions above. Write the answer next to the item, with one line of reasoning.
• Step four: create the second agent's identity and credentials from nothing. Grant only what step one says the role needs.
• Step five: connect shared knowledge as read-only, and confirm the second agent cannot reach documents that belong to other roles.
• Step six: build the evaluation set for the new role from realistic tasks, including a few where the correct behaviour is to refuse or ask for approval.
• Step seven: run the second agent with a small group, with the first agent unchanged. Compare logs of both to confirm that neither is acting on the other's context.
• Step eight: review permissions of both agents after the first weeks of real use, and remove anything granted but never used.

Step eight is easy to skip and is where most drift is caught. The guide to a step-by-step permission review describes how to run it without a large team.

What does this look like in practice? An illustrative scenario

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

A small distribution business has a first agent that answers supplier and order questions for the operations team. It reads the order system, drafts replies and logs everything. The owner now wants a second agent to help the finance lead chase overdue invoices.

The tempting move is to copy the first agent and change the instructions. Instead, the team walks through the inventory. The product and policy documents are shared, read-only, because both roles need the same facts. The writing rules are shared, so customers hear one voice. The log format is shared, so the owner reviews both in the same place.

The mailbox connection is separated: the finance agent gets its own identity and can only draft messages, with a person approving anything that goes to a customer about money. Conversation memory is separate, so a supplier's private remarks to operations never appear in a payment reminder. The reminder template is copied, not shared, because the finance team will want to adjust its wording without affecting the operations replies. Each agent has its own monthly limit, and the finance agent has a named owner in the finance team.

Two months later the operations agent needs a change to how it handles shortages. The change touches only its copy of the procedure and does not require any review of finance. That is the benefit of the separation, and it costs a little more upkeep.

How does Be Human handle a second agent?

Be Human treats the second agent as a new role on infrastructure the client already controls. We start with the inventory of the first agent, classify each item as shared, copied or separate with the client's owner, and give the new agent its own identity, permissions, memory and limits. Shared knowledge and logging stay in one place so both agents can be reviewed together, and approval boundaries are agreed before the agent goes live. Managed operations then include monitoring both agents and periodic permission review, and any change that affects both goes through a documented request.

For how a new agent behaves once it is live and how changes should be introduced, the article on updating an agent in production without breaking it is a useful companion.

Frequently asked questions

Should the second agent use the same model as the first? Not necessarily. The model is a company-level choice that you can share, but a different role may justify a different model for cost or quality reasons. Keep the evaluation set so you can compare results before changing.

Can two agents share one knowledge base? Yes, and for company-wide facts it is usually better than keeping two copies. Make the access read-only, keep role-specific or confidential documents in separate collections, and give a named person responsibility for keeping the shared material current.

When is it too early to add a second agent? When the first has no clear success criterion, no owner, or permissions nobody has reviewed. The second agent will inherit those gaps and add its own. Stabilize the first role, then expand.

Who should own the second agent? A person in the team that benefits from the role, with the authority to approve its actions and changes. Shared infrastructure can still have a single operator, but each role needs its own accountable owner so questions about behaviour have a clear destination.

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