It is Monday morning and a new target has just landed. Someone on the team says it out loud: didn't we look at something almost identical last year? Everyone half remembers. Nobody knows where it is. The person who led that diligence has moved on to another deal, or another firm, and by lunchtime the team has opened a fresh checklist and started from the top.
If you have worked on deals, you have lived some version of that morning. We want to talk about why it keeps happening, why the obvious fixes never quite solve it, and what we think a good answer looks like. We build software in this space, so we say so at the end, and you can weigh the rest accordingly.
Where the knowledge goes
Think about what a team actually learns during a diligence, and then about where all of it ends up.
The data room belongs to the seller, and it closes when the process does. The investment memo captures the conclusion but rarely the path to it: the issues that looked serious in week two and were settled by week four barely leave a trace. The red flag report was written for one committee, on one date.
And the really valuable part, the question a senior colleague asked that nobody else thought of, the clause that looked standard and wasn't, lives in comments, in calls, in an email thread that three people were copied on.
Nobody is being careless. Deals run on deadlines, and a deadline rewards getting the work out, not filing it neatly for whoever comes next.
What firms usually try
Most firms have tried at least one of these, and each of them helps a little.
A shared drive with a folder per deal keeps the documents safe. But to find the right precedent you still have to remember which deal it was in, which is exactly the thing people forget.
A checklist library tells you what to ask. It doesn't tell you what the team found the last time they asked it, or why it ended up mattering.
A search tool, even a clever one with a language model on top, finds documents that contain the words you typed. It has no idea that the tax advisers later contradicted a finding in that memo, or that a partner corrected how everyone was reading a change of control clause two deals ago.
What they share is that each deal gets treated as a closed file. Yet what makes a deal useful for the next one is precisely what happened inside it: what was compared, what was questioned, what someone fixed.
What would actually help
When we talk to deal teams, the wish list is short.
First, precedent they can trust, which means precedent with its source attached: which deal, which document, which section, which version, and what was finally decided. A vague feeling that we have seen this before does not survive an investment committee.
Second, a heads up. If the new data room contradicts something found in a comparable deal, or is missing a document that deal had, they want to hear it from the system, not from the committee.
Third, and this is the one that surprises people, a memory of corrections. When an expert fixes a misreading, that fix should reach the next team on its own, not stay in the inbox of whoever happened to receive the email.
What to ask any system that promises this
These are the questions we would put to any supplier, and the ones we expect to be asked ourselves.
Does every answer show the exact passage it comes from? A lawyer or an analyst should be able to check it in seconds rather than take it on trust. That depends far more on how documents are retrieved than on which model writes the answer, which is why retrieval augmented generation is only as good as what it retrieves.
Are permissions enforced when information is retrieved, or tidied up afterwards? Deal material is confidential by nature, often under agreements that limit who can see it. If the system holds several deals, what it knows about one client's process must never show up in another's.
Who decides when the system's knowledge changes? If a new finding would alter an existing conclusion, the system should propose the change and let a person approve it, reject it or roll it back. Quietly overwriting what the firm knows is not acceptable.
And can you take it all with you? Everything the system has learnt should be exportable in open formats. If you ever change supplier, the precedent stays with the firm.
A sensible first step
Don't start with every deal the firm has ever done. Pick one type of transaction you see again and again, the one where the team most often says we have done this before. Gather the closed deals of that type, with their memos and final findings.
Then sit down with someone who worked on them and write twenty real questions a new joiner would ask at the start of a similar diligence, with the answers agreed in advance. Add a handful the system ought to refuse, because the material simply doesn't support an answer. Run them, and look at the passages behind each answer, not just the answer itself.
The test we like best is this one: the tenth diligence of that type should move faster than the first. If it doesn't, the knowledge is still walking out of the door.
Not just an M&A problem
We have told this story through a due diligence because that is where the problem is easiest to see, but the same thing happens in plenty of other teams.
In legal, someone negotiates a liability clause that was already argued over with another client two years ago, and the position agreed back then is buried in an email. In procurement, a supplier gets assessed without anyone knowing that another site had trouble with them and wrote it up in a report nobody can find. In sales, a proposal is built from scratch when a very similar one was already won, or lost, for reasons someone noted down and nobody read again.
The documents change and so does the vocabulary, but the pattern is the same: knowledge is created by doing the work, it ends up scattered, and the next team starts over. The questions above apply just as well to any of those cases.
Full disclosure
We build one of these systems, BeAI 2nd Brain. M&A is one of the areas we designed it for, but not the only one.
Where we put most of our effort is the architecture, because that is what decides the quality of the answers and how well the system fits each organisation. It is flexible and modular: every agent is made of six explicit parts, the model, the prompt, the tools, the skills, the middleware and the long-term memory, and each one can be tuned on its own. A new agent is a configuration document, not a new release of the platform.
In practice, that lets us choose, for each deployment, the combination that answers best on the client's real documents, and shape the system around their sources, the way they work and their access rules, instead of asking them to adapt to it. It runs in the client's own Azure tenant, and quality thresholds are agreed for each project and checked against real cases whose answer is known in advance, just like the test we suggested above.
Everything above is what we would want any team to hold us to.