AI Agents in Investment: Where Verifiable Ends
An AI agent belongs in an investment process only when the task has a checkable answer and a human fallback. Two tests, four scenes, three refusals.
Two questions decide whether an AI agent belongs in a step of the investment process: does this step have a checkable right answer, and if the output is wrong, can a human take over without breaking the workflow. Steps that pass both can be quantified, so you can tell later whether the investment paid. Steps that fail both produce impressive demos and no evidence. Catalpa’s four published AI scenarios — financial statement recognition, indicator-based risk judgement, desktop behaviour monitoring, and project effort capture — all sit inside those two tests. It is also why we embed agents into existing workflow nodes instead of shipping a chat box.
Only steps with a right answer qualify
A right answer means an objective result a person can confirm, at a cost lower than producing it. Statement recognition qualifies: the figure on the source document is a fact. Risk indicator judgement qualifies: threshold versus evidence can be compared. Behaviour and effort capture qualify: the event already happened. “Should we invest in this company” does not: the investment committee owns that conclusion, feedback arrives in years, and no causal link exists between a model output and the eventual result.
| Process step | Checkable answer? | Cost of an error | Verdict |
|---|---|---|---|
| Field extraction and metric calculation | Yes, against source documents | One wrong field, recompute | Suitable; keep the evidence chain |
| Risk trigger judgement | Yes, threshold versus facts | Miss or false alarm, human-reviewable | Suitable as first-pass triage |
| Sensitive operation and document monitoring | Yes, events objectively occur | Missing record weakens compliance proof | Suitable; storage and permissions matter most |
| Investment recommendation and deal ranking | No, humans own the outcome | Judgement dressed as conclusion, accountability blurred | Not suitable; summarise material only |
| Auto-drafted external disclosure text | Partly, but definitions require sign-off | Text enters the process first, definitions reverse-engineered later | Not fully automatic; first drafts only |
Every output carries evidence and confidence
An unverifiable model output is, inside an investment system, equivalent to a hand-keyed number of unknown origin. We impose three hard constraints: each recognised or judged result keeps a pointer to its source (page, region, link); it keeps a confidence value that decides whether human confirmation is required; and it keeps the model and rule versions so the decision can be recomputed later. These are not explainability rhetoric. They answer one audit question: where did this figure come from, and why did nobody look at it at the time.
Clients, not vendors, set the confidence thresholds. The same score deserves different treatment in direct-deal finance collection than in sub-fund monthly reporting. Shipping a default threshold disguises an engineering convenience as a business rule. The surrounding controls — encryption chain, access records, field-level permissions — are described under security and compliance.
Shut-down capability is an acceptance test
One test tells you whether the design is sound: switch an agent off for a week and see whether the process still completes. If it does, the agent sits at the right node and compresses evidence-gathering and calculation time. If it does not, the agent has replaced the process itself, and the system now has a structural dependency on a model: any vendor change or model upgrade becomes a business outage.
This is also why we do not deliver AI as a conversation window. A conversation’s output has no storage structure, so it cannot bind to fields, owners and approval steps; it ends up in someone’s memory or in a chat history. Only structured, stored fields can be accepted, measured and audited. Scenario boundaries are set out in AI agents and intelligent risk, and the engineering detail of the most common case is in financial statement recognition: the hard part is account mapping.
A working list for the review meeting
Take these nine items into the AI scenario review:
- For each scenario, name the right answer, who confirms it, and how long confirmation takes.
- Establish the manual baseline: hours per period without a model. That is the only control group.
- Ask the vendor how misjudgements are handled. Do not accept “the model keeps improving”.
- Confirm the storage shape: fields, tables, and the business object each row binds to.
- Confirm that your own staff set and adjust confidence bands, per data domain.
- Confirm the shut-down test: any agent can be disabled without breaking the flow.
- Clarify data boundaries: whether client data trains models, whether inference leaves the intranet, whether source files are retained.
- Require model and rule version numbers, so a past decision can be recomputed as it was made.
- Order scenarios as “collect evidence first, judge second”. Do only the first half in year one.
Three uses we decline
First, replacing investment judgement or auto-scoring deals. It transfers accountability from a committee to a model that cannot be held responsible, and it teaches the team to optimise the score rather than the facts. Second, auto-generating external disclosure. LP letters and supervisory returns carry definitional choices in their wording; generating text before definitions are signed lets the model decide how the organisation describes itself, and the definitions then get reverse-engineered to fit. Third, “intelligent matching” of same-named fields across institutions without a signed definition table. It appears to resolve three-tier divergence while hiding it inside a similarity score; when an auditor asks why two entities count as one metric, nobody can answer. The correct order is: sign the definition table, store the mapping, and let the model flag exceptions only (definition work sits in data governance and metrics).
The boundary for AI in investment management is not set by model capability. It is set by verifiability. Any step where you can prove correctness through evidence, threshold and named owner can go live now. Any step where the honest answer is “the demo looked good” should wait until it has accumulated a reviewable history.