“AI transaction coordination” is used to mean everything from a chatbot on a help page to software that genuinely moves a deal forward. This is the mechanism, so you can tell which one you are being sold.
The problem being solved
A transaction generates dozens of emails from a dozen senders, each carrying something the file needs: a report, a commitment, a status, a date. The work of coordination is mostly the work of routing — deciding what each message is, which deal it belongs to, what it changes, and who needs to know.
Traditional transaction software does none of that. It waits for a person to open it and type. That is the gap, and it is a routing problem before it is an intelligence problem.
The pipeline
Ingestion
The system connects to the agent’s mailbox and picks up new mail continuously. Nothing is moved; mail stays where it is and is read. The scope of what it watches should be the agent’s choice.
Classification
Each message is categorised — inspection report, title commitment, loan status, signature request, scheduling, noise — and its attachments are read, including scanned PDFs that need text recognition. Cheap deterministic rules should run before any model does, because most mail is obvious and a model call per email is waste.
Matching
The hard step: which transaction does this belong to? Good systems score multiple signals — who is on the thread, whether the thread is already attached to a deal, an address in the body, and what the agent has corrected before — and fall back to asking when two deals score too closely.
Extraction
Pulling structured facts out of unstructured text: a deadline, a party’s details, an amount, a status change. This is where a model earns its place, and also where it is most likely to be confidently wrong.
Action
Filing the document, updating a checklist, creating a reminder — or, for anything consequential, building a proposal for a person to approve.
Learning
Corrections feed back: the sender who was filed to the wrong deal, the attachment that was the wrong document type. A system that does not capture corrections makes the same mistake forever.
Why matching is the hard part
It is where the failures that destroy trust live. An agent with eight live deals has the same lender on three of them, the same title company on five, and a thread that says only “the report is attached”. Get the match wrong and you have put a buyer’s inspection report on somebody else’s transaction — which is worse than doing nothing.
The design answer is that matching should be deterministic and scored rather than a model’s judgment, and that ambiguity must produce a question, not a guess. If two transactions score within a small margin of each other, a careful system stops and asks. That is the single most important thing to test before trusting one of these products.
What should never be automated
Not because the model cannot do it, but because the cost of being wrong is not symmetrical.
Must stay a human decision
Approval required
- Changing a contract deadline — a legally operative date
- Any message that leaves the building
- Generating a document and sending it for signature
- Creating an account for a client
- Declaring a transaction complete
Safe to automate
Reversible and internal
- Filing an email and its attachments to a transaction
- Moving a checklist item to a status you asked for
- Recording notes, parties and milestones
- Setting up a module’s default checklist
- Anything logged with its previous value, so it can be undone
This is how Orbit is built, and the line is in the code rather than in a settings page: date changes and sensitive outbound mail cannot be switched to automatic at any automation level.
How to evaluate one of these products
- Ask what happens when it cannot tell which deal an email belongs to. "It asks" is the right answer.
- Ask whether it can change a contract date on its own. "No" is the right answer.
- Ask where outbound mail is sent from — your own mailbox means replies come back to you.
- Ask to see the audit trail, and whether an action can be undone.
- Ask what happens to your correction. If nothing, you will be making it forever.
- Ask which mailboxes it supports before anything else.
What it does not solve
It does not decide whether to object to an inspection, tell your client what to accept, or repair a relationship with a listing agent. It removes the reading, sorting, filing and reminding. That is a large share of the hours and none of the judgment — which is the right division, and the one to hold a vendor to.
Questions
For filing, sorting and surfacing, yes — and those are most of the hours. For anything legally operative it should be proposing rather than acting, which means its reliability is bounded by your review rather than by the model.
It needs to read the mail related to your transactions, and a well-designed system lets you scope that. Ask specifically what scope is requested and what is stored.
It should not, and in Orbit it cannot — outbound mail is always a proposal you approve, and sensitive categories can never be set to automatic.
A chatbot answers questions about data you have already entered. A coordinator reads the inbox and updates the data. The test is whether it finds out about things on its own.