The case workspace

The case workspace composes nine independent reads into one screen: the case, the borrower record from the lending core, tasks, interactions, notes, documents, automated case effects, arrangements, and anything parked for an approver. Each renders its own loading state from its own query, so a slow lending core does not block the rest of the case.

The case brief

The brief derives a single next-step sentence and an accompanying action. It is evaluated in a fixed precedence, with unclaimed work ranked above work already held:

Alongside it the brief shows at most three financial figures, and only for case types where the arrears are the subject of the case — collections, hardship, disaster, bankruptcy, deceased borrower, legal action, debt validation and debt disputes. An address-change case on a delinquent borrower shows no past-due figure.

Protection state

Protection is reported as two facts rather than one, because the hold on the lending record and the suppression of outreach are applied separately and can diverge:

The dock

A 400-pixel column runs the full height of the screen and holds two panes: the borrower snapshot and the case copilot. Both remain mounted, so switching panes does not discard an in-progress question. The selected pane is remembered per agent in browser storage — the selection only, never any conversation content.

The dock is gated on the permission to request the copilot. An agent without it sees the snapshot and no pane switch.

Three details in the snapshot are careful:

Tabs

Overview, Activity, Interactions, Work, Documents, Notes and Payments, each with a live count. The payments count is narrow by design: active arrangements plus money action requests in open states only, rather than every money record the case has touched.

The open tab and the focused record are both held in the query string, so any card on any case is directly linkable.

Activity merges seven sources into one chronological index with search and per-category filters — case, interaction, work, money, document, note, system — grouped by day. Entries link to the tab that owns the full record rather than reproducing its content. Actors are read from the worker registry, so an AI agent’s call is attributed to that agent rather than to the case owner.

The workflow journey

The case renders the workflow it is running stage by stage, in the workflow definition’s own wording, with each stage marked complete, current, skipped or upcoming.

A skipped stage carries a reason code and reason text from the definition. The interface does not compose that sentence itself.

Reaching a terminal outcome is rendered separately from completing every stage, because a case that cured and a case referred elsewhere can both have every stage accounted for.

The case roster

One list holds everyone who has worked the case: people, AI agents, the workflow itself, and the queues where its work is sitting unclaimed. Registry names are split into a name and a role, so an AI worker reads as a named agent with the work it owns, rather than as a code.

Case actions

Available actions come from the server’s list of transitions this case can currently make; the client-side map is a fallback only, and the server’s list wins wherever the two disagree. The set is: set waiting, snooze, return to open, escalate, resolve, close, reopen, and export evidence.

Escalation is structured rather than a flag with free text. It takes a target type — supervisor, compliance reviewer, queue or named person — chosen from a live list of eligible targets; an urgency of normal, urgent or immediate; a response deadline validated as future-dated; and, for compliance review, a reason code of potential consumer harm, control failure, or complaint or regulatory inquiry.

Export evidence returns the case’s complete record as a file under its own permission.