The problem
I’d been coordinating a small team of AI agents, including a project manager, engineers, a designer, and a security reviewer, across several projects at once. The work was getting done, but I had nowhere to actually see it. Who’s active right now? What decisions are waiting on me? Which blocker is about to slip? It all lived in scattered reports and commit logs. I wanted a cockpit.
The approach
The dashboard reads the team’s own artifacts, the QA reports, decisions, and blockers every role writes, and turns them into an operator’s view: an agent feed, a “What Needs You” ledger of the decisions waiting on me, a blocker board, a health grade per project, and velocity over the last week and month. It is a server-rendered Next.js app. In private use it runs against real state, behind a sign-in that admits exactly one GitHub account, mine.
The interesting problem was making any of it public. The real data is sensitive: security findings, private notes, decisions in flight. It can never be published, but a demo nobody can click proves nothing. So there are two builds of one codebase. The public demo runs in a hard-locked demo mode: every data reader short-circuits to a synthetic snapshot before it can touch a real file, every write returns a plausible answer and persists nothing, and a build guard refuses to produce a public build at all unless demo mode is on.
What shipped
A public demo you can drive. Sign in as a guest, approve or defer a decision, triage a blocker, open the command palette, export the reports view as CSV, switch themes. A Think Tank board that sorts ideas into Do it, Later, and Skip, and a dispatch queue with its relay activity. Fifteen agents in the feed and a health grade per project, all on synthetic data that resets each session. The demo says it is a demo, and it dates the snapshot it was built from, so nobody mistakes the numbers for live operations.
Inside the build
A closer look.
The Think Tank: ideas triaged into Do it, Later and Skip. 
The Dispatch queue, with agent work lined up alongside its receipts.
Where it stands
Private operator app · public synthetic demo
My role
Mine. The seam. The real data here, including security findings, private notes, and decisions in flight, can never be published, but a demo nobody can click proves nothing. I chose a synthetic snapshot, demo-mode read and write paths, and a build guard. Every data reader short-circuits to a synthetic snapshot before it can reach a real file. The write path is severed, so an approve button returns a plausible answer and persists nothing. And the build itself refuses to produce a deploy until it is told which kind it is, public demo or private real, and refuses a real one outright if the login gate is off.
The agents’. All three layers, and the guard that reads the published snapshot back and fails the build if anything in it looks real.
What I check. That the synthetic build passes its positive checks and refuses unauthorized modes. Those checks verify the tested conditions; they do not establish independent failure tolerance.
The rejected shortcut
The alternative was a single demo-mode flag, which is one misconfigured environment variable away from serving my actual findings to the open internet. These controls cover different points in the path, but they share mode configuration.
Reflection
The build taught me that make it public and keep it private aren’t opposites. With the right seam, you can ship a faithful, interactive demo while the sensitive version stays private.
That separation turned out to be the whole design.
