I use agents heavily in my own life. Or workers, as I prefer to call them.
One monitors changes in areas I care about. Another deals with repetitive admin. Others keep projects moving without requiring me to check everything myself.
They are useful because they were built around me. I even built my own harness.
They use my tools. They know what I want monitored, what can be handled automatically and when I need to be involved. Their jobs reflect my habits, priorities and tolerance for risk.
You might find the setup interesting. Copying it would be less useful.
My workers would arrive with instructions written for my life, connections to tools you might not use and rules based on decisions you never made. You could borrow the idea, but you would probably need to build your own workers.
Companies are now doing the same thing at a much larger scale.
I recently read about one large professional-services organisation operating around 6,000 digital workers. Some research, some monitor, some write code and some support delivery work. The exact number matters less than the direction: agents are starting to become part of how companies operate, rather than an experiment sitting beside the real work.
We will also see more AI inside transactions.
Agents can scan data rooms, review contracts, compare datasets, test assumptions and maintain an updated view of diligence findings as new information arrives. A 2026 survey of more than 230 active dealmakers found that 51% of M&A teams were already using AI and another 31% were piloting it. Due diligence was identified as the largest near-term opportunity.
That is the obvious side of AI in M&A:
How can agents help you execute the deal?
I am more interested in the reverse question:
What happens when the business you are buying already relies on agents?
Imagine acquiring a division whose finance team uses a worker to check invoices. Another helps procurement review supplier requests. Employees have adjusted their jobs around them.
The division uses these workers every day. But the parent operates the platform, pays the bills and controls access to the systems they use.
Do they come with the business?
That brings me back to my own setup. You might borrow the idea behind one of my workers, but you would want it connected to your tools and following your instructions. A buyer will have much the same decision to make.
Some agents may be worth adapting. Others may be unnecessary because the buyer already has its own way of doing the work.
But if you are lifting and shifting a process largely unchanged, include the agents performing it. Otherwise, you could transfer the same workload and the same small team while leaving behind the workers that made that staffing level possible.
Before deciding what should move, I would ask three questions:
- What does the agent know that the buyer is not allowed to keep?
- Which tools and identities break on Day 1?
- Who owns the rules the agent is executing?
1. What does the agent know that the buyer is not allowed to keep?
Take a procurement worker used by the division being sold.
It receives a supplier invoice, finds the corresponding purchase order, checks the contract and decides whether the case can proceed or needs human review.
The agent may look as though it belongs to the division.
But perhaps it searches a group-wide contract repository. It uses supplier-risk information collected across several businesses. It compares requests with purchasing patterns from the whole company.
Some of that context may transfer with the division.
Some of it may belong to businesses the seller is retaining. Some may include commercially sensitive information, employee data or supplier terms the buyer is not entitled to receive.
The worker can transfer while much of what made it effective stays behind.
That creates an odd ownership problem.
The division may have requested the agent.
A central technology team may have built it.
The parent may own the platform.
Several businesses may have contributed the data.
Employees across the group may have gradually corrected its behaviour.
Asking, “Which department uses the agent?” does not settle who owns the capability.
The buyer needs to understand whether the agent can still do its job using only the information the acquired business is entitled to keep.
Perhaps it can.
Perhaps its accuracy falls slightly and more cases require human review.
Or perhaps the agent was effective precisely because it could see beyond the division.
The same issue applies to customer operations.
Suppose an agent knows that a certain type of complaint should be escalated immediately.
Why?
Maybe similar complaints led to major customer losses elsewhere in the group. Maybe a central customer-service team noticed the pattern and added the rule. Maybe the agent retrieves examples covering products the buyer is not acquiring.
The buyer might receive the final instruction:
Escalate complaints that match this pattern.
What it may not receive is the history that explains the rule.
That history matters when the business changes and someone needs to decide whether the rule still makes sense.
A company’s agents are built from more than prompts and code. They also contain traces of the company’s experience.
In a carve-out, not all of that experience necessarily belongs to the business being sold.
2. Which tools and identities break on Day 1?
Knowing what to do is only half of a worker’s job.
It also needs the tools and permission to do it.
The procurement worker may access the finance system through a parent-company identity. It may retrieve contracts through a group API, update supplier records in a shared platform and send exceptions to a central team.
Copying the worker’s instructions does not recreate any of those connections.
The buyer may use a different finance system. Its purchase orders may be structured differently. Its identity model may not recognise the agent. The person who should receive an exception may sit in a completely different organisation.
You can transfer the worker and discover that it no longer has anywhere to work.
Over time, I think buyers should have their own agents.
Their workers should reflect their systems, permissions, policies and operating model. An agent designed around the seller’s environment should not automatically become the buyer’s end state.
But the transition matters.
Suppose the division has reduced its finance team because agents now perform much of the invoice processing. The transaction then lifts and shifts the process and the reduced team, but leaves the agents behind.
The same workload arrives on Day 1.
The digital workers do not.
The buyer has inherited a staffing gap disguised as an AI benefit.
If you lift and shift a process, you need to understand which agents are doing part of the work. Either bring them across for the transition or put enough human capacity back into the process.
You cannot move the lean team while leaving part of its workforce behind.
Then there is the cost.
Do these agents have a cost?
Obviously, yes. I am less convinced that cost per agent is a useful number.
One worker may wake up once a week, check a handful of items and stop. Another may process thousands of transactions every day.
The cost may include model usage, software licences, data access, hosting, orchestration, monitoring, testing and the people maintaining the platform. Inside a large group, several of those costs may be absorbed centrally rather than appearing in the division’s P&L.
Six thousand agents sounds enormous.
It tells you almost nothing about the standalone cost without knowing what those agents actually do.
The useful calculation is closer to:
What does it cost to deliver this process at the required volume and level of control, with the agents and people it needs?
A target may report that agents allowed it to avoid ten hires.
That may be accurate.
But if the buyer now needs its own agent platform, additional software access and a team to operate it, the standalone saving will be lower than the figure visible in the target’s current cost base.
The AI benefit has not disappeared.
Part of its cost was simply sitting elsewhere in the parent company.
3. Who owns the rules the agent is executing?
Suppose the agent transfers with the right information, tools and permissions.
It can now work inside the buyer’s environment.
It may still be doing the wrong job.
Imagine a customer-service worker that automatically approves refunds below €200.
Why €200?
Perhaps the parent decided that investigating smaller claims cost more than accepting them. Perhaps the threshold was introduced during a period of unusually high customer complaints. Perhaps it reflects the economics of a much larger group.
The buyer may want a €100 threshold.
It may have different margins, different customer promises or a different tolerance for fraud.
The agent can be technically healthy while applying a policy the buyer does not want.
This is why ownership cannot stop at assigning someone to maintain the software.
Who owns the rule?
Who can change it?
Who understands why it was introduced?
Who decides when the business has changed enough to reconsider it?
The answers may sit with people who are not part of the transaction perimeter.
A central finance team may understand why certain invoices receive additional review.
A group compliance team may know why a supplier triggers an alert.
An operations manager may know which exceptions are harmless and which are early signs of a larger problem.
The agent has made their decisions repeatable.
That does not mean it has made their judgment transferable.
Some of the reasoning may appear in its written instructions. Other parts may sit in examples, approval thresholds, evaluation cases and years of human corrections.
A rule such as “send unusual cases to group finance” can hide a large amount of human work.
Someone in group finance receives the case, interprets the issue, contacts another department and makes a decision.
If that team remains with the seller, changing the destination email address will not recreate what it did.
This is where the employees transferring with the business become especially important.
They know which rules reflect a real business need, which were inherited from the parent and which exist because of a limitation in an old system.
Consultants can help make those judgments visible.
Take real cases handled by the agents. Look at where people intervened. Understand why they accepted or rejected the recommendation. Identify which decisions belong to the acquired business and which were borrowed from the parent.
Then decide what should survive the separation.
The aim should not be to copy every instruction.
It should be to preserve the judgment the buyer still needs.
Does the agent belong in the perimeter?
There will not be one answer for every agent.
Some workers will clearly belong to the parent. They may support several businesses and depend almost entirely on shared systems.
Others will be tightly linked to the division. They may perform work that would otherwise require additional employees on Day 1.
Some should transfer temporarily because the underlying process is being lifted and shifted.
Some should be rebuilt around the buyer’s tools.
Others should disappear because the buyer does not want the process or rule they were created to support.
The decision should follow the work.
What process is transferring?
How much of it is currently performed by people?
How much is performed by agents?
Which context, tools and judgment allow those agents to operate?
If the worker disappears, what has to be added back?
Carve-out teams already spend a great deal of time identifying applications, contracts, data, people and shared services.
Agents sit across all five.
They use applications.
They act through contracts and subscriptions.
They depend on data.
They encode decisions made by people.
They may rely on shared services that are invisible in the target’s headcount.
That is why they cannot be treated as another line in the software inventory.
An AI-enabled business may appear standalone because the agents are already working.
The real test is whether they will still work once the parent company is gone.
When you acquire an AI-enabled business, are you buying its digital workers—or only the results they produced while connected to somebody else’s company?