AI Agent Due Diligence Before an Acquisition

Quick answer

Verify four things specifically, beyond the standard technology and IP diligence checklist: who actually owns the rights to the system prompts, fine-tuned weights, and training data the target used to build the agent, what the target's real containment and escalation rates are versus what their pitch deck claims, whether the agent has ever been the subject of a customer complaint, regulatory inquiry, or legal claim tied to a wrong or harmful output, and what vendor contracts the agent depends on and whether those contracts survive a change of control. Any of these left unchecked can turn into a liability or an integration cost that was never priced into the deal.

This is different from evaluating a vendor

Selecting a vendor for your own AI agent, covered in what to put in a vendor RFP or bake-off, is a forward-looking evaluation: you are choosing a partner for a system you have not built yet. Acquiring a company that already has an AI agent live in production is a backward-looking diligence problem: you are inheriting a system, its history, its data, and its legal exposure, whether or not the deal team fully understands what that system does. The two exercises share some questions but the acquisition case has a much higher cost of getting it wrong, since you cannot walk away from a vendor relationship post-close the way you could decline to sign an RFP.

Verify IP ownership of the agent itself, not just the product it sits in

Standard M&A technology diligence checks source code ownership and open source license exposure. It often misses whether the target actually owns the rights to the system prompts, any fine-tuned model weights, and the training or fine-tuning data used to build the agent, versus licensing some or all of that from a vendor or a departed contractor under terms that do not survive an acquisition. Ask directly: if this deal closes, does the acquirer have unrestricted rights to continue operating, modifying, and retraining this agent, and get that answer in writing before valuing the agent as an asset rather than treating it as a liability wrapped in a demo.

Independently verify the metrics, do not take the pitch deck's word for it

A target's investor deck will quote containment rate, cost savings, and customer satisfaction numbers for their AI agent. Request the underlying production quality metrics and raw transcript samples, not just the summary slide, and have your own team or a third party independently verify containment rate, escalation rate, and a sample of actual conversations for accuracy and tone. It is common for a pre-acquisition metrics deck to reflect a best-case period or a narrow use case rather than the system's real steady-state performance across its full conversation volume.

Check for a pre-existing liability trail

Ask specifically whether the agent has ever been the subject of a customer complaint, a regulatory inquiry, or a legal claim related to a wrong, biased, or harmful output, separate from the general litigation disclosure schedule most deals already require, since AI-agent-specific incidents do not always get flagged the same way a product liability claim would. Cross-reference this against what actually counts as legal liability for a wrong AI agent answer to understand what exposure looks like even if no claim has been filed yet, since an unfiled but plausible claim is still a real valuation risk worth pricing into the deal or covering with a specific indemnity.

FAQ

Who on the deal team should own AI agent diligence?

Whoever owns technical diligence should own the IP and metrics verification, but legal should independently review the liability trail and contract survivability questions, since those are legal exposure questions, not engineering ones, even though they concern a technical system.

Should AI agent diligence findings affect deal price or just deal terms?

Both are reasonable depending on what you find. A weak IP position or an undisclosed liability history is often better addressed with a price adjustment or a specific indemnity than a walk-away, since the agent's value to the acquirer usually still exceeds the risk once it is properly priced in.

What if the target cannot produce clean documentation of how the agent was built?

Treat that gap itself as a finding. An agent with no clear record of what data trained it, what prompts drive it, or what vendors it depends on is harder to safely operate post-close and should be priced and planned for as a higher-integration-risk asset, not assumed to be fine because it currently works.