Insights
How to choose an AI partner for M&A and PE work: what to ask, what it should cost
Mitchel Campbell, Co-founder and CEO
· 7 min read
The short answer
Most firms comparing AI providers are comparing things that are not alike. A seat licence, an automation agency, a specialist implementation partner and an internal build all get described as "doing AI", and they fail in different ways. The question that separates them is not which model they use. It is who owns the result, who is accountable when it is wrong, and what happens to your firm if you stop paying.
This guide covers the four options, ten questions worth asking, what the work should cost, and the five answers that should end a conversation.
The four things you are actually choosing between
Software you subscribe to. A product with seats. It is the cheapest to start and the fastest to show you something. The trade is that it does what it does: your firm adapts to the tool, the workflow lives on someone else's roadmap, and when you stop paying it stops. Good when a standard problem is close enough to your problem.
A generalist automation agency. Builds workflows across industries, often very capably. The gap is domain: a team that has automated invoice processing and lead follow-up has not sat in a buyer process, does not know why a CIM is structured the way it is, and will not spot that a confidentiality rule has been broken. You end up supplying the judgement, which is the expensive part.
A specialist implementation partner. Builds inside your systems, in your market, and stays accountable for whether it works. Costs more than software and takes longer than a demo. Worth it when the work is confidential, when the output goes in front of clients or LPs, and when the process is specific to how your firm runs deals.
Building it in-house. Cheapest on paper, and the right answer if you have an engineer who will own it for years. The failure mode is not the build, it is month seven, when the person who built it is busy and the thing quietly stops matching how you actually work.
Nobody is going to tell you their own category is the wrong one. The questions below are how you tell.
Ten questions, and what good answers sound like
1. Who owns the code, the data and the workflows?
Good: you do, outright, running in your own accounts, with anything proprietary to the vendor licensed to you in a way that survives the relationship ending.
Bad: a long answer. Ownership is a short answer in a good contract.
2. Where does it run?
Good: inside your environment and your accounts wherever possible, with permissions aligned to client, fund, deal and team boundaries.
Bad: "in our secure cloud", with no detail on whose tenancy, what is retained, or for how long.
3. What happens if we part ways?
Good: it keeps running, you hold the keys, and you can take it in-house. Ask them to say that in writing.
Bad: a transition plan that depends on their goodwill.
4. What reaches a client, buyer, seller or LP without a human approving it?
Good: nothing. There is a review step, it is named, and someone at your firm clicks it.
Bad: anything that treats approval as a setting rather than a gate.
5. Who is actually building it?
Good: the people in the room, or named people you will meet. Ask who wrote the last thing they shipped.
Bad: a strategy team who will "scope it for delivery" by someone you have not met.
6. What do you know about my work?
Ask them to describe a buyer process end to end, or what goes wrong in diligence. You will know inside two minutes. Domain knowledge is the one thing that cannot be added later by a competent engineer.
7. What is the first workflow, and why that one?
Good: a specific process, chosen because it is where your hours actually go, with a baseline measured before anything is built.
Bad: a platform rollout, or a list of everything that is possible.
8. How will we know it worked?
Good: a number agreed in advance - hours returned, turnaround time, coverage, completeness - measured against where you started.
Bad: a demo, a dashboard, or "efficiency".
9. What does this cost, and what makes it cost more?
Good: a number or a range, and an honest account of what drives it: how many systems it touches, whether it writes back into them, how messy the source data is, and whether it sends anything externally.
Bad: "it depends", for longer than a minute.
10. What should we not automate?
Good: a real list. Advice, valuation conclusions, the negotiation, what goes to clients and LPs, the relationship itself.
Bad: no list. A provider with no limits has not thought about yours.
What it should cost
Almost nobody in this market publishes a price. Of ten providers reviewed in October 2026, two did. That makes comparison hard, so rather than a number, here is how to read the quotes you get.
The shape most engagements take. A paid diagnostic first - an audit or readiness assessment that tells you where the hours are and what to build first. Then a build, priced per workflow. Then an ongoing monthly fee for monitoring, tuning and the next workflow. Be wary of anyone who skips the first stage: a build quoted before anyone has measured your process is a guess.
What moves the number. More than three production systems. Writing back into those systems rather than reading from them. Permissions that differ by client, mandate or fund. Source data that is inconsistent or unstructured. Anything that sends externally, which needs deliverability work and a tighter approval gate. A workflow that touches one system and produces a document sits at the bottom of any provider's range; one that reads a data room, writes to your CRM and emails buyers sits at the top.
How to compare quotes that are not alike. Divide by the hours returned. A build that takes 500 hours a year off a team is cheaper than a quarter-priced one that takes off 60, and far cheaper than a seat licence nobody adopts. Ask every provider to state the hours and how they calculated them - and whether those hours are measured or modelled.
What to ask for in writing. The fee for the diagnostic, what it produces, and whether it credits against the build. The build price for the first workflow, fixed once scoped. The monthly fee and what it covers. What happens to the price when you add a second workflow.
How to run the evaluation
Thirty days is enough.
- Pick one process where you can say how many hours it takes today. If you cannot, that is the first finding
- Ask two or three providers the ten questions above, in writing
- Ask each for a scoped first piece of work, with a fixed price and a defined output
- Run it on live work, not a sandbox. The failure modes only show up on real deals
- Agree the measurement before you start, not after
A provider who will not scope a small first piece of work is telling you something.
Five answers that should end the conversation
- You do not own what we build
- The data leaves your environment and they cannot say precisely where it goes
- Nothing can be run on a live deal until the full rollout is complete
- There is no human approval step, or it can be switched off
- They cannot describe your work back to you
How we do it, for completeness
Analyst3 is the third category above. We start with a strategy and workflow audit that maps where your team's hours go and ranks what to automate first, quantified in hours and dollars. The highest-value workflow goes first, run by hand on live deals until your team signs off on the output, then wired into the systems you already use. You own the code, the data and the workflows, running in your own accounts. Nothing reaches a buyer, seller, owner, client or LP until someone at your firm approves it.
We built the firm this way because we have sat on both sides of the table: a decade in investment banking and corporate development on one side, and production AI engineering on the other.
If the questions above are useful and you end up hiring someone else, the guide did its job.