Why AI workflows in M&A fail silently, and what building them like software actually means

An analyst opens a workflow, runs it against a target company, and ten minutes later has a screening memo. The formatting is clean. The tone is right. The comps are there, the sourcing looks sensible, the sections are in the order a VP would expect. It reads like something that took an afternoon, not ten minutes. She sends it up the chain.

Nobody checks it, because it looks right. And looking right and being right are different claims. Nothing about that ten minutes told her which one she'd gotten.

That gap is the subject of this piece. Not because AI is unreliable in some vague sense, but because the way most of us build workflows today gives us no way to tell the difference. We write a prompt, run it, read the output, and if it looks plausible, we move on. That's not a workflow. That's a monolith with a good UI.

Here's what happens when that gap catches up with you.

The output that looked right

The report was a sector analysis: five comparable transactions in a defence technology sub-sector, laid out in a table with deal value, EBITDA, and multiple for each. The kind of table that goes straight into an IC pack. Formatting consistent, sourcing footnoted, five rows that all looked like they belonged to the same document.

One of those rows was a mid-sized acquisition, priced at 11.6x EV/EBITDA.

That number was never published. Neither party disclosed a multiple, and no outlet covering the deal reported one. What the workflow had was a disclosed deal value and an assumed EBITDA margin. It did what a spreadsheet does when you give it two numbers: divided one by the other and reported the result as if it were the third.

Nothing in the table said that. The 11.6x sat next to four real multiples, formatted the same way, footnoted the same way, reading with the same confidence. No flag, no asterisk, no column for "derived" versus "disclosed." An analyst scanning the table would have taken all five rows as the same kind of fact. Three would have been right to trust. One would not.

The number wasn't absurd. It wasn't 40x or negative or attached to the wrong company. It was plausible, in range for the sector, built using a technique an analyst might reach for themselves under time pressure. That is exactly why it didn't get caught. Nothing about reading the output would tell you which row was manufactured. The document gave you no way to ask the question.

The first fix looked reasonable. Label every figure: disclosed, estimated, or not disclosed, so a reader can see at a glance which is which. It reads like exactly the honesty the failure was missing. It didn't work. The estimated label didn't stop the fabrication, it gave it somewhere respectable to live. A number could now be manufactured and still be technically flagged, technically inside the rules, because the rules had quietly created a category whose entire purpose was to hold numbers nobody had confirmed. The label made the guess look governed. It wasn't. The only fix that held was removing the category entirely: a figure is published and cited, or it's absent. Nothing in between. No exceptions, not even arithmetic on two numbers that were each individually real.

Why a better prompt can't catch this

The instinct, once you've seen a failure like that, is to fix the prompt. Add a line: "only report disclosed multiples." Add another: "flag estimates clearly." It feels like the failure was a gap in instructions, and gaps in instructions get closed by writing better instructions.

That instinct is wrong.

A single prompt is doing three jobs at once. It states what's true: a multiple only counts if it was disclosed. It defines what the output looks like: a table, five rows, a multiple column. And it governs behavior when information is missing: what happens when a multiple wasn't published. Three kinds of instruction, one undifferentiated block of text, no mechanism forcing the model to treat them differently.

So when the rule "only report disclosed multiples" collides with the structural expectation "every row needs a multiple," nothing adjudicates which wins. The model doesn't fail loudly. It resolves the tension quietly, by deriving a number and reporting it in the same format as the real ones, because the structural instruction was easier to satisfy than the truth instruction was to enforce.

This is also why adding more instructions doesn't fix it. We ran the same workflow, same prompt, same brief, twice. One run sourced correctly. The other missed a live financing round entirely and reported a closed transaction as an unconfirmed rumour. Same instructions, same model, same inputs, different documents. The rule was competing with everything else in the prompt for the model's attention, and which instruction won wasn't consistent from one run to the next.

That inconsistency is the real problem. A workflow you can't trust is manageable: you know to double check it. A workflow that's right nine times and silently wrong the tenth, with no way to tell which run you're looking at, is the dangerous version. No amount of prompt refinement closes that gap, because the prompt was never the layer where consistency gets enforced.

What catching it actually requires

The fix is separating the three jobs so each can be enforced on its own terms, checked on its own terms, and changed without breaking the other two. That separation is what turns a prompt into a workflow (skills, in the vocabulary some of you will already know).

Here's where the fabricated 11.6x would have died. A truth layer that says don't derive it. A structure layer that never demanded a filled cell over an honest gap, because governing that trade-off was never its job. A behavior layer with a defined response to a missing figure: report it as not disclosed. No layer fighting itself, which is exactly what was happening inside the one-prompt version.

Take each in turn. The truth layer states what's true, independent of any document. A multiple only counts if it was disclosed. A missing figure gets flagged, not filled. No back-calculating one number from two others, ever. This layer doesn't care whether it's producing a sector report or a screening memo. It's the same rule set either way, which is exactly why it has to live separately from any one template. Bury it inside a single document's instructions and it silently stops applying the moment you build the next document type.

The structure layer defines what the output looks like. Columns, order, structure, sourcing. It says nothing about how to behave when a number isn't available. Its job is shape, not judgment.

The behavior layer governs uncertainty. What happens when a multiple wasn't published, when sources contradict, when the model doesn't know. This is the layer that decides "not disclosed" is a valid, correct answer, not a failure to fill in a cell.

The same separation fixes the consistency problem. A rule stated once, in a layer whose only job is stating rules, gets applied the same way regardless of which document it's assembled into. A rule buried in a long, busy prompt is competing for attention every single time. Separation doesn't make the model smarter. It removes the competition.

None of this is exotic. It's the same instinct that led software engineering away from writing every program as one undifferentiated block of logic: separate concerns so an error in one doesn't hide inside the others. Workflows built on language models need the same discipline, because the failure mode is the one software engineering solved decades ago, wearing a different costume.

Collaborating on Semaverse workflows

This is what we built, because we hit this

We didn't arrive at this by reading about it. We built Semaverse, a deal advisory platform for M&A teams, ran it against live client mandates, and watched the one-prompt version fail exactly this way, repeatedly, before we understood why.

And we didn't start with rules and structure. We started with agents, built to go out and do the research, draft the document, assemble the pieces, because that's what the work required. Only after watching failures like the fabricated multiple recur across mandates did we understand that the agents weren't the problem. Nothing above them was separating what's true from what the output should look like from how to behave when information was missing. The agents were doing exactly what they were built to do. They just hadn't been given rules built with that discipline.

What the agents were missing was instruction, not capability. A rule that says "flag gaps clearly" does nothing if the research agent has no instruction for how to frame a gap when it hits one: it defaults to narrating its own process instead. Once those instructions were right, they held. The agent layer turned out to be the most stable part of the system. It was the rules and structure layers that kept needing revision, template by template, document type by document type, as every new mandate taught us something the last one hadn't. That's why those layers are built as a shared, versioned surface, published, revision-tracked, editable by the person running the mandate rather than locked to whoever built the platform, because the person closest to a failed output is usually the one who spots the fix first.

What we haven't automated yet is the loop that closes it. Reviewing an output, finding what broke, tracing it back to the layer responsible: today that's work we do by hand, and it's how every example in this piece was found. We can see where it goes next: a validation pass that checks a finished output against its own claimed sources, actual verifiable ground truth, not the rules it was supposed to follow, and surfaces automatically what we currently find manually. A figure can pass every rule in the system and still be wrong, if the rule had a gap or something upstream changed. The loop isn't another layer to build alongside the others. It's the check that closes the circle back to them. We're not there yet. But knowing the loop needs closing, rather than assuming a good rule set closes it on its own, is itself part of the discipline this piece is arguing for.

None of this required a smarter model. It required treating the whole system with the discipline you'd bring to any software you expected to run correctly more than once. That's what we'd say to any team building this themselves, with or without us: get the execution layer solid early, then expect the rules and structure on top of it to keep changing as you learn what actually breaks.

Looking right was never the same as being right

Go back to the analyst who sent the memo up the chain. Nothing about that moment was careless. The output was clean, well sourced, structured the way these documents are supposed to be structured, and she did what anyone does with a document that looks right: she trusted it.

That's the part worth changing. Not the trust itself, but what it's resting on. The fix isn't reading outputs more suspiciously or double checking everything by hand: that's not a workflow, that's just slower distrust. The fix is building the thing so the question "is this actually right" has an answer built into how it was produced, not something you reconstruct after the fact by re-deriving every number yourself.

Most of what runs on AI in M&A right now is still the version from the first section. A good prompt, a clean output, no check underneath verifying the work. It'll be right most of the time. That's exactly the problem. Right most of the time is indistinguishable, on the page, from right all of the time, until the one time it isn't, and by then it's gone out under someone's name.

Next time an output looks clean, the useful question isn't "does this look right." It's "what would have to be true for this to be wrong, and would I be able to tell." If you don't have a good answer, the workflow producing it isn't finished yet, no matter how good the last output looked.