# The thirty-day proof: how an investment firm should test agentic AI.

Most AI proofs of concept stall somewhere between the demo and production. This is the week-by-week plan behind Genba's Experience Seat: what gets fixed before the build, what the trial has to demonstrate under hostile inputs, and how the month closes.

Published: 2026-08-08

## In brief

- Scope the proof to **one high-friction workflow**, with the acceptor, rubric, and exit criteria agreed before any build.
- The trial runs on a **fully synthesised family-office estate**, so the complete loop, writes and approvals included, lands nowhere real.
- The seat ships with **no pre-built Capabilities**: the Principal directs Tōryō and authors the firm's first one.
- The decision rests on **repeatable proof runs against the agreed rubric**, and the export is the firm's whichever way it goes.

## The premise :: Most pilots stall. A proof should be built to decide.

Around 80% of AI projects never reach production or operations, by the Australian government's own count. IOSCO's review of AI in capital markets found the same shape inside this industry: fewer than half of the firms with live use cases had reached production. The common failure is not model quality. It is that the pilot was never designed to produce a decision: no agreed criteria, no defined end, no owner of the outcome.

Genba's Experience Seat takes the opposite structure. Thirty days, one accountable Principal, one workflow that matters, success criteria fixed before anything is built, and a scheduled go / no-go at the end. The rest of this article is that plan.

## Days 1–5 · Scope :: One workflow, criteria first.

Do not trial a generic assistant. Pick one high-friction workflow whose value the firm can already state in hours. Synthesising earnings transcripts against the firm's investment-thesis parameters into a memo draft is a representative choice: unstructured inputs, judgment in the middle, a document the Principal must stand behind at the end.

### The workflow

One bounded objective with real shape: inputs, judgment, a deliverable someone signs. If it can be finished in a prompt, it proves nothing; if it needs six systems, it proves nothing yet.

### The acceptor

A named person with the authority to accept or reject the outcome. Not a committee. The acceptor agrees the rubric before the build and judges the proof runs at the end.

### The rubric

What a passing output looks like, written down: the data points that must be extracted without error, the time the workflow should take, and the rule that every generated claim traces to a verifiable source.

### The exit rule

Thresholds on quality, speed, and cost that end the proof early, so a failing trial stops cleanly instead of drifting. An ended proof is a result. An undecidable one is the real failure.

## Days 6–10 · The estate :: A synthesised family office, provisioned end-to-end.

The Experience runs in a dedicated, client-named single tenant containing a fully synthesised multi-family-office estate: document management with firm-style templates and historical reports, portfolio and holdings, relationships, correspondence, calendars. It behaves like a working firm because the proof needs one — and none of it is real.

This is why the security conversation is short. There is no read-only scope to negotiate, because the firm's production systems are not connected at all. Writes, approvals, and consequence execute fully inside the synthesised estate, so **zero production writes** is a property of the architecture rather than a policy promise. No AI agent holds a credential at any point. Every action crosses Daimon, the [governed execution boundary](/insights/daimon-execution-boundary/), and returns with a receipt. Where the firm prefers to work with its own material, public or sanitised documents can be introduced under the same governance.

## Days 11–20 · The build :: The Principal authors the firm's first Capability.

The seat ships with no pre-built Capabilities. That is the point of it. The firm's first Capability should be the firm's own, shaped by its templates, its tone, its thresholds, and the Principal should see exactly how such a thing gets made, because that is what they are evaluating.

1. **Direct the objective** — The Principal tells [Tōryō](/insights/toryo-chief-of-staff-architecture/), in plain language, to develop the Capability: "build the quarterly earnings-synthesis workflow against our thesis parameters."
2. **Review the plan** — The plan arrives as a working page: reviewable, editable, approved by the Principal before work begins.
3. **Approve access and action** — As Tōryō stages specialists, action and access requests surface as decision cards in the firm's chat and on the approvals page, one decision closing both. Nothing proceeds unapproved.
4. **Watch the work** — Status arrives as short updates with links into the live project state: tasks, owners, blockers, evidence.
5. **Iterate the drafts** — Output drafts arrive for review, built from the estate's templates and historical examples for structure and tone. The Principal comments, redirects, accepts.
6. **Review what the firm learned** — The finished Capability and the knowledge gathered along the way surface as candidates for the firm's canon, held by [Kyōzō](/insights/kyozo-institutional-canon/) under named review — nothing becomes reusable truth silently.

## Days 21–25 · The proof :: Repeatable runs, hostile inputs, complete evidence.

A demonstration that works once is an anecdote. The Capability runs the agreed rubric repeatably, on deliberately messy inputs too: malformed tables, conflicting transcripts, missing periods. It is judged on how it flags what it cannot resolve, because escalation behaviour is the property a regulated firm actually depends on.

Every run leaves a complete record: what the system was asked, what context it used, what it did, who approved what, and where every claim in the output came from. This is the evidence regulators increasingly expect of AI in investment services. ESMA has been explicit that MiFID II conduct and organisational obligations apply unchanged, and the EU AI Act's human-oversight article requires exactly the oversight, interruption, and automation-bias awareness the decision-card structure enforces.

> The proof produces a decision and the evidence for it. Whichever way it goes, the firm ends the month ahead.

## Days 26–30 · The decision :: Continue on evidence, or stop clean.

The acceptor judges the proof runs against the rubric agreed on day five — the same rubric, unmoved.

**Go.** The firm continues into Genba One: the same operating core and governance, with the synthesised estate replaced by governed, approved connections to the firm's own systems behind identical contracts. The Capability authored in the Experience carries forward. Consequence remains earned per workflow: live-read before write, approved action before any delegation.

**No-go.** The firm exports the output, the Capability, and the complete record in open formats, and the environment is deleted. No residual exposure, no stranded spend, and the evidence file explains the decision to anyone who asks.

## References

1. [Guidance for AI proof of concept to scale](https://www.digital.gov.au/policy/ai/AI-POC-to-scale/overview) — Digital Transformation Agency, Australian Government, on why ~80% of AI projects never reach production
2. [Artificial Intelligence in Capital Markets: Use Cases, Risks, and Challenges](https://www.iosco.org/library/pubdocs/pdf/IOSCOPD788.pdf) — IOSCO CR/01/2025, adoption and production rates across 184 market participants
3. [Architecting a successful generative AI proof of concept](https://docs.aws.amazon.com/prescriptive-guidance/latest/gen-ai-lifecycle-operational-excellence/dev-architecting.html) — AWS Prescriptive Guidance, on success criteria, exit criteria, and synthetic data for PoCs
4. [Define your success criteria](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, on measurable criteria and evaluation before build
5. [Public statement on AI in investment services](https://www.esma.europa.eu/press-news/esma-news/esma-provides-guidance-firms-using-artificial-intelligence-investment-services) — ESMA, on MiFID II obligations applying unchanged to AI
6. [Regulation (EU) 2024/1689, Article 14 — Human oversight](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) — the oversight, interruption, and automation-bias requirements for high-risk AI systems
7. [The governed execution boundary for agentic work](/insights/daimon-execution-boundary/) — Genba Labs Insights
8. [Tōryō: one operating mind across every obligation](/insights/toryo-chief-of-staff-architecture/) — Genba Labs Insights

## Questions and answers

### How should an investment firm run a proof of concept with AI agents?

Scope it to one high-friction workflow with success criteria agreed before anything is built: a named acceptor, a rubric, and explicit exit thresholds. Run it in an environment where the full loop of planning, approvals, drafting and revision can execute with real consequence that lands nowhere real. Genba structures this as a thirty-day Experience Seat: one Principal, a synthesised family-office estate, and a defined go or no-go decision at the end.

### How does the Genba Experience keep a proof of concept safe?

The estate is synthesised. The trial environment is a dedicated, client-named single tenant containing realistic family-office systems and data: documents, holdings, relationships, correspondence, none of it real. The firm's own systems are simply not connected, so zero production writes is a property of the design rather than a promise, and no AI agent ever holds a credential.

### What should the success criteria for an AI proof of concept be?

Three things, fixed before the build: a named human acceptor with the authority to say yes or no; a rubric that states what a passing output looks like, including traceability of every claim to a source; and exit thresholds that end the proof cleanly if quality, speed, or cost miss the bar. The proof then runs repeatably against that rubric rather than as a one-off demonstration.

### What does the firm keep if it decides not to continue?

Everything the proof produced, exported in open formats: the completed output, the Capability that was built to produce it, and the complete record of how the work progressed. The environment is then deleted. A clean stop with evidence is a designed outcome of the Experience, and there is no residual vendor exposure.

### How is this different from a vendor demo or a pilot that drifts?

A demo shows a vendor's prepared Capability. The Experience ships with none. The Principal directs Tōryō to author the firm's first Capability end-to-end: objective, plan, approvals, drafts, revisions. What gets evaluated at day thirty is the firm's own working asset and the evidence trail behind it, against criteria agreed on day one. The proof is built to be decided, in either direction.

### What happens after a successful proof of concept?

The firm continues into Genba One: the same operating core, the same governance, with the synthesised estate replaced by governed, approved connections to the firm's own systems behind identical contracts. The Capability authored during the Experience carries forward, and consequence is still earned per workflow. Nothing becomes autonomous by default.