Academy · Solutions · Agentic System
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
LNspecialist agents over four sharedLN Skillrules, a coordinator that fills the fields, a confidence gate, a reporting page — then the full Agentic System around it: three collections, a second workflow, personas, the audit trail, a trainable model loop, cost telemetry, an analyst chat, and a shippable Solution. You’ll use. Collections & schema (D1) · Taxonomy, lifecycle, tags & events (D3) · Your first agent (A3) · Skills & skill packs (A6) · Teams & mesh (A11) · LLMs & services (A2) · Access & roles (G1) · AI Builder (A9) · Pages & cards (E6) · Hubs & distribution (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-fields 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.
A regulated lending programme has two kinds of requirement: the ones you configure here — collections, the fleet, the workflows, personas, the audit trail, pages, cost telemetry, the analyst chat — and the ones you record as convention in your own field descriptions and enforce in process, such as per-field sensitivity tiers or an accuracy target. This build says plainly which is which as each comes up, and never claims a number the platform doesn’t measure.
The build order is bottom-up, because every layer stands on the one below: agents fill fields 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 over the evidence + the reporting table (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 > 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.
Purpose is permanent. You choose Processing vs Knowledge once, at create time — pick deliberately. If the Knowledge choice isn’t offered in your project, ask your administrator; B1 has the honest fallback in the meantime.
The shared taxonomy — the load-bearing part. A domain model is only “shared” if the fields are shared. On Lending Applications ▸ Taxonomy → Taxonomy at the bottom of the list:
- 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 a reporting page and can gate the lifecycle. This Learner is your field dictionary: the single vocabulary every agent fills and every report reads.
A regulated field dictionary also wants sensitivity tiers. You record that as a note in each field’s Description — the platform stores and shows it, it does not enforce it. Changes to the dictionary itself are covered by snapshots and freeze in Stage 6.
Checkpoint. Three collections in the collection list; Lending Applications carries the
Loan Filedictionary. 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 > Agents > Agent Toolkit > 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. A
LN Skill —andLNprefix 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 > Agents > Agent Toolkit > Agents → + Agent ▸ Agent at the bottom of the list (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 language model; Agent Mode = Thinking — lending decisions reason across several rules at once. 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.
Golden-prompt test each one. A sharp prompt with a known answer is the cheapest verification there is. 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 — document mode in the playground. Feeding a PDF to a Thinking-mode agent in the playground doesn’t work reliably today. Verify your agents with the text prompts above; 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 > Data > Ingestion (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 > 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 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_flagsare the gate the platform 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; same for L2 Approval.
Watch out — the cap is one number, not a rule set. You may also want “only auto-approve DTI ≤ 43.” Set a Max Amount and the card asks for the Amount Field it reads that number from, so you can cap on
requested_amount. What it cannot do is stack conditions — it is one ceiling on one field, alongside confidence and zero flags. For anything richer (“Prime only, and DTI ≤ 43”), leave the cap off, gate on confidence plus flags, and let the reviewer take the ratio calls. And never Reset to default on a lifecycle with live documents — it rebuilds the standard flow and asks you to confirm by typing the collection’s identifier.
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: 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 — its audit entry records an automatic accept rather than a person; a flagged or low-confidence one lands in the Inbox with a
recommendationof 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. 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. Group them into solution areas as the fleet grows — origination intelligence, income verification, asset analysis, underwriting, compliance and fair lending, fraud and QC, pricing, servicing, portfolio and communication. 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. If you want a team whose members are themselves teams and don’t see the option, ask your administrator.
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 waits on a slow external service such as a bureau pull, build a Mesh (+ Agent ▸ Mesh): its members are wired by queues, work hops over a durable bus, and a Service member parks while the external worker runs and reports back — so 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.
On stage timings: you can add an SLA-breach alert to a stage Event (D3) and be told when something sits too long. A full per-stage latency budget is a table you keep yourself — record the target in the stage description and let the alert do the watching.
Stage 6 — Governance and compliance facets
Personas. Studio > Governance > Access > Users & Access → the Personas view (G1). Use + Add persona to build the lending roles — Loan-Processor, Underwriter, Compliance-Officer, Servicing-Agent — choosing the collections and stages each one works in. Then, on each lifecycle stage, set Can be viewed by to the persona allowed to act on it. That is what makes “AI recommends, an Underwriter confirms” enforced rather than hoped for. Add people to a persona from the People view; someone who should only ever read gets the Viewer workspace role.
Versioning. Studio > Governance > Versioning holds three entries: History (what changed, when, and by whom), Snapshots (take one, restore from one) and Freeze (lock the configuration so it cannot be changed, and lift it again). Snapshot before every significant change; freeze during an audit or a release window.
Validation. 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).
Screening and 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 yours to configure. There is no live watchlist feed behind them: the model does not know the watchlist, so record the screening result as a field and let the policy refuse to auto-approve past a flag.
The audit trail. Studio > Governance > Oversight > Audit & Usage. It opens on Audit — every access, create, update, delete, download and every stage move, with who did it and when; the switch under the title shows Usage, the consumption and activity side. The stage-move history is your compliance record, and a mesh run adds a per-segment trace on top.
Swapping the model. The agent’s Model tab is a real single swap point, and Studio > Agents > Agent Toolkit > Language Models lists the models registered for this project and lets you set the default (A2) — do the swap once so you know it works. Where the data physically lives and who your model provider is are contract questions, not settings on this page.
Checkpoint. Personas gate the stages; a snapshot exists and freeze is available; the model swap point is exercised; Audit & Usage shows the trail; clean loans go straight through while exceptions hit a reviewer.
Stage 7 — Recommendation and reporting facets
Recommendation. 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. Studio > Agents > Classic ML > AI Models (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, and read the result on Studio > Agents > Classic ML > Prediction Report. That is how a recommendation engine stops being a static prompt and starts being an apprentice. What you cannot do today is ask a Thinking agent to re-read the PDF and self-correct — that hits the Stage-3 document-mode gap. Reviewers improve the model by correcting labels, not by re-running an agent over the document.
Calibration and drift are yours to watch. The correction loop is real; a standing dashboard that tells you “95% confidence means ~95% correct” is not something the platform computes for you, so treat confidence as a routing signal and re-measure accuracy with the Prediction Report when you retrain.
Reporting pages. Studio > Experience > Designer > Pages (E6). Build three, one per audience, from cards in the card library at Studio > Experience > Designer > Cards:
| Page | Cards | Audience |
|---|---|---|
| Pipeline Ops | counts by stage, approval rate (Approved ÷ decided), average DTI, 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 — the platform measures it. Accuracy targets are not: don’t put a 98.5% figure on a page unless you measured it with a Prediction Report over a real reference set. Add role-scoped Views at Studio > Data > Views — Loans Awaiting Underwriter, Exceptions Older Than 5 Days — the lists your teams actually work from, and place them on the pages as table cards.
Stage 8 — The analyst chat over the whole domain
One chat that answers questions across the domain — B2 applied at system scale. Build a chat agent (A3) and wire the domain onto its Knowledge tab: attach Loan Documents under Knowledge collections (the evidence corpus it retrieves and cites), and under Datasheet attach one table materialised from a View over Loan Decisions — the clean object Stage 7 gave reporting to count (D5). The Datasheet slot takes one table, so pick the slice this audience actually counts; a second slice means a second agent. What you attach here is the load-bearing wire: it scopes the agent to exactly this 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 the decisions table)
- “Show me the income evidence for loan #4821.” (retrieval, over
Loan Documents, with citations) - “How many files did we refer rather than decline last month?” (structured, over the decisions table)
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. Go to Studio > Hubs > Solutions — the Hubs chip sits on the right of the top bar while you are in Studio (V4; full walk-through in B10). Publish the whole project as a Solution. The one load-bearing rule: structure travels, data doesn’t — the package carries the shape (collections, the field dictionary, the fleet, lifecycles, personas, pages, guard rails) and deliberately leaves behind your documents, your search index, your model credentials and anything else tied to this workspace. At publish time everything sorts into three buckets: pure configuration travels inside the package; anything belonging to the environment — a language model, a server — must already exist where you install; and anything that points at data is wired to the installing project’s own objects.
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 > Data > Ingestion→ Upload → a borrower’s documents → Target collection = Lending Applications (route evidence to Loan Documents). The Processing… chip climbs as the fleet fills theLoan Filedictionary. - 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 — an automatic accept in the trail, not a person; 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; Audit & Usage shows the full 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 audience pages. Pipeline Ops (throughput and the gate at work), Model Health (how the extraction is holding up), Cost (what the pipeline costs to run) — three audiences, 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.97so 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
LNagent before it joins a team, and restrict each to its pinned skills. - Snapshot before you change the dictionary. The
Loan Filefields are the vocabulary everything else reads. Take a snapshot first, and freeze during audit windows. - Never publish a number you didn’t measure. Cost telemetry is measured. Accuracy is measured only when you run a Prediction Report over a reference set. Sensitivity tiers and residency are conventions you record and enforce in process — say so rather than implying the platform checks them.
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.
Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.
See the platform live