Due diligence and vendor checks that end in a human sign-off

Due diligence suits agents well and suits full automation badly. The work is repetitive, document-heavy and shaped like a checklist, which is exactly where an agent saves time. But the output is a judgment someone will lean on when they sign a contract, onboard a supplier or make an offer, and that judgment has to stay with a person. This guide shows how to build a pipeline that does the gathering automatically and leaves the decision, together with its evidence, in front of a human.

Decide what the pipeline is for

“Due diligence” covers very different jobs. A vendor check before onboarding a software supplier, a counterparty review before a distribution agreement and pre-acquisition diligence on a target share a shape but not a depth. Before building anything, write down three things: the decision the diligence supports, the level of assurance that decision needs, and who is accountable for it.

A procurement team approving a low-risk SaaS tool needs a short check with clear escalation rules. An acquisition team needs depth, a data room and specialist reviewers. The pipeline design follows from that answer, not the other way round. In both cases agents are good at collecting documents and public records, extracting values from them, comparing what different sources say and flagging inconsistencies. They should not be the ones deciding that a risk is acceptable.

Turn the checklist into answerable items

Most organizations already own a diligence checklist, usually written for humans: “review corporate structure”, “check litigation history”. An agent needs each item rewritten as a question with a defined answer, named sources and a stated trigger for escalation. One row per item keeps it manageable.

The table doubles as acceptance criteria for the whole run. Diligence is done when every row has an outcome, not when the agent has produced a persuasive memo.

Each item gets an outcome and its evidence

Give every checklist item one outcome from a small fixed set, and require evidence for each. A practical set is confirmed (sources support a clean answer), flagged (the red-flag condition is met, or one source contradicts another), not found (the sources were checked and did not answer) and not applicable (with a reason). The record for one item might read:

item       Legal identity
outcome    flagged
evidence   registry extract, registration no. 0000000:
           'Status: active. Registered name: Example Systems Ltd.'
           master services agreement, page 1:
           'between ... and Example Systems Limited Partnership'
note       contract names a different legal form than the registry;
           confirm which entity will sign
source     registry extract imported with its reference and date

Two rules matter more than the format. First, not found is not clear. A litigation search that returned nothing in one court database shows only that; a report that turns it into “no litigation” is making a claim nobody checked. Second, a value the agent could not support stays empty. A guessed incorporation date is worse than a blank, because it looks finished. Missing evidence is an open question makes the case in detail.

Sources: whose word counts for what

Diligence evidence comes from three places, and each deserves a different weight. Official records such as registries, court systems and list publications are authoritative for what they cover, but often incomplete or awkward to query. Material the counterparty supplies, such as contracts, financial statements and questionnaire answers, is essential but self-reported. Third-party sources such as news, databases and reviews fill gaps and raise questions, but rarely settle them.

Write the acceptable sources into each item instead of letting the agent decide what is reliable. Much of the evidence in a vendor check is also material you already hold: the vendor's own answers and documents. Running extraction over that, with each value tied to the passage it came from, is often worth more than any web search. Deciding which sources may answer a question and bringing the evidence you already have cover both halves.

Red flags: defined in advance, cleared by people

An agent is good at noticing that two documents disagree. It is the wrong party to decide that the disagreement is harmless. Define red-flag triggers before the run, as in the table above, and route every triggered flag to a person with the evidence attached.

Two kinds of flag need particular care. Name matches against sanctions lists or adverse media are often false positives: common names, transliterations and similarly named companies all produce hits. The pipeline's job is to present each match with identifying details from both sides, such as date of birth, registration number and address, so a reviewer can clear or confirm it quickly. Dismissing it is not the pipeline's job. Inconsistencies between documents, for example a revenue figure in a pitch deck that differs from filed accounts, should be quoted side by side rather than averaged or explained away.

Running the pipeline in GoCux

In GoCux, each counterparty review fits on one work order: the goal (a diligence file for this vendor), the scope it may touch (the supplied documents and the permitted sources) and the checklist as acceptance criteria. Extraction pulls values out of the material you supply and keeps the supporting passage beside each one; a value that is not in the material stays unknown. Where public records are needed, a research plan sets out the steps and a source allowlist, and it runs only after approval. Web material arrives through an authorized browsing or export step and keeps a reference to the page and the time it was retrieved.

Consequential steps pause for a person. Sending a document request to the vendor waits for approval, and exporting the finished file pauses with the files in scope listed. Every step, source and decision builds up on the work order's record, and a rejected step is recorded as well. After onboarding, a Pulse definition can ask a narrow question again on a cadence you approve, for instance whether the vendor's registry status has changed. Each detected change is reviewed individually and takes no action for you. See Extraction, Task and Pulse for the details.

A sign-off that means something

The last step is a person reviewing the file and recording a decision: approve, approve with conditions, or decline. For that decision to carry weight, three things should hold. The reviewer sees every flagged and not-found item, not only a summary. The decision is attributed and stored together with the evidence it relied on. And the signer has the authority to accept the risk; for higher-risk categories that may be someone other than the person who requested the vendor. Who may approve agent work discusses how to arrange that.

What to verify before you rely on it

• Every checklist item is a question with named sources and a written red-flag condition.
• Each item ends as confirmed, flagged, not found or not applicable, with evidence or a reason.
• “Not found” is never reported as “clear”.
• Values without a supporting passage stay blank.
• Potential name matches show identifying details from both sides.
• Contradictions between sources are quoted side by side.
• Requests sent to the counterparty and exports of the file wait for approval.
• The signer sees the complete file and holds authority for that level of risk.
• A rerun on the same inputs gives the same outcomes, or the differences are explained.