Vivian Cho
Trust Officer at Larchmere. Reviews and approves every petition, distribution plan, and final accounting — by replying to a real email.
Trust Officer
Felix Moreau
Estate Administrator. Reviews incoming referrals and coordinates document collection and deadline tracking for every open estate.
Estate Administrator
Diane Okonkwo
Outside Probate Counsel. Retained for matters requiring outside legal review.
Outside Probate Counsel
Owen Sinclair & Rosalind Sinclair
Owen refers his aunt Rosalind's estate through Larchmere's public site — the referral that becomes Chapter 2's matter-spawn story.
Referring Nephew / Decedent
Caroline Ashby-Reyes & Eleanor Ashby
Caroline, Eleanor's daughter, is the executor of record for the full probate administration that runs through Chapters 3–5, alongside her brother Nathan Ashby, the estate's second heir.
Executor / Decedent
Priya Higgins & Walter Higgins
Priya is the executor on Walter's small estate — well under the statutory threshold, and eligible without a full probate.
Executor / Decedent
About this walkthrough
Every screen below is a real, unedited screenshot from a live, automated run of Regisseur, captured on July 12, 2026 — not a mock-up or a staged demonstration. Larchmere Trust Company, Vivian Cho, Felix Moreau, Diane Okonkwo, Owen Sinclair, Rosalind Sinclair, Eleanor Ashby, Caroline Ashby-Reyes, Nathan Ashby, Walter Higgins, and Priya Higgins are fictional; all data shown is illustrative.
The probate court in this walkthrough is a simulated integration standing in for a real court's e-filing system — the platform's filing calls, docket checks, and confirmation numbers you'll see are genuine, but no real court e-filing occurred. In production, the same configuration surface connects to a real county's e-filing system.
The trust officer's approval emails really arrive by email, and the platform's reading, sender-verification, and confirmation exchange are the product's real code, running live — only the inbound reply's delivery transport is simulated in this environment rather than sent from a live mail client.
Deadline monitoring runs on an hourly sweep in production; for this capture, that same sweep was triggered on demand rather than waiting out the clock. One deadline — the Inventory & Appraisal filing — was deliberately left to run past due, to show detection and escalation honestly rather than only the happy path; the creditor-claim window alongside it was tracked the same way and never breached.
The generated DE-111 Petition for Probate, the DE-160 Inventory & Appraisal, and the small-estate affidavit are labeled demonstration reproductions of the real California Judicial Council forms — not the official forms themselves. A firm's own current form templates can be substituted directly.
All of the estate math shown — small-estate eligibility, deadline arithmetic, and each heir's pro-rata distribution share — is computed deterministically by the platform. The AI writes narrative summaries only; the trust officer and outside counsel decide everything.
Before any matter exists, before any login — Larchmere's own public site: probate administration, the small-estate affidavit fast path, and referral triage, the trust officer and estate administrator of record, and the one way in: begin an estate settlement.
Larchmere's public referral-intake page — for an executor, heir, or referring professional who isn't yet sure which process applies. Decedent and estate basics, plus the referrer's own contact details, is all it asks for.
Owen Sinclair refers his aunt's estate: decedent Rosalind Sinclair, Alameda County, an estimated $310,000 gross value — comfortably above the small-estate threshold, so this referral will classify onto the full-probate path.
The referral is submitted. Owen receives an estate number for his records — Larchmere's administrator has already been notified.
Seconds after Owen submitted, the referral appears in Larchmere's operations view — already active. No one manually opened a file or routed the intake.
The Referral Intake & Classification agent has already read the referral and classified the administration path by estimated value against the $184,500 statutory threshold — a deterministic transform, never LLM judgment. Felix Moreau's administrator review is the next step.
Filtered to the estate's own attributes: county, estimated value, and administration path — the deterministic classification the platform computed, on the record.
Felix signs in as himself and sees the pending Administrator Review task directly on the node — the same Complete Task panel every human node in this platform uses.
Vivian Cho decides whether the firm takes on Rosalind's referred estate — the same accept/decline gate every referral passes through.
Every message on Rosalind's referral so far, on the record — Larchmere has just emailed out the review request for the Accept/Decline gate. The reply that closes it, next, is a named, real email from the trust officer.
Vivian replies APPROVE, confirms YES, and the gate closes — the real reply-to-approve command loop, on the record.
Filtered to the estate's own attributes: the accepted classification, and — the proof this really happened — the matter-opened status and the new matter's own job id, written by the platform's Matter Spawn step, not typed in by a person.
A new case — "Estate of Rosalind Sinclair" — already in Larchmere's own case list. Nobody clicked "New Case": the referral-triage pipeline's Matter Spawn step opened it the instant Vivian accepted.
One case created another, entirely through the platform's own tools — no human ever opened it by hand: Rosalind's decedent/executor/estate facts carried straight into her new matter, so the Estate Intake & Document Request step could genuinely run and request Caroline's — Owen's referred contact's — documents.
Estate Profile Verification and DE-111 Petition Generation have already completed automatically — Larchmere has already emailed Caroline a secure link requesting the death certificate, will, asset statements, and executor ID.
Eleanor Ashby's estate record: Alameda County, an estimated $620,000 gross value, and the estate's status as it moves through the pipeline — every fact the deadline guardian will later track.
Caroline Ashby-Reyes, the executor, uploads the estate's opening documents through the same secure, single-use link Larchmere emailed her — no email attachment, no manual intake. The portal header names her actual task, "Executor Documents Received" — the node's own human-readable label, never the raw node id (product fix, this recapture).
The DE-111 Petition Preparation agent drafts a brief cover narrative confirming the petition is ready for counsel review, referencing the decedent, the petitioning executor, and the county of administration.
The Case Record's Artifacts view lists the demo-reproduction DE-111 Petition for Probate, stamped with the node that generated it and when.
The actual PDF Larchmere's platform generated for Eleanor's petition — the same AcroForm-fill engine used everywhere else in the platform, reproducing the DE-111's key parts. The footer plainly labels it a demo reproduction, not the official Judicial Council of California form.
Every message Larchmere has sent on Eleanor's matter so far, on the record — the request for Officer/Counsel Review has just gone out, and Caroline has already opened her own document-request link. The reply that closes this gate, next, is a named, real email from the trust officer.
Vivian replies APPROVE, confirms YES, and the gate closes — attributable and auditable, no application login required.
The petition is filed with the probate court (a demonstration mock in this environment) and the same docket check reports letters issued — the court case number and the letters-issued date, both on the record.
The petition is filed, letters are issued, and the real §8800/§9100 statutory deadlines have just been computed from the letters-issued date — a centerpiece of this whole walkthrough, a deterministic transform, never a guess.
The Deadline Computation agent's own Review tab — the creditor-claim window (§9100) and the inventory & appraisal due date (§8800), both computed deterministically from the letters-issued date, four months out.
The executor supplies the account statements and valuations Larchmere needs to complete the Inventory & Appraisal — through the identical portal-link pattern used for the original document request.
Inventory & Appraisal is a fully autonomous agent node with no human assignee, so it never appears in anyone's personal worklist — the OVERDUE filter only surfaces items assigned to the signed-in person. The ops dashboard's SLA Breaches tile and the case's own Escalations feed (both captured next) are the real evidence for this breach.
Larchmere's operations dashboard: the SLA Breaches tile reflects the real the escalation record row the coordinator sweep wrote for Eleanor's Inventory & Appraisal deadline — a genuine breach detection, not a countdown timer.
The moment the Inventory & Appraisal (DE-160) filing completes, the SLA breach resolves on the record — the same escalation feed, now showing "No open escalations — All caught up." for this matter.
The DE-160 Inventory & Appraisal is filed with the probate court — the breach detected and resolved above. The Creditor Claim Window is next, wired with its own real, future-dated deadline.
The creditor-claim window sits in the administrator's own "My Work" list with a genuine future due date, computed the same §9100 way as the inventory deadline — tracked, not overdue. This is the direct honest contrast to the deliberate breach story above.
The Claim Review Support agent totals the filed creditor claims (a deterministic transform) and drafts a factual summary — it does not decide which claims are allowed. The real Approve/Reject controls the trust officer clicks are visible on the node's own Review tab (the the platform, ).
The Claim Review node, right after the trust officer's real click on the Approve control shown in the previous scene — the totals and case values it wrote are now on the record; the platform only totals and summarizes, the officer decides which claims are allowed.
The distributable residue and each heir's pro-rata share have been computed by a deterministic largest-remainder transform — never LLM judgment. The Distribution Plan Approval gate is next.
Filtered to the case's document attributes: the computed distribution shares (each heir's computed cents, guaranteed to sum exactly to the residue) and the plain-language the distribution plan summary echoing it verbatim.
The request for Distribution Plan Approval has just gone out — to the same trust officer visible throughout this thread, who has already handled every earlier gate on this matter by email.
The same reply-to-approve loop, one more time: Vivian replies APPROVE, confirms YES, and the distribution gate closes.
The final accounting and distribution receipts are assembled and filed with the probate court (a demonstration mock in this environment) — the court confirmation number, on the record.
Final Accounting Approval's request has just gone out — the last human gate before Estate Closed, going to the same trust officer seen approving every earlier gate in this thread.
The last reply-to-approve gate on this matter: Vivian replies APPROVE, confirms YES, and Estate Closed is next.
The full probate journey: intake through document verification, petition, filing, letters, the computed deadlines, the deliberate breach and its resolution, the creditor window, claim review, distribution, final accounting, and Estate Closed — every node done, none stranded.
Seconds after the matter opened, Larchmere has already emailed Priya Higgins, Walter's executor, a secure link requesting the death certificate and asset statements needed to determine small-estate eligibility.
Priya Higgins uploads the death certificate and asset statements through the same secure, single-use portal-link pattern used across every Larchmere matter.
This node's own Review tab reports only that the pipeline completed — it does not display the eligibility verdict inline. The days-since-death count, the value-threshold check, and the eligibility status this scene set out to show are the case's own attributes, visible next on the Case Record, written by this same deterministic transform.
Filtered to the estate's own attributes: the eligibility status, the days-since-death count, and the estimated estate value — every one of them written by the deterministic transform chain, not typed in by a person.
The §13101 small-estate affidavit (demo reproduction) has been generated — the case now sits at the one gate a human must clear before institution delivery.
The request for Officer Review — Affidavit has just gone out — the last human gate before Small Estate Complete. The reply that closes it, next, is a named, real email from the trust officer.
The same reply-to-approve loop as every other officer gate in this package: Vivian replies APPROVE, confirms YES, and institution delivery is next.
The full small-estate fast path: intake, document collection, the deterministic §13100/§13101 eligibility determination, the affidavit, the officer's approval, institution delivery, and Small Estate Complete — every node done.