Regisseur · Product Walkthrough
A day in the life of a platform operator
How do you run this thing, and what happens when something breaks? Follow one operator through a routine morning review, a configuration health check, setting up a guardrail, a real incident, and watching the platform detect, explain, and help resolve it — before healing itself.
7
Chapters, one operator's day
1
Configuration issue found and fixed
1
Real incident, detected and resolved
0
Manual database edits
18
Screens captured live
About this walkthrough
Every screen below is a real screenshot from an automated, end-to-end run of Regisseur, captured live — not a mock-up. The people and the company are fictional; the data is illustrative. Two moments in this story were deliberately arranged so the whole incident could be shown start to finish in one sitting: the broken configuration in Part 4 was introduced on purpose to demonstrate what happens when something breaks, and the automatic monitoring check in Part 5 — which normally runs about once an hour — was triggered on demand rather than waiting for the next scheduled pass. Everything else, including the detection, the alert, the email, the fix, and the self-healing resolution, is the product's own real behaviour.
Part 1
Morning Review
One glance at the operations view — what needs attention today
The operations lead starts the day the same way every day: one screen. Active cases, stuck nodes, queue health, error rate, halt status, open escalations, SLA breaches, recent failures, open alerts, and this week's automation spend — all in one grid, refreshed every ten seconds. No hunting through logs, no separate dashboards to reconcile.
Two tiles the operations lead checks first: Stuck Nodes — anything that has been sitting eligible-but-untouched, or genuinely blocked, longer than expected; and Open Alerts — anything that has already crossed a configured threshold. A node that goes fully blocked is flagged with a red "Blocked" badge and a plain-English reason, not just a timestamp.
Real spend, not an estimate: this week's and last 30 days' LLM cost across every agent execution in the workspace, plus a per-case average and the highest-cost outlier cases. The operations lead can see exactly what the automation is costing before anyone asks.
Part 2
Config Hygiene
A built-in health check finds and fixes configuration gaps
Before doing anything else, the operations lead runs a configuration-integrity check: every agent reference, every form-template binding, every webhook token the workspace depends on. This is a read-only preflight — it never touches case data.
One click, and the workspace's configuration health is scored: pass, warn, fail counts across every check the Doctor knows how to run. The result is saved so the next person to open this tab sees the same picture.
Every finding names the exact check, the exact subject (the agent slug, the template node, the event source), what's wrong, and — where the system knows how to say it — the remedy. No cryptic error codes: an operator can act on this without opening a debugger.
Part 3
Guardrails
Alert rules — set once, delivered by email and Microsoft Teams, with reminders
The operations lead already set a guardrail for exactly this scenario: if any node in this workspace goes fully blocked, notify — by email and by a Teams DM — and keep reminding every four hours until it's resolved. Nothing fires yet; this is pure configuration.
Screenshot omitted for privacy
This frame displayed a demonstration contact email address, so it was withheld from the published report. Every other screenshot in this walkthrough is unedited output from the same real run.
Blocked nodes ≥ 1, remind every 4 hours, delivered to email and a named team member's Teams DM. One rule, plainly readable, doing exactly what it says.
Screenshot omitted for privacy
This frame displayed a demonstration contact email address, so it was withheld from the published report. Every other screenshot in this walkthrough is unedited output from the same real run.
Part 4
Something Breaks
A case hits a broken configuration
This fault was deliberately induced for this demo: a case node was pointed at a retired agent configuration. The platform did exactly what it should — it refused to guess, and it stopped cleanly at the one affected step instead of failing silently or corrupting the case. Every other node in this case is untouched.
Opening the blocked node shows exactly what happened and why, in language a non-engineer can act on: "Agent dispatch failed for node Triage Claim (this step): agent 'retired_underwriting_agent_v0' could not be resolved to a live agent definition — node blocked. Remedy: fix or re-seed the …" No log-diving required.
The same tile the operations lead glanced at this morning now shows a red "Blocked" badge on this exact node — the system surfaced the problem on the dashboard the moment it happened, with no manual check required.
Part 5
The Platform Notices
An automatic alert fires with a direct link to the problem
The guardrail set up this morning has done its job: the coordinator's hourly sweep (compressed here for the demo) evaluated every active alert rule against the workspace's real state, found the blocked-node count over threshold, and opened a firing. The Open Alerts tile shows it immediately.
The real alert email, screenshotted in the recipient's inbox during this demo session (deliveries are routed to a test inbox in this environment). Severity, signal, the exact count against the threshold, and a deep link that lands one click away from the blocked node — with the same plain-English explanation and remedy the operator will see on the node itself.
Screenshot omitted for privacy
This frame displayed a demonstration contact email address, so it was withheld from the published report. Every other screenshot in this walkthrough is unedited output from the same real run.
Part 6
The Operator Acts
Follow the link, fix the configuration, resume the case
The operator follows the link the alert pointed at — no searching through the case list, no guessing which node broke. The deep link lands exactly on the blocked node's detail panel.
With the agent configuration restored, the operator clicks "Re-run Agent" — the same control available on every agent node, not a special admin escape hatch. The processing picks back up exactly where it left off.
The node is no longer blocked; the case continues through the rest of its pipeline exactly as if the interruption had never happened. Nothing about the case's history was lost or silently rewritten — the block, the fix, and the rerun are all part of the permanent record.
Part 7
Self-Heal
The alert clears itself and the board goes clean
The next sweep (hourly in production; compressed here for the demo) re-evaluated the same signal, found it back under threshold, and closed the firing automatically. No operator had to remember to check back and clear it manually.
From routine morning check, to a real induced fault, to detection, to a two-click fix, to automatic self-resolution — the whole loop closed without anyone needing to write a ticket, page a second engineer, or dig through logs. This is what running the platform day-to-day looks like.
