Pipeline studio

The Pipeline Studio (/space/studio) is the visual workflow orchestrator. Where chat is turn-based, the studio is graph-based: you compose agents and steps as nodes connected by edges, then run the whole graph with conditional routing, hand-offs and scheduled triggers.

New to the AI side? Read AI concepts from scratch first — Structured output / plan extraction is what turns a chat reply into this graph.

The workflow model

Workflows are persisted in Postgres (workflows, workflow_nodes, workflow_edges, workflow_runs in schema.ts):

• Workflow — name + owning user (optionally linked to a conversation).
• Nodes — steps in the graph (agent calls, tools, gates).
• Edges — directed connections between nodes (success, failure, conditional).
• Runs — execution instances with status and step history.

The canvas

WorkflowStudio renders an interactive canvas (workflow-canvas.tsx, workflow-visualizer.tsx, workflow-nodes.tsx):

• Drag & drop node placement and edge wiring.
• Per-node configuration — which agent/model runs, what tools it may use, inputs and outputs.
• Approval gates — approval-card.tsx inserts human-in-the-loop checkpoints before destructive or external actions.
• Editable mode for authoring, view mode for inspecting an executed plan.

The concepts behind the studio

The studio makes two AI ideas tangible:

• Structured output. The orchestrator’s plan isn’t free prose — it’s recovered as a schema-shaped object (steps, dependencies) via a tolerant JSON scanner plus strict Zod validation. That structured data is what can be rendered as graph nodes and edges; free text can’t. See AI concepts → Structured output.
• Agent orchestration as a graph. Running a workflow is the same multi-agent machinery as chat — orchestrators, executors, verifiers — but arranged as an explicit dependency graph instead of a turn-by-turn dialogue. Conditional edges are decision points; hand-offs pass work between agents; approval gates are human-in-the-loop checkpoints before destructive/external actions.

Where plans come from

The studio is tightly coupled to chat orchestration:

1. The Lead Orchestrator plans a task in the chat and emits a structured plan in its reply.
2. The client extracts it with extractPlanFromContent → safeParsePlan (tolerant JSON scanner + strict Zod validation in output-schemas.ts).
3. The extracted plan can be opened in the studio as a visual graph — nodes become the plan steps, edges the dependencies.

This is the canonical path: plan in chat → refine visually in the studio → execute. The extraction is robust against missing code fences and prose wrapping, so plans survive even when the model doesn’t format them perfectly.

Executing workflows

Runs flow through workflow_runs with per-step status. Orchestration execution reuses the same agent machinery as chat (agent modules: orchestrator, executors, verifiers), so each step gets the same per-step usage tracking (tokens, cost, latency) visible in the ops panel and governance metrics.

Conditional routing & hand-offs

Edges can carry conditions — a step’s output routes the next step (retry, escalate, proceed). Hand-offs let one agent pass work to another mid-graph, which is how the hierarchy (orchestrator → executors → verifiers) plugs into the pipeline model.

Scheduled triggers

Workflows can be scheduled through Cron (/space/cron): instead of manual runs, a trigger fires the graph on a schedule. See the Usage, health & teams page for cron details.

Related surfaces

• Chat ops panel — live per-step status of an orchestration run.
• Agent hierarchy — the runtime agent tree that executes steps.
• Cron — scheduled execution of pipelines.