§ DemosReal operations · one engine · REG-DEMO-2026.09

Real operations. Running live.

Each walkthrough is assembled from screenshots of a real end-to-end run (real cases, real agent executions, real email, real signatures, real approvals) captured from live browser sessions. No staged UI. No mocked data. Every AI demo gets applause; these are the runs that closed the case.

Eleven walkthroughs, in storyline order. Every number on this page is measured from the run’s own ledger, never typed, and where a run has a gap, the gap is named on the page, not papered over.

§ 01 · The demo set

Eleven runs, front to back.

Salazar’s completed 1035 exchange · the case marked Complete, with the Communications tab recording the close via a real Microsoft Teams reply.
01Insurance · Annuity · New

A 1035 exchange that chases, waits, and hands off when it should

Three exchanges, one fifteen-step process. The platform does the chasing; people make the decisions. Okafor arrives complete and goes straight through: suitability reviewed and decided by a real person, the carrier transfer request approved and sent, the contract issued, the register written back. Halvorsen’s disclosure arrives unsigned: the platform finds the missing signature, drafts the request to the producer, a person approves it, the corrected document comes back through a secure link, the owner signs for real, and the case issues. Salazar’s ceding carrier never answers: four reminders go out on the policy cadence, the request is escalated to a person on two real surfaces, and the case is closed by a real person typing “Approved” in Microsoft Teams.

MeasuredStraight-through: 4 human touches (3 policy-mandated) · 0.7 human minutes · 317 s case. Missing signature: 5 touches (4 policy-mandated) · 0.69 human minutes · 1 real signature · 4 real emails. Silent carrier: 3 touches (2 policy-mandated) · 0.59 human minutes · 4 chase reminders sent unattended · closed from Teams.
Shown liveIntake · extraction · SoR verify (real SharePoint registers) · parties auto-bound with an audit trail · completeness check · approve-then-send · real email · portal upload → auto-resume · real e-signature · chase ladder + escalation · approve from Teams · generated case brief · reason-required override · Communications drawer · determinations on the audit tab · SoR write-back · touch ledger.

On the recordFictional identities; all outbound email routed to one stand-in inbox; the signature ran against a real e-signature provider; the chat exchange was a real person at the keyboard. One gap named on the page: after the Teams close, the same case briefly still showed the underlying request as open on another screen, found and fixed the same day. Not yet shown: the inbound requirements letter arriving in a real mailbox (deferred to the next run).

Some screens shown here are from the current development build; the hosted demo environment is one release behind.

The platform’s drafted request for a missing death certificate · its reasoning, the recipient, and a single-use secure upload link, held for human approval before anything is sent.
02Insurance · Claims

A claims back office that runs itself

Three death claims, one 14-node process. The contrast is the story. One claim arrives complete and goes straight through. One is missing the death certificate: the platform notices, drafts a considerate request, a person approves it, it goes out over real email, the beneficiary uploads through a secure link, and the case resumes itself. One beneficiary never replies: the chase engine sends four reminders on the policy cadence, exhausts, and escalates to a person. The case is left honestly open.

MeasuredStraight-through: 2 human touches (the claim filing, then a policy-mandated review) · 51.5 s human · 128 s case. Missing document: 3 touches, 2 of them decisions · 53.6 s human · 205 s case. Silent beneficiary: 2 touches, 1 decision · 22.7 s human, then platform-only · 5 real emails sent (the request and 4 reminders) · 0 manual follow-ups, and the case left escalated and open, not closed.
Shown liveIntake · extraction · SoR verify (real SharePoint Policy Register over Graph) · completeness check · approve-then-send · real email · portal upload · obligation + auto-resume · chase ladder + escalation · adjudication under authority · AcroForm settlement letter · SoR write-back · audit + touch ledger.

On the recordChase cadence time-compressed; the secure link is standard sensitivity (the platform refused to downgrade a PHI-grade request rather than send one); the settlement letter is issued but not yet attached to the email; outbound routed to a stand-in inbox.

The vendor’s real email reply opened on the case · the field ticket attached, beside the running contract-compliance workflow and the case brief.
03Compliance · Missing documents

What happens when a document is missing?

Real SharePoint. A real email reply. A real signature from a signatory the platform bound. Invoice-exception cases on one 14-node graph: the field ticket is missing, so the platform drafts the request to the vendor’s accounts-payable contact (a party it bound itself from the company’s own vendor master), a person approves it, and the vendor simply replies to the email with the ticket attached; the attachment lands as evidence and the case resumes. Contract math on MSA §7.3 is applied deterministically; the variance exceeds the agent’s authority, so a human examiner decides, and if the examiner wants to let the full invoice stand, the platform refuses to record it until a reason is stated. The adjustment memo is signed for real by the vendor’s authorised signatory, whose authority the platform attested from the retrieved agreement. A second case has no authorised signatory on file: the platform refuses to request a signature nobody could give (zero envelopes) and a person decides how to proceed.

Measured$2,700 invoiced · $1,350 entitled · $1,350 variance > $500 authority · 2 human decisions · 0 manual party setup · 0 manual signatory setup · 1 signature collected · 0 chases · 347 s case. No-signatory case: 2 decisions · 0 envelopes · 0 escalations.
Shown liveGraph/SharePoint read + write-back · parties bound by the pipeline · completeness check · LLM-drafted outreach addressed by role · approve-before-send · real email → real email reply with attachment → auto-resume · clause reasoning with citation · reason-required override · Adjustment Memo PDF · attested signing authority + real e-signature · determinations on the audit tab · generated case brief · Communications drawer · full record.

On the recordThe vendor’s reply is sent programmatically from the workspace’s own mailbox because the mail provider can only send as its credentialed account (the accepted design, named in the report). The signature is applied through the e-signature provider’s own API rather than drawn on screen (headless cannot draw). Outbound routed to a stand-in inbox narrated as the vendor’s AP mailbox. The chase-loop case keeps its August captures.

Some screens shown here are from the current development build; the hosted demo environment is one release behind.

The install screen on the live demo box refusing an unsigned bundle (“Bundle trust check failed”) with the release stamp visible in the footer.
04Platform · Deployment

Built in one place. Installed cleanly in another.

One signed file. A live public box. Unsigned refused, and a wrong-vertical install refused too. A complete industry package (agents, forms, document templates, process flow, obligation policies) exported as one cryptographically signed file and installed into a different, live workspace at release 1.3.0 through one install screen. A signed preview verifies; an unsigned package is refused automatically; installing a different vertical into a workspace that already runs one is refused unless explicitly confirmed; the sibling install lands 12 applied, 4 of 4; the original workspace is provably untouched.

Measured27 publish scenes · 2 workspaces · 12 components · 4 of 4 obligation policies · 1 unsigned package refused · 1 wrong-vertical install refused.
Shown liveBundle export · offline signing · verify-before-extract · trust refusals · wrong-vertical guard · readiness check · permanent install ledger · release-version proof.

On the recordRecorded against the public demo box at release 1.3.0; the box is kept stopped when not in use. The wrong-vertical gap the August edition named on-page is now closed, and captured as a scene.

A Woodgrove Life case paused by the circuit breaker · the red banner shows the exceeded execution cap and the reset-and-resume control.
05Insurance · Safety limits

Why trust agents with regulated work?

A security reviewer’s walkthrough of the guardrails around every agent: a standing test suite, two models compared on real measured cost, a judge that has to earn calibration before it can gate anything, drift checked against run history, a per-case circuit breaker tripped on purpose and reset live, the workspace-wide Emergency Brake pulled and released, and one log where every safety action lands on the record. Re-driven on the current engine on 1 October 2026 — and that drive found the breaker itself leaking, which is now fixed rather than captioned.

Measured9 test cases run against one agent · 2 models compared with real measured cost · 2 independent safety limits, both tripped for real · case history exportable as JSON or CSV.
Human gateHuman review gates and compliance forcing shown live; audit export with certificate. A judge may not gate anything until it has earned calibration, and in this run it had not.
SystemsEval matrix + judge calibration · drift gate · per-case circuit breaker · workspace Emergency Brake · safety & governance log · audit export.

On the recordWhat was arranged for the demo is stated on the screen it affects: the safety-limit test uses a disposable case with a deliberately low limit and pre-filled details, the calibration labels are entered by the test script from a fixed rule, and the emergency brake is pulled and released within seconds. Four results are shown as honest “not yet” states rather than cleaned up: the drift check refuses to call a trend, the judge is not calibrated so rubric scores read “—”, the audit panel’s event preview sits below the fold in its capture, and the safety limit is not exact under parallel work. The July capture of this demo had the breaker leak captioned as a quirk; the re-drive proved it was a real defect, and it was fixed.

Patricia Doyle’s term-life case · the Communications tab showing the second request for her missing answers, her first reply and the reminder, all on one thread.
06Insurance · Underwriting

Three applications. Two policies, one decline, and a chase.

One underwriting workflow, run end to end on three applications. A clean profile takes the fast track to an issued policy. An incomplete application is chased through a protected link: one reminder, a re-check, and a second request for only the five answers still missing; then it takes the closer standard review and issues. The third is declined, with the notice on the record. Every policy that is issued is approved by a named reviewer before it goes out. Every screen is from one real recorded run on 5 October 2026.

Measured3 applications · 2 reviewer approvals · 1 reminder · 2 requests to the applicant, 15 + 5 answers · 42 screens.
Human gateA named reviewer approves every issued policy before it goes out: two real approvals in this run. The decline is recorded without one; how much sign-off each step needs is a per-step setting.
SystemsUnderwriting workflow · applicant chase over a protected link · APS / lab evidence · risk classification · policy issuance.

On the recordRe-driven 5 October 2026 to add the applicant chase. The one-day reminder was sent by running the real reminder process as if 25 hours had passed; nothing was edited by hand. Lab, physician and signature documents are generated sample files, and the records, underwriting and catalog services are simulated. Fictional applicants; the stand-in contact address only ever appears masked.

Some screens shown here are from the current development build; the hosted demo environment is one release behind.

Woodgrove Life applicant portal showing a self-submitted term-life application marked Completed.
07Insurance · Self-serve

From website form to issued policy, no human in the loop

A customer applies for term-life insurance on a public website and agents run the entire case (application, lab analysis, underwriting classification, policy issuance) all the way to Policy Issued. The only pauses are honest ones: waiting on external document uploads. Full autonomy where you’ve earned it, human gates where you haven’t.

Measured10 real emails sent automatically · 1 human approval.
Human gateNo internal handoffs; identity-verified portal uploads for lab and physician evidence.
SystemsAI advisor intake · self-service portal · lab / MVR orders · policy issuance.
Fabrikam Energy’s case list · Idris Balogun’s three linked cases: the Field Technician application, onboarding, and historian read access, each completed.
08Connected processes · Hiring to access

One application. Three processes. One connected hire.

Idris Balogun applies on Fabrikam Energy’s public careers page and the hiring case opens itself, reads the résumé, judges it against the company’s own role-requirements document, and puts the screening decision in front of the hiring manager. The interview invitation is drafted, approved by a person, and sent; the candidate answers by email and the case moves on by itself. HR records the hire, the offer is signed for real, and the hiring case writes the new hire onto the company’s own monday.com Onboarding board, which opens the onboarding case through a real webhook: a real Microsoft account, the equipment, the register, a signed safety acknowledgement, the welcome email. Onboarding’s own hand-off opens the access request: the supervisor, OT Security and IT each decide, the historian access is granted outside the platform and confirmed inside it. Three closed cases, linked in the product, and nobody re-keyed anything.

Measured3 connected cases from one application · 0 cases opened, assigned or started by hand · 8 decisions by named people · 2 messages approved before sending · 2 people named on a case by hand · ~6 min from application to last close.
Human gateEight decisions by five named people. Screening, interview outcome, the hire record, the onboarding plan, equipment, and a second, independent approver (OT Security) on plant-system access.
Shown livePublic careers intake with a real PDF · résumé extraction + role-requirements citation · approve-before-send · real email reply → auto-resume · real e-signature (offer and acknowledgement) · case-to-case hand-off over the customer’s own monday.com boards and webhooks · real Microsoft account created and verified · IT and OT tasks with attestation · two independent approvers on high-risk access · Related Cases linked both ways · generated case brief · full audit per case.

On the recordFictional company and people. The two board items that opened the second and third cases were written by the cases themselves onto a real monday.com account and opened through its real webhooks; the Microsoft account and the two register rows were checked directly in the directory and the lists. The candidate’s email reply was sent over Microsoft Graph from the company’s own mailbox. The inbox, the matching and the fulfilment are real; only the sender identity is stood in for. Both signatures were applied through the signing service’s own interface. The background screen is an outside vendor; the plant historian is outside the platform by design; company groups and a mailbox were not created. The candidate’s stand-in contact address is masked in seven frames.

Some screens shown here are from the current development build; the hosted demo environment is one release behind.

Regisseur My Work inbox showing an operator’s tasks · one actionable now, one complete.
09Operations · The operator surface

A day running the operation

What the humans see: the My Work queue, approving and completing tasks inline, the morning digest, SLA budgets and escalation ladders, and per-case cost on the dashboard. Then the part that matters: a case hits a broken configuration, the platform detects it and emails the operator a deep link, the fix lands, the case reruns, and the alert self-resolves. Your team gets one queue, not eleven tabs.

Measured7 chapters · 17 screens · 8 health-check failures shown and left unfixed · 2 monitoring sweeps, run on demand · 1 real incident detected, explained and resolved.
Human gateInline approve / complete from one worklist; SLA-breach escalation.
SystemsMy Work worklist · ops dashboard · SLA + cost telemetry · alerting.

On the recordFour things were arranged by the test and each is flagged on the screen where it happens: the broken configuration was planted by a script, the monitoring sweeps that normally run hourly were triggered on demand, the fix was applied by a script (the operator’s own action is the re-run), and the deep link was opened by the test rather than clicked from an inbox. Stated on the page: the alert email is recorded as accepted by the mail provider, but no inbox was checked, so arrival is not claimed.

Regisseur workflow builder · a four-node Beneficiary Change Request graph: Change Request Intake, Change Risk Assessment, Manager Approval, Change Effective.
10Platform · Build it yourself

From a blank canvas to a running case, built by the person who owns the process

An operations lead opens a blank canvas and draws a four-step Beneficiary Change workflow (intake, an AI risk assessment, a manager approval, change effective). She builds the agent for the assessment step with AI-assisted prompt drafting and a deterministic read-reason-write pipeline, tests it in simulation with a real model call and no side effects, binds a real intake PDF, then creates a real case and watches the platform run it end to end (agent assessment, human review, manager approval, done). No engineering team, no staged data.

Human gateThe agent’s assessment is held for human review; a manager approves before the change takes effect.
SystemsVisual workflow builder · AI-assisted agent authoring · schema + pipeline editor · simulation · PDF form onboarding · live case execution.

On the recordEvery frame is from one continuous build-and-run session against a live environment. The workflow, agent, form, and case were all created during the session shown.

Proseware Recovery · case DED-S1-0001 complete: a $612.48 Walmart shortage disputed, decided in favour and paid, with the shortage analyst’s recommendation and reasoning beside it.
11CPG & retail · Deduction recovery

Retailer deductions, worked to cash. Autonomy earned, then pulled back.

A revenue-recovery firm works 18 retailer deductions for a food supplier across Walmart, Target and Amazon. Your own detection engine plugs in at one step; agents check each retailer’s rules, assemble the evidence, chase the supplier for a missing price approval, file and reconcile. The shortage analyst earns autonomy after 11 reviews at 100% and files two disputes with no person at any step. A $7,850 promotional deduction always goes to an auditor. When Walmart changes its rule, the audit lead puts the analyst back under review with one recorded action.

Measured18 deductions · 16 disputes filed, 15 by the agent · 2 with no human at any step · 0.89 human touches per case · median 1.2 min from opened to filed.
Human gateAuditors approve every supervised recommendation. Over-cap promotional deductions with no agreement always go to a person. Autonomy is earned per claim family and comes back under review with one recorded action.
SystemsYour detection engine (one typed tool call) · retailer rules register · retailer portals · supplier upload link · audit export.

On the recordRetailer decisions and payments are simulated, so the recovered dollars show a case handled through to cash, not a win rate. The detection engine is a stand-in with scripted scores. One 30-day hold was released by running the real timer as if 427 hours had passed. Fictional firm, supplier and data; all email went to a test inbox.

Some screens shown here are from the current development build; the hosted demo environment is one release behind.

All companies, people, and cases shown are fictional and generated for demonstration. Every screenshot is unedited output from a real run of the Regisseur platform. Nothing is staged or mocked up. Where a run relies on a mock (a government agency, a credit bureau), the mock is labelled in the report itself.

§ Next step

Walk through the one that matches your operation.

Bring us the process, the systems of record, and the risk constraints. We will run the same cases with your data and show you where Regisseur fits, or does not.

Book a walkthrough →