Workflows
The Workflows surface is the live operations view for Agirunner.
This page matters because it is where the product stops feeling like a set of settings pages and starts feeling like a working system. If something important is happening right now, this is usually where an operator notices first.
What You See
Section titled “What You See”At a high level, the page is split into three layers:
- a left rail for finding workflows
- a central board for work-item progress
- a lower workbench for detailed inspection and intervention
This is why the Workflows page is more than a list. It is where operators spend time while work is active.
Workflow Rail
Section titled “Workflow Rail”The rail supports:
- search
- lifecycle filtering
- ongoing vs recent views
- needs-action filtering
- creation of new workflows
That makes it the fast-entry point for finding work that matters right now.
The rail is not passive navigation. It is part of the operating model:
- it can open the launch dialog for a new workflow
- it can change the current workflow scope without leaving the page
- it keeps live and recent work visible in one place instead of forcing context switching
Board And State Strip
Section titled “Board And State Strip”The selected workflow shows:
- the workflow state strip
- work-item cards and lane state
- cues for orchestrator activity and operator attention
This is the fastest visual answer to “where is the work stuck or moving?”
The strip keeps workflow-wide posture visible while you inspect lower-level details. The board makes work-item state legible: which parts are moving, which are waiting, and where an operator should look next.
Workbench Tabs
Section titled “Workbench Tabs”The workbench is where the workflow becomes understandable:
- live console activity
- deliverables and artifacts
- needs-action context
- steering and operator updates
If the rail answers “which workflow?” and the board answers “where is it?”, the workbench answers “what is actually happening?”
How It Connects To The Rest Of The System
Section titled “How It Connects To The Rest Of The System”The workflows page is where the rest of the product comes together:
- Playbooks And Authoring define the reusable process the workflow is following
- Workspaces provide the durable project context the workflow runs against
- Orchestrator shapes how work is broken down and supervised
- Specialists, Skills, And Models define the specialist identities the workflow can route into
- Workflow Detail, Live Logs, and Live Containers provide the evidence surfaces when the board view is not enough
This page is effectively the live join between authored process, control-plane state, and runtime execution.
Common Operator Loop
Section titled “Common Operator Loop”A realistic operator loop on this page looks like:
- find a workflow in the rail
- inspect the board to see current position
- open the workbench tab that matches the problem
- add work, steer, pause, resume, or review as needed
- stay on the same page while the workflow keeps moving
That last point is a deliberate product choice. Mission Control is meant to reduce operator context switching rather than create more of it.