I was running a multi-agent orchestrator (Cogniflow) for a course-production pipeline, and it had grown two separate tools around it: an Observer to watch runs and a Configurator to edit pipelines. Two servers, two ports, two mental contexts — and the person actually doing the work (in this case, students in an observability masterclass) had to hold both open and remember which one did what. That’s a familiar failure mode in any team building internal agent tooling: monitoring and configuration start as separate quick scripts and never get merged, so every new user pays the “which dashboard do I need” tax. At team scale this is the same problem as having a metrics dashboard and a deploy console that don’t talk to each other — you end up tab-switching to debug something that should be a single screen.

Cogniflow UI is one FastAPI process with two route namespaces that never collide: `/pipelines/…` (Observer) and `/pipeline/…` (Configurator, singular). From the home page you see every pipeline as a card; click one and you land on a live board that polls for status, shows per-agent cards with token-context usage against a configurable budget, tails the run’s event log, and gives you Start / Stop / Pause / Resume / Reset buttons plus an Approve/Reject action for any agent sitting at a human checkpoint. There’s a full run History view with diffs between runs and a place to annotate what happened.

Switch to the Configurator (one navbar click) and you’re editing the same pipeline that’s running: a DAG graph view where you add or delete agents and edges and reorient the layout, a per-file prompt editor for each agent’s system and task prompts with version history and one-click restore, a raw file browser for anything else in the pipeline folder, and a Validate action that checks required “taglines” (role/responsibilities/guardrails, description/goals/context/etc.) are present before a run. A “Specialize” button shells out to the Claude CLI to auto-tune a prompt template for a specific role, and there’s a separate library view for managing those reusable prompt templates.

The other half of the design is distribution: this ships as a `cogniflow-ui.exe` / `.app` PyInstaller build for non-technical users, not just a dev server. On every launch it seeds a curated set of example pipelines (writer-critic, code-review-board, newspaper-ai-article, software-factory, universe-origins) into the orchestrator’s pipelines folder via an additive, version-gated overlay — first launch gets the examples, later launches leave the student’s edits and run history alone unless the bundled version number moves forward. That seeding logic (tracked by a small `.ui-seed-marker.json`) is its own small piece of engineering: it has to never delete user work, never touch a user-created pipeline with the same folder-overlay logic, and still let you ship an updated example prompt to everyone on the next release.

The interesting problem wasn’t the UI, it was the seeding lifecycle: how do you ship “starter content” into a mutable folder that the user is also editing, forever, without a database? The answer I landed on — additive overlay plus a version-stamped marker file, never a delete — is a small pattern that generalizes to anything that ships example/config data alongside user data (starter templates in a CMS, default dashboards in an analytics tool, seed data in a local-first app). I also learned that merging two previously-separate FastAPI apps into one process is easy if you design the URL prefixes to be structurally disjoint (plural vs. singular) from the start — retrofitting that later would have meant a rewrite of every internal link and redirect.

The natural next step is the “cyclic” flavor UI mentioned in the same repo — the DAG orchestrator assumes a fixed agent graph per run, but a cyclic flow (agents that can loop back, retry, or re-route based on output) needs a different board and a different graph editor, which is already scaffolded as a separate stack. Beyond that, the packaging model here — a signed desktop binary that points at a config file for the only two things a non-technical user needs to change (host/port, data folder) — is directly reusable for shipping any internal agent tool to a non-engineering audience inside a company: ops teams, subject-matter experts running review pipelines, anyone who shouldn’t need Python installed. The approve/reject checkpoint plus the taglines-validation gate are also the seeds of a governance layer — if you needed audit trails on who approved what agent output and why, that’s a small extension of what’s already logged per run, not a new system.