Capstone: Lending domain brain

In one line. Stand up an entire governed lending domain — a shared field dictionary, a fleet of specialist agents over reusable skills, origination and servicing workflows, governance / compliance / recommendation / reporting woven across all of it, and one analyst chat that can question the whole tower. You’ll build. Incrementally: first a working lending automation — five LN specialist agents over four shared LN Skill rules, a coordinator that fills the schema, a confidence gate, a dashboard — then the full Agentic System around it: three collections, a second workflow, RBAC, immutable audit, a trainable model loop, cost telemetry, an analyst chat, and a shippable Solution. You’ll use. Collections & schema (D1) · Lifecycle & events (D3) · Your first agent (A3) · Skills & skill packs (A6) · Teams & mesh (A11) · LLMs & services (A2) · Security & governance (G1) · AI Builder (A9) · Dashboards & views (E7) · Hubs & solutions (V4)

One workflow is a feature. This is a platform. A System is level 3 of the ladder, and it is a composition, not an invention: the domain model is D1’s collection-times-schema repeated, the workflows are B7’s shape, the analyst chat is B2’s, distribution is B10’s. You assemble far more than you author. Budget an afternoon to walk one stage end to end; a day or two to do everything.

What’s clickable vs what’s a pattern. Honesty matters more here than anywhere. The platform ships a real, configuration-only way to build the spine of a lending domain — collections, the fleet, the workflows, RBAC, the audit trail, dashboards, cost telemetry, the analyst chat. Several governance and compliance facets, though, are today represented as taxonomy/labels and architecture rather than fully clickable engines: model-drift monitoring, confidence calibration, prompt-version governance, data-residency assertions, numeric accuracy SLAs. Each stage below flags which is which — a Represented today callout marks the label-represented parts. A good builder labels the difference rather than overclaiming; that honesty is itself a governance discipline.

The build order is bottom-up, because every layer stands on the one below: agents fill a schema that must exist first; workflows route through collections that must exist first; the analyst chat reads collections that must be populated first.

TIER 4  ANALYST CHAT      one agent, all domain collections attached (Stage 8)
FACETS  GOVERNANCE · COMPLIANCE · RECOMMENDATION · REPORTING  (Stages 6-7, span everything)
TIER 3  WORKFLOWS         origination + servicing/exception    (Stages 4-5)
TIER 2  AGENT FLEET       LN specialists over shared LN Skills (Stages 2-3, 5)
TIER 1  DOMAIN MODEL      three collections, one field dictionary (Stage 1)
                          → Stage 9: package the tower as a Solution

Steps

Stage 1 — The domain model (three collections, one field dictionary)

A lending domain has at least three kinds of thing. Studio ▸ Data Model ▸ Collections → + Collection for each (D1):

Collection	Purpose	Why this kind
Lending Applications	Processing	Each application is a case that gets decided — it moves through a lifecycle.
Loan Documents	Knowledge	Paystubs, W-2s, appraisals, bank statements — the evidence corpus the analyst chat reads. Knowledge = no lifecycle, becomes searchable.
Loan Decisions	Processing	The adjudicated outcome per loan — approve/refer/decline plus reasons. Kept separate so reporting and audit have one clean object to count.

For Lending Applications, enter Collection Name Lending Applications, Description Incoming loan applications for an automated decision, leave the other accordions at defaults, Save.

Flag-gated. The Knowledge category is gated by the knowledgeCollections flag — see B1 for the honest fallback if you don’t have it. And Purpose is immutable after create — pick deliberately.

The shared taxonomy — the load-bearing part. A domain model is only “shared” if the fields are shared. On Lending Applications ▸ Schema → footer Taxonomy:

Taxonomy Name: Loan File — Description: The decision fields for a loan application — Type: DocumentClassification — Entity: Lending Applications (pre-filled). Submit.
Select Loan File, then + Label for each field (Add between, Add and exit on the last). A field’s type comes from a validation rule under View Config — there is no “type” dropdown:

Label Name	Description	Type
`applicant`	`The borrower's full name`	Plain text
`requested_amount`	`Loan amount requested`	View Config → numeric
`income`	`Total monthly qualifying income`	View Config → numeric
`DTI`	`Back-end debt-to-income ratio, as a percent`	View Config → numeric
`credit_band`	`Credit tier, e.g. Prime / Near-prime / Subprime`	Plain text
`risk_flags`	`Any fraud / red-flag findings`	Plain text (one line per flag)
`recommendation`	`Approve / Refer / Decline`	Plain text

Keep DTI and income numeric — clean numeric fields read well on the dashboard and can gate the lifecycle. This Learner is your field dictionary: the single vocabulary every agent fills and every report reads.

Represented today — taxonomy governance. A regulated field dictionary wants versioning, a Reviewer-to-Owner approval workflow, and sensitivity tiers. Real Version Control snapshots exist (Stage 6), but per-field sensitivity tiers and field-level approval are today represented as label/description metadata on the Learner, not a dedicated engine. Build the pattern now: add a sensitivity_tier note to each field’s Description.

Checkpoint. Three collections in the left rail; Lending Applications carries the Loan File dictionary. Tier 1 stands.

Stage 2 — The shared skills (the fleet’s toolkit)

Write each lending capability once, as a reusable Skill, so every specialist pins it instead of you re-pasting a prompt. This is what makes a fleet cheap to build and cheap to fix — change the rule in one place, every agent picks it up on next load.

Clicks. Studio ▸ Agent Builder ▸ Skills → Skills tab → + Skill (A6). For each: on the Form tab set Name and Description (write the description for discovery — the “use when…” half tells an agent to reach for it); on the Markdown tab write the rule body (write that for execution); then Create (note the new V1 chip).

Skill Name	Description	Markdown body — the rule
`LN Skill — Income Calculation`	`Compute monthly qualifying income from pay docs; use when verifying income.`	Base income = annual W-2 wages ÷ 12. Average variable income (bonus/OT/commission) over 24 months. Caution on declining income.
`LN Skill — DTI Affordability`	`Compute back-end DTI; use when assessing affordability.`	Back-end DTI = total monthly debt obligations (incl. proposed PITI) ÷ gross monthly income × 100. List what counts as a debt.
`LN Skill — Credit Analysis`	`Summarise a credit report into a band; use when reading credit.`	Read FICO, tradelines, derogatories. Map to a band: ≥740 Prime · 620–739 Near-prime · <620 Subprime. Note collections/lates.
`LN Skill — Fraud Red Flags`	`Spot loan-fraud indicators; use when screening a file.`	Flag income mismatch across statements, identity inconsistency, collateral risk, document tampering (math that doesn’t foot, font changes).

Tip — name with a prefix. LN Skill — and the LN agent prefix are exactly the convention the real lending fleet used — it groups the fleet’s assets in the searchable list. Pick a prefix and stick to it. Optionally bundle all four into one Skill Pack (LN Lending Pack) on the Skill Packs tab and pin the pack in one click.

Stage 3 — The specialist fleet

Five thin specialists, each owning one stage and pinning only the skill(s) it needs. Small and single-purpose is the whole point — tune and test each on its own, not one mega-prompt.

Clicks. Studio ▸ Agent Builder ▸ Agents → footer + Agent ▸ Agent (A3). For each, set the tabs below, then Save Agent (no autosave):

Agent (Persona ▸ Name)	Instructions (seed via the co-pilot, then refine)	Capabilities ▸ Skills to pin
`LN Income Verifier`	“Compute the borrower’s total monthly qualifying income from their pay documents. Return only the monthly figure and how you derived it.”	`LN Skill — Income Calculation`
`LN Credit Analyst`	“Summarise the credit report and assign a credit band (Prime / Near-prime / Subprime). Note any collections or late payments.”	`LN Skill — Credit Analysis`
`LN Fraud Check`	“Screen the file for fraud indicators and list each red flag found. If none, say ‘No red flags’.”	`LN Skill — Fraud Red Flags`
`LN Affordability`	“Compute the back-end DTI percentage from income and monthly debts including proposed PITI.”	`LN Skill — DTI Affordability`
`LN Decision`	“Given income, DTI, credit band and risk flags, recommend Approve, Refer or Decline with a one-line rationale.”	`LN Skill — DTI Affordability`, `LN Skill — Credit Analysis`

On every agent: Model = your project’s LLM; Agent Mode = Thinking — lending decisions reason across several rules at once, and the whole real fleet runs in Thinking mode. On Capabilities, + Pin skill per the table, and optionally tick “Restrict this agent to pinned skills only” so the specialist stays predictable. Leave Output at chat defaults for now — LN Decision gets structured output in Stage 4.

Flag-gated — the Playground. The richer Agent Harness Playground (the right pane with playground, runs, evaluation tabs) is behind the agentHarness lab flag; enable it from the Lab menu (E1). Without it you still get a working Playground — just the legacy projection.

Golden-prompt test each one. This is exactly how the real fleet is verified: a sharp prompt with a known answer. In the Playground, Input Type = Text, paste, press Enter:

Agent	Golden prompt	A correct answer contains
`LN Income Verifier`	“W-2 box-1 wages $84,500/yr and an averaged monthly bonus of $900. State the total monthly qualifying income.”	`7,941` (or `7,942`)
`LN Credit Analyst`	“Summarise: FICO 712, 6 open tradelines, 1 collection $480, 0 lates in 24 months.”	`712` and `collection`
`LN Fraud Check`	“Paystub YTD gross $26,000 in March but the W-2 for the prior full year shows $84,500. Any income-fraud concern?”	`mismatch` / `inconsistent` / `discrepancy`
`LN Affordability`	“Gross monthly income $9,000. Debts: auto $450, student $250, cards $200, proposed PITI $2,520. Back-end DTI percent?”	`38`
`LN Decision`	“Income $9,000/mo; DTI 38%; credit band Prime (FICO 712); no red flags. Approve, Refer or Decline?”	`approve`

Known gap. Playground Document mode for Thinking-mode agents is a known gap — verify agents with these text prompts; PDFs are for the real collection run. Don’t promise a live document-mode Thinking demo you can’t show.

Checkpoint. Each agent resolves in Thinking mode and its answer contains the golden token. Tier 2 stands: a verified fleet of five over a shared toolkit.

Stage 4 — First workflow: origination end to end

This stage turns the fleet into a working lending automation — the milestone the rest of the system grows around.

a) Ingestion. Studio ▸ Connector ▸ Ingestion (Sources v3 is behind the ingestionV3 lab flag — D4). To test now: Upload → drag in a few application PDFs → Target collection = Lending Applications → Submit. For production: + Connector → Botminds Drive → Test connection → Save connector; then + Job → Job name Applications intake, Browse… to the loan-files folder, Extensions pdf, tick Recursive, Target collection Lending Applications, Recurring → every 6 Hours → Create job.

b) Make LN Decision a coordinator over the fleet. Select LN Decision → Edit → the Subagents tab (A11):

Coordination mode = coordinate — delegate to members, then synthesise one answer.
+ Add subagent four times: LN Income Verifier, LN Credit Analyst, LN Fraud Check, LN Affordability. Give each a one-line Prefix (e.g. on Fraud Check: “List every red flag; if none, say ‘No red flags’.”).
On the Output tab: turn on Structured output, pick the Learner Loan File, confirm each Label carries a Description, set Process unit = Page, turn on Confidence Score and References. Save Agent.

c) Assign it as the collection’s Worker. Studio ▸ Data Model ▸ Collections ▸ Lending Applications → Agents tab → Assign LN Decision. Every loan file that lands now runs the whole fleet: the coordinator delegates to the four specialists, synthesises, and writes the seven schema fields.

d) The gate — auto-clear the easy approvals. Lifecycle tab → the Auto-Decide policy card (D3):

Enabled = true; Applies To = approve — keep human eyes on declines and refers.
Min Confidence = 0.92; Require Zero Flags = true — the AI’s confidence and an empty risk_flags are the code-backed gate the evaluator actually enforces. Save; the preview reads roughly “Auto-approve when AI confidence ≥ 0.92 AND zero flags.”
Click L1 Review → confirm Send to Inbox (human review) is on (IncludeManualIntervention); same for L2 Approval.

Honesty callout — capping on a numeric like DTI. You may also want “only auto-approve DTI ≤ 43.” The card exposes a Max Amount, but the shipped evaluator compares one number — the agent’s self-reported _meta.amount — not an arbitrary schema field by name. A DTI cap only fires if LN Decision surfaces DTI as its _meta.amount; otherwise leave the cap off and gate on confidence plus flags alone. And never Reset to default on a lifecycle with live documents — it is destructive.

e) The review path a human walks. Consumer app ▸ Inbox — each card wraps a loan file (wraps ▸ Lending Applications · doc-… · L1 Review); the Inbox doesn’t act, it points (E5). Open → Document Detail (/<project>/:docId): click a flagged value — say DTI : 46 — and the viewer highlights the source segment it was read from; correct in place (it teaches the model — A9); Rescore if dependents change; advance through L2 Approval → Approved. Every move writes the audit trail — and that trail is the decision; there is no separate decision object.

Checkpoint — the milestone. Upload two files: a clean Prime file (DTI ~38) auto-approves (audit actor AI/auto); a flagged or low-confidence one lands in the Inbox with a recommendation of Refer or Decline. You now have a complete, audited lending workflow. Everything after this widens it into a system.

Stage 5 — From workflow to system: grow the fleet, add servicing

Grow the fleet. The real production fleet runs about 50 lending agents over 18 shared skills, organised into solution areas — origination intelligence, income verification, asset analysis, underwriting, compliance and fair lending, fraud and QC, pricing, servicing, portfolio and communication. You built a five-agent slice; grow it the same way: more LN Skill — rules, more thin LN specialists that pin them — an LN LTV Calculator (loan ÷ appraised value), an LN AUS Findings Interpreter, an LN Adverse Action Letter Writer for declines. Each extractor’s Output tab points at the same Loan File dictionary and fills only its slice — one shared vocabulary, many writers.

Compose Teams. For multi-step jobs, compose agents into Teams (A11): a dedicated LN Underwriting Decision Team leader that only coordinates keeps LN Decision’s prompt focused on writing the recommendation; route mode makes a leader pick one specialist per request — good for triage.

Flag-gated. Nested Deep teams (a team-of-teams) are behind BM_DEEP_NESTED_TEAMS_ENABLED.

Upgrade to a Mesh when you outgrow in-process. When the pipeline grows long, has true parallel checks (credit and fraud at once), or a step needs a slow external service (a bureau pull past 240 seconds), build a Mesh (+ Agent ▸ Mesh — not flag-gated): members are runnables wired by queues, batons hop over a durable bus, and it survives a restart. Fan the file out to credit and fraud in parallel, then fan in to the decision. The full pattern is worked in B7.

Add the second workflow — servicing / exceptions. A System is many workflows, not one. Model a second lifecycle — on Loan Decisions, or a dedicated servicing collection — for loans already on the books: escrow analysis, delinquency triage, loss-mitigation eligibility. Most items pass straight through; only exceptions (a delinquency bucket crossing a threshold, a covenant breach) raise a human review. Same D3 machinery, applied a second time.

Represented today — SLA by stage. Per-stage SLA budgets (P95 latency, STP targets) are described as an SLA Conformance label, not measured by a live SLA engine. You can clickably add an SLA-breach alert on a stage Event (D3) — teach the alert (clickable) and the budget table (represented).

Roles / RBAC (fully clickable). Studio ▸ Security ▸ Access Roles (G1). Build the lending roles — Loan-Processor, Underwriter, Compliance-Officer, Servicing-Agent — and gate each lifecycle stage to the role allowed to act on it. Roles gate Studio buttons and the lifecycle, so “AI recommends, an Underwriter confirms” is enforced, not hoped for.

Versioning (fully clickable). Studio ▸ Project ▸ Version Control — snapshot and freeze the whole configuration so a change can’t silently drift, and you can roll back. This is the real backbone under several governance facets.

Validation (fully clickable). The same View Config rules that give a Loan File field its type also enforce it — an amount is numeric, income on the paystub reconciles with the W-2 — plus agent-side guard rails (A8).

OFAC / fraud. The fraud and QC agents run as part of intake, and their results land as fields the gate reads (risk_flags, an OFAC Screen label). The agents and the gate are clickable; an external OFAC reference-data service is represented as a Reference Data Service label rather than a live integration — the LLM does not know the watchlist, the policy just refuses to auto-approve past a flag.

Immutable audit (fully clickable — this is real). Studio ▸ Security ▸ Audit — every access, create, update, delete, download, and every stage move is recorded immutably. The stage-move history is the compliance record; the mesh run ledger gives a per-segment durable trace on top.

Represented today. Model-agnosticism is half and half: the agent’s Model tab is a real single swap point and Studio ▸ AI & Services lists the swappable models (A2) — do the swap. But assertions like canonical-API-boundary access and data-sovereignty isolation are represented as labels plus architecture, not a clickable enforcement engine. Prompt-version governance is partially live — a versioned-prompt object exists with rough edges — so treat retention/IP assertions as labels plus the vendor-contract layer, not a finished UI.

Checkpoint. Lending roles gate the stages; a frozen snapshot exists; the LLM swap point is exercised; the Audit page shows the immutable trail; clean loans go straight through while exceptions hit a reviewer.

Recommendation (clickable). The underwriting team already produces approve/refer/decline plus reasons. Wire its output into Loan Decisions so every loan ends with a structured recommendation and reasons — one clean object for reporting and audit to count.

The trainable loop (clickable, honest depth). Studio ▸ AI Builder (A9) — the platform’s own trainable extractor, owned by a Learner, improves every time a reviewer corrects a field on Document Detail: correct → train → re-predict. That is how a recommendation engine stops being a static prompt and starts being an apprentice. What is not clickable today is asking a Thinking agent to re-read the PDF and self-correct — that path hits the Stage-3 document-mode gap. Reviewers improve the model by correcting labels (real), not by re-running an agent over the document.

Represented today. The production-grade quality controls around that loop — an active-learning dashboard, confidence calibration (“95% confidence means ~95% correct”), drift monitoring with retrain thresholds — are represented as Active Learning / Calibration / Drift Monitoring labels, not finished dashboards. The training loop is clickable; the MLOps governance around it is taxonomy.

Dashboards (fully clickable). Studio ▸ Intelligence (E7). Build three, one per persona:

Dashboard	Tiles	Persona
Pipeline Ops	counts by stage, approval rate (Approved ÷ decided), average `DTI` (numeric metric), risk distribution by `credit_band`, what’s waiting on a human	Processor / Team Lead
Model Health	extraction accuracy trend, hallucination-vs-low-confidence split, field confidence summary	QC
Cost	cost per loan / document / stage / field, spike alerts	Owner

Cost telemetry is genuine instrumentation — cost-aware inference is live, not a label. Not sure which template fits a tile? Use the Agentic Widget — describe it in plain language (“average DTI of approved loans this month”) and let AI build it. Add role-scoped Views like Loans Awaiting Underwriter or Exceptions Older Than 5 Days — the lists your teams actually work from.

Represented today. Numeric accuracy SLAs (98.5% classification, 99.9% on sensitive fields) are SLA Conformance labels, not measured — you can’t truthfully show a 98.5% figure from a single demo loan. Teach the instrumentation; never a fabricated accuracy number.

Stage 8 — The analyst chat over the whole domain

One chat that answers questions across applications, documents, and decisions — B2 applied at system scale. Build a chat agent (A3) and, on its Knowledge tab, attach all three collections: Loan Documents (the evidence corpus, retrieval) plus the structured Lending Applications and Loan Decisions (counting and filtering via a Datasheet — D5). That multi-collection attachment is the load-bearing wire: it scopes the agent to exactly the domain and nothing else.

Now an analyst can ask, in App ▸ Chat:

“What’s our approval rate this quarter, and the top three decline reasons?” (structured, over Decisions)
“Show me the income evidence for loan #4821.” (retrieval, over Documents, with citations)
“How many loans are stuck waiting on an underwriter?” (structured, over Applications)

Watch out — scope is the guardrail. Attach only the collections this analyst audience is allowed to see; the Knowledge-tab attachment is the access boundary, and the Chat audit records every question. A System’s analyst chat is as governed as everything beneath it.

Stage 9 — Package the system as a Solution

What you built once should run for the next team or tenant without a rebuild. Studio ▸ Project ▸ Publish / Studio ▸ Hubs (V4; full walk-through in B10). Publish the whole project as a Solution to the Solution Hub. The one load-bearing rule: structure travels, data doesn’t — the package carries the shape (collections, the field dictionary, the fleet, lifecycles, roles, dashboards, guard rails) and deliberately leaves behind your documents, vector index, model credentials, and tenant ids. Those are re-created empty, required to pre-exist, or rebound at install time — the EMBED/DECLARE/REBIND model from Core concepts (S2).

Checkpoint. The lending domain appears in the Solutions catalog. Install it into a fresh project and confirm the structure lands while the data does not.

Stage 10 — Test the tower

Run the whole thing once, top to bottom — the capstone proof:

Drop a loan file in. Studio ▸ Connector ▸ Ingestion ▸ Upload → a borrower’s documents → Target collection = Lending Applications (route evidence to Loan Documents). The Processing… chip climbs as the fleet fills the Loan File dictionary.
Spot-run a specialist. Re-send any Stage-3 golden prompt in its Playground and confirm the fleet still answers with the golden token.
Watch origination route it. The clean, confident loan goes straight through (audit actor AI/auto); the low-confidence or flagged one lands in the right reviewer’s Inbox under Needs Review.
Review one as a human. Inbox item → Document Detail → verify a flagged field against its highlighted source, correct a value (that correction feeds the Stage-7 training loop), approve through L2 Approval → Approved; the Inbox item self-resolves.
Confirm the decision and the audit. The loan lands a recommendation plus reasons in Loan Decisions; the Audit page shows the full immutable trail — who did what, when, at what confidence.
Ask the analyst chat. One structured question (“approval rate this week”) and one retrieval question (“show the appraisal for that loan”) — cited, scoped answers across collections.
Read the three persona views. Pipeline Ops (throughput and the gate at work), Audit (compliance), a coverage View (governance) — three personas, one system.

All seven and you stood up a governed lending domain platform — collections, fleet, workflows, facets — entirely by configuration.

Make it production-worthy

Tune the gate to your risk appetite. Raise Min Confidence to 0.97 so more files get human eyes; set Applies To = both only once you trust the fleet on declines too.
Keep specialists honest. Golden-prompt every new LN agent before it joins a team, and restrict each to its pinned skills.
Label the represented facets. Fully clickable today: RBAC, versioning, validation, immutable audit, cost telemetry, dashboards, the analyst chat, distribution. Represented as taxonomy: sensitivity tiers, drift/calibration, prompt-version governance, residency, numeric accuracy SLAs. A real System mixes both; keep the labels that state which is which.

Where to go next

Ship it to the next team: B10 · Package & ship a solution.
The pattern behind this build: The System pattern.
The analyst-chat layer in depth: B2 · Enterprise data Q&A.