AI agents or workflow automation: what a deal firm actually needs

A surprising share of the administrative weight in a deal firm is rule-shaped. Files that need naming and filing the same way every time. Status updates assembled from fields that already exist. Follow-up reminders on a cadence. Stage transitions that trigger the same checklist each time. None of this needs intelligence; it needs consistency, and consistency is exactly what deterministic automation delivers.

Automation of this kind has two properties a small firm should prize. It behaves the same way on the ten-thousandth run as the first, so nobody has to check its output. And when it breaks, it breaks visibly and loudly rather than plausibly and quietly. A rule that fails produces an error; a model that fails produces something that looks right. That difference decides where each belongs. Anywhere an unchecked mistake could reach a client, the duller tool is the safer one.

Language models earn their keep where the input is unstructured and the output is a draft a person will review. Reading a folder of accounts in inconsistent formats and pulling the figures into a model. Producing the first version of a teaser from the firm's own template and the company's real documents. Turning a call recording into structured, filed notes. Summarising what changed in the latest turn of a legal document.

The common thread is judgement over messy material, with a person deciding what happens next. That last clause is not a caveat; it is the design. A model in a deal workflow produces drafts, and drafts are most of the value: the hour of assembly is gone, and the ten minutes of review remain. Nothing in that arrangement asks the firm to trust a model with a decision. It asks only that assembling a first version stops costing an afternoon.

Automation fails by rigidity. The deal that does not fit the stages, the file named unusually, the exception the rules never anticipated: rule-based systems handle these badly, and the fix is a person and an explicit path for exceptions. What automation will not do is invent. It cannot produce a plausible wrong number, because it cannot produce anything it was not given.

Models fail in the opposite direction: gracefully, fluently and sometimes wrongly. That is manageable when the output is a reviewed draft and dangerous when it is not. The practical rule we apply: anywhere an unreviewed mistake could reach a client or a counterparty, either use deterministic automation or insert a human checkpoint. There is no third option worth having. The two failure shapes also need different responses. Rigidity is answered by giving exceptions a route to a person; fluency is answered by making the check cheap enough that it always happens.

The systems that work in practice interleave the two. Automation watches the mailbox and files the attachment; a model reads it and drafts the summary; automation routes the draft to the right person and chases the review; the person signs it off; automation files the result and updates the pipeline. The model sits inside a deterministic frame that feeds it, bounds it and checks its work into the record.

This is also the honest answer to the reliability question. A firm does not have to trust a model with its process. It has to trust it with the one step where judgement over messy material is the job, inside a frame that makes checking cheap. Built that way, how far to trust AI stops being a matter of opinion about models. It becomes a question about one step, with a person on either side of it, which is a question a firm can actually answer.

Take the moment a signed NDA arrives by email. A rule-based automation recognises the attachment, files it against the right mandate with the right name, moves the deal to the next stage, opens the checklist for that stage and tells the partner. Every step was written down by a person in advance, and the system does exactly that, every time. Nothing is interpreted. If the attachment is missing or the sender is unknown, the automation stops and asks a person rather than guessing.

That predictability is why we put automation first. It works against the mailbox, folders and trackers the team already uses inside the firm's own Microsoft 365 tenant, so nobody changes how they work and no data passes through Verdalyze's servers. The log shows what happened and why, and the manual step stays available as a fallback until the team trusts the automation enough to retire it.

Now take the data room that opens the following week. An agent reads the folder, extracts the key terms and figures from documents that vary in format, and drafts a summary of what is unusual, with each figure traced to its source page. That is judgement over messy material, and no rule could be written for it in advance, because the documents are different every time.

The agent's output is a draft. A named person reviews it, corrects it and signs it off before anything reaches a client or counterparty. The model is grounded in the firm's own documents rather than answering from general knowledge, model calls run under enterprise terms that exclude training on the firm's data, and the whole workflow stays behind the firm's existing access controls. The agent can therefore never show a person a document that person could not already open.

A working deal system uses each tool where it is strong and hands off between them at explicit points. The frame is deterministic; the model sits inside it. This is the shape most of our workflows take:

• Automation captures: an email, a file or a stage change triggers the workflow and gathers the inputs.
• The model drafts: it reads the material and produces a first pass, with sources shown.
• Automation routes: the draft goes to the right person, with a reminder if it sits unread.
• A person decides: the draft is corrected and signed off, or rejected.
• Automation records: the result is filed, the pipeline is updated and the log is written.

The proportions vary by workflow, but the pattern holds: the model is one step in five, and the four around it are what make its output cheap to check and safe to rely on.

Three questions usually settle it. Could a competent person write down the rule for this task in a paragraph? If yes, automate it; a model would be slower, dearer and less predictable. Does the task involve reading or writing prose, or interpreting documents that vary? That is model territory, with review. Would a plausible-but-wrong output be expensive? Then a person signs off, whatever the tooling.

Applied honestly, the test routes most of a firm's administrative weight to plain automation and reserves the model for the handful of steps where it is genuinely the only tool that works. That ratio is unfashionable and correct, and it is also cheaper to run and easier to trust.