How to Merge Two Companies' AI Agents After an Acquisition

To merge two companies' AI agents after an acquisition, first inventory every agent on both sides, including its memory, tools and permissions. Then keep the agents separate until each has a named owner and a decided future. Combine only agents that share the same role, data rights and approval rules, and move them one at a time while the old agent stays available. The goal is not a single agent as fast as possible. It is that no agent keeps acting with authority nobody remembers granting.

Key takeaways

• Inventory before you decide anything. You cannot merge, retire or secure agents you have not listed, and the unofficial ones matter most.
• Separate by default and combine by decision. Two agents that sit side by side safely are better than one merged agent nobody can explain.
• Treat memory as data with a source and a set of rights, not as a pile of text to concatenate.
• Permissions do not transfer with the deal. Re-grant each one deliberately, to a named human owner, at the narrowest scope that works.
• Migrate one role at a time, with a tested way back, and judge each move by an observable result.

Why do AI agents need their own merger plan?

When two companies join, IT teams already expect to reconcile email domains, identity providers, contracts and software licenses. AI agents add a layer that is easy to miss because they do not look like software in the usual sense. An agent holds instructions written by a person, memory built up over months, and access to accounts that let it read and act. Some of those pieces belong to the acquired company, some to the buyer, and some to a vendor whose terms differ.

The risks are specific. An agent may keep working with credentials tied to a system you plan to shut down. Its memory may contain customer or employee information collected under terms the other company never agreed to. Two agents may answer the same customer question differently, because they were taught different policies. And the person who set one of them up may have left during the transition, taking the only explanation of why it behaves as it does.

Legal and regulatory duties also travel with the data. Where information may be stored and processed often depends on contracts and jurisdiction, which is why it helps to read AI data residency for business before you decide where a combined memory will live. A merger plan for agents is simply the discipline of answering four questions for each one: what is it, what does it know, what can it do, and who answers for it.

How do you inventory both companies' agents?

Start with a plain list, built from conversations as well as systems. Ask each department head what assistants, automations and chat-based tools their people use, then check against billing records, identity logs and the integration lists of your main business systems. Expect to find agents nobody mentioned, such as a sales assistant a team set up on its own or a bot connected to a shared mailbox.

For every agent, record the same fields on both sides so the lists can be compared directly:

• Name, purpose and the business role it performs, in one sentence.
• Human owner and a named backup owner.
• Channels it speaks through, such as email, chat, phone or a customer portal.
• Tools and systems it can reach, and whether it can only read or also write.
• Accounts and credentials it uses, and whose name they are registered under.
• Memory: instructions, knowledge sources, conversation history and any stored notes about people.
• Data categories it touches, including anything personal, financial or contractual.
• Vendor, model and hosting location, plus the contract that governs them.
• Approval rules: what it may do alone and what needs a human to confirm.
• Evidence of how well it works today, such as review notes or error reports.

The last field is the one teams skip. If nobody can say how well an agent performs, you cannot judge whether it deserves to survive the merger. Put the results on one page, using the approach in Draw Your AI Stack: A One-Page Architecture Map for Leaders, so that leaders from both companies can read the same picture. Mark anything with an unknown owner or unknown credentials in a visible color. Those are your first priorities, not your last.

Which agents should stay separate and which can be combined?

A combined agent sounds efficient, but efficiency is rarely the first thing to protect. Start from the assumption that each agent keeps running as it is, and move it only when a clear reason exists. The following guide helps you decide, agent by agent.

• Keep separate when the two agents serve different customers, markets or legal entities that still operate independently.
• Keep separate when their data rights differ, for instance when one company's customers agreed to terms that do not cover use by the other.
• Keep separate when either agent handles regulated or especially sensitive information and the review of the combined setup is not finished.
• Keep separate when the agent is tied to a system scheduled for retirement. Plan its replacement rather than carrying it over.
• Combine when both agents perform the same role, such as first-line support, for the same audience under one policy.
• Combine when one agent clearly outperforms the other on the evidence you recorded, and the weaker one adds little that is unique.
• Combine when the two companies already share one identity system, one approval structure and one owner who can answer for the result.
• Retire when an agent has no owner, no evidence of use, or access that nobody can justify. Archive its configuration first.

A middle path often works best: let the agents stay separate while presenting one front door to staff or customers. The routing can send a question to the right agent without merging their memory or permissions. It gives people consistency now and leaves the harder decisions for when you have evidence. If your agents come from different vendors, also check how easily each can be exported, because the merged design should not trap you with a provider chosen under different circumstances.

What happens to agent memory when two companies join?

Memory is where merging goes wrong most quietly. An agent's memory is not one thing. It usually includes four parts: the instructions that define its role and tone, the documents it retrieves to answer questions, the history of past conversations, and any notes it keeps about people or preferences. Each part needs a different decision.

Instructions are the easiest to compare and the most important to reconcile. Read both sets side by side. Where the two companies disagree on a refund rule, a tone of voice or an escalation path, a person with authority must choose, because the agent will not. Knowledge sources can often be combined once duplicates and outdated documents are removed, but tag each document with where it came from. That tag lets you remove it later if a contract or a regulator requires it.

Conversation history and personal notes deserve the most caution. Before you merge them, confirm that the terms under which the information was collected allow the new use, and that the people concerned would reasonably expect it. If you are not sure, leave that memory in its original place and let the combined agent start without it. A fresh start costs some convenience. A wrongly merged memory can cost trust that is hard to rebuild.

Before any migration, take a full backup of each agent and prove that you can restore it. The article on AI agent backup and restore explains what to save and how to test it. Keep the backup of the acquired company's agent even after you retire it, for as long as your records policy requires.

How should permissions and approvals be reconciled?

Permissions are the part of an agent that can cause real harm, so treat them as new grants rather than inheritances. An agent that could read the acquired company's finance system last month should not automatically be able to do so under new ownership. Credentials, tokens and service accounts are often tied to the original organization's identity system, and some will break during consolidation anyway. Use that moment to re-grant access on purpose instead of patching it back to how it was.

Work through each agent with a few principles, drawn from standard authorization practice:

• Give each agent its own identity, not a shared login or a person's account.
• Grant the narrowest access that lets it do its role, and prefer read-only access until there is a reason for more.
• Make sure every permission has a human owner who can approve, review and revoke it.
• Check that delegated access, such as OAuth grants to third-party tools, is reissued under the new organization and that the old grants are revoked.
• Log what the agent does with each permission, so a reviewer can see actual use against granted access.

Approval boundaries need the same care. One company may allow its agent to send customer emails alone, while the other requires a person to confirm each message. Do not average the two. Choose the stricter rule for the first period, then relax it for specific actions once the evidence supports it. For a structured way to do this, follow How to Run a Permission Review for Your AI Agents, Step by Step. The review should end with a signed-off list of what each agent can do, who owns it and when it will be reviewed again.

What is a safe order of work, and what does it look like in practice?

A sequence keeps the project calm. Each step produces something a leader can inspect.

• Step one: Freeze new agents and new tool connections on both sides until the inventory is complete, so the list stops growing.
• Step two: Complete the inventory and assign a human owner and a backup owner to every agent.
• Step three: Back up each agent and test one restore.
• Step four: Review permissions and revoke what has no owner or no justification, starting with credentials tied to retiring systems.
• Step five: Classify each agent as keep separate, combine, or retire, using the decision guide above, and record the reason.
• Step six: Migrate one role at a time, running old and new side by side, with a rollback plan and a clear success measure for the role.
• Step seven: Review the result with the people who use the agent, then retire the old one only after the new one has proved itself.

Here is an illustrative scenario, not a real case. A distributor buys a smaller service company. Each has an agent that answers customer questions by email. The inventory shows the distributor's agent is read-only and well documented, while the acquired company's agent writes to a ticketing system through a login belonging to an employee who has since left. The team revokes that login first, issues a dedicated identity, and keeps the two agents separate while a shared front door routes questions by customer type. Only after the refund policies are reconciled by a manager do they merge the instructions, and they leave the old conversation history in its original place.

Be Human handles this kind of work as part of designing and operating personalized AI infrastructure. In a first engagement we map the agents, memory, channels, tools and permissions on both sides, define one useful role at a time with its approval boundaries, and agree an observable success criterion before anything moves. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review and controlled changes, with the humans at the company keeping control of decisions. For the governance habits that make this repeatable, see AI Governance for Companies: A Lightweight Start for Mid-Sized Firms.

Frequently asked questions

Should we merge the agents right after the deal closes? Usually not. In the first period, prioritize the inventory, the owners and the permission cleanup, because those reduce risk immediately. Merge roles later, once you have evidence about which agent performs better and the data rights are clear.

Can we combine the two companies' agent memory into one knowledge base? Sometimes, but not as a single step. Combine instructions and reference documents first, tagging each by origin, and review personal or customer history separately against the terms it was collected under. If the rights are unclear, leave that history out of the combined agent.

Who should own the merged agents? Each agent needs a named human owner with authority over its role, and a backup owner. Ownership should sit with the business leader responsible for the work the agent does, with IT or a managed provider supporting the operation rather than deciding policy.

What if the acquired company's agent was built by a freelancer or a vendor we do not know? Treat it as unreviewed. Confirm who holds the credentials, what the contract says about the configuration and memory, and whether you can export them. Keep it running only within narrow permissions until you have that information, and plan a documented replacement if you cannot get it.

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