AI agent platform due diligence

Once a letter of intent is signed on an AI agent platform, diligence needs to move quickly into the records that show what the agent has actually done, because that history is a better predictor of what you’re inheriting than any product demo. A platform that takes autonomous action carries a different risk shape than an ordinary software product, and the documents that matter most here are not the ones a generic small-business checklist would prioritize first.

The audit log is document one

Request the complete history of actions the agent has taken on customers’ behalf, in whatever form the platform actually keeps it. If a full audit log doesn’t exist, that is itself a finding — not a formatting issue to work around, but a sign the seller cannot currently show you what the product has been doing in production, which should shape both the price and the terms you’re willing to accept.

Trace every integration and its re-authorization requirement

Each system the agent acts on — a CRM, an ERP, a finance tool — typically needs its own re-authorization once ownership changes, and some of those re-authorizations depend on cooperation from the customer or the connected platform’s own vendor, not just paperwork on your side. Map every live integration before closing and confirm none of them will silently break or require a customer’s active participation you haven’t planned for.

Read the indemnity language in every customer contract

Every customer contract likely says something about what happens if the agent takes an action the customer didn’t want — whether that language exists as a liability cap, an indemnity running from the vendor to the customer, or nothing addressing it at all — and you need to read each one rather than rely on a summary, because the terms are rarely identical across a customer base built up over time. Confirm whether that indemnity language actually assigns cleanly to a new owner on a change of control, since some contracts cap liability differently, or trigger a renegotiation right, the moment ownership changes. Whatever allocation of liability exists in these contracts today is the allocation you inherit at closing, and it is worth knowing before you sign rather than after the first incident that happens under your ownership.

Chase the IP assignment on orchestration and guardrail code

The same contractor-IP gap that affects any software acquisition matters more here, because the code in question is the code that decides what the agent is allowed to do. Request the signed assignment for every contractor who built orchestration logic, permissioning rules or guardrail code, and treat a missing one as a live ownership question rather than a formality.

Pressure-test the incident history

Cross-check whatever incident log the seller provides against what the seller’s own customer support or legal function actually has on file, and ask customers directly where the relationship allows it. An incident that was resolved informally and never properly logged is exactly the kind of thing that resurfaces as a claim once you own the business and the customer decides to pursue it.

Confirm the regulatory posture, not just the marketing page

Check the platform’s actual compliance work against PIPEDA and, for Quebec customers, Law 25’s automated-decision disclosure requirements, rather than relying on a privacy-policy statement. Review any marketing claims about task-completion rates or reliability for whether they could draw Competition Bureau scrutiny if they turn out not to be substantiated, since that exposure would become yours.

Verify the regulated-domain assessment was actually done

Ask for documentation showing the seller identified which customer use cases have the agent acting inside a regulated domain — initiating payments, or producing output that reads as financial or legal guidance — and what was done about each one, rather than accepting a general assurance that nothing has come up. The absence of any such assessment is itself a finding, because it means the exposure hasn’t been sized, not that it doesn’t exist. Cross-reference this against the customer list and the actual workflows the agent performs for each one; a use case the seller describes informally as low-risk sometimes looks different once you see exactly what the agent is doing in production, and that gap is worth surfacing before you close rather than after. Where the platform serves customers in more than one province, check whether the assessment accounted for provincial differences too, rather than treating one province’s rules as though they applied everywhere.

Findings that should stop the deal

• No audit log of actions the agent has taken, or one the seller cannot produce in full.
• An undocumented incident where the agent acted incorrectly, with customer liability still unresolved.
• Total reliance on a single foundation model’s tool-calling feature with no fallback plan.
• Contractor-built guardrail or orchestration code with no signed IP assignment.
• Customer contracts that block assignment on a change of control with no consent obtained.
• No documented assessment of which customer use cases touch a regulated domain, or indemnity terms so inconsistent across the customer base that liability exposure can’t be sized.