Equipoise · anatomy · The Agentic Bank

The one agent allowed to see the monitoring data, and only for outcome testing: it catches a disparate-treatment pair the underwriter cannot.

Second line. Independently reviews the underwriting decision for fair-lending risk; a violation holds the commit at the Keystone gate.

Methodology

1 Is the decision supported? Test it against the policy and the file. A within-policy file declined with no hard basis is itself a fair-lending red flag.
2 Outcome testing: pull the similarly-situated comparators and compare credit profile AND outcome. A materially-equivalent applicant who got a more favourable outcome, differing on a prohibited basis, is potential disparate treatment.
3 Proxy check: scan the decision's stated factors for any prohibited-basis proxy (a name, a neighbourhood).
4 Verdict clear / concern / violation. Use the basis only as a lens on fairness, never as an input to credit merit.

Sandboxed tools

In-process MCP tools only. Built-in tools disabled, settingSources [], permissionMode bypassPermissions. The only ground truth is the tools.

get_application read

The credit-relevant fields.

get_credit_report read

The bureau credit file.

get_policy read

The credit policy, to test whether the decision is supported.

get_monitoring read

The applicant's prohibited-basis attributes — for outcome testing ONLY, never credit merit.

find_similar read

Similarly-situated applicants with a prior decision and their basis attributes.

record_review commit

Commits the fair-lending review. Called exactly once.

Outcome contract

A fair-lending verdict (clear / concern / violation), whether the decision is supported, the comparators weighed, the findings, and a recommendation.

▸ the validated schema (FairLendingReview)

type FairLendingReview = {
  verdict: "clear" | "concern" | "violation"
  decisionSupported: boolean       // supported by policy + the file?
  comparators: { id, decision, note }[]
  findings: string[]
  recommendation: string
}

Grounding

real ECOA / Reg B 12 CFR 1002. Disparate treatment and prohibited-basis proxy risk. Basis is a lens on fairness, never an input to credit merit.

synthetic Synthetic applicants + monitoring + comparators. Includes a near-identical pair differing on race with opposite historical decisions.

Governance seams

The three trust boundaries a runtime governance layer clamps onto. Shown here ungoverned, so you can see exactly what would be inspected, redacted, or blocked.

Model plane

context in

The Equipoise methodology plus the decision under review and the file.

governor → Confirm the basis is used only for outcome testing, never to question credit merit.

Tool plane

every read, incl. monitoring

Its reads include get_monitoring (the prohibited-basis attributes) and find_similar (comparators with their basis). The data the underwriter is denied flows freely HERE, by design.

governor → The mirror image of the underwriter's guard: a governor confirms only the fair-lending reviewer may pull basis, scoped to outcome testing.

Data plane

the commit

The recorded verdict written to the case journal; a violation feeds the Keystone gate.

governor → Route a violation straight to a hold rather than a soft note.

Equipoise is the deliberate counterpart to the blind underwriter: the one agent permitted the monitoring data, and only as a lens on fairness. The same governance layer that redacts basis for Spark is what authorises it here, scoped to outcome testing.

Evals & guardrails

3 / 3 golden Graded on the verdict, decisionSupported, and naming the comparator that drives it.

Disparate-treatment pair. Two near-identical files differing on race, opposite historical decisions: returns violation and names the comparator.
Supported decline. Clears a decline that rests on a genuine policy basis with no disparity.

Orchestration

Specialist (second line) outcome testing

⇢Reviews Spark's decision
⇢A violation holds the Keystone gate