Jet
Back to Jet

Workflows — Multi-Agent Orchestration

A workflow is an ordered chain of skills. Each step inherits its skill's system prompt + required tools, and a simple template lets later steps consume earlier steps' output via {{prev.output}}. This is the Blueprint's Level-3 orchestration — the thing that takes Jet from "AI assistant" to "AI agent network."

The three patterns

Pattern Shape Best for Status
Sequential chain Each step's output feeds the next. Strict order. Linear pipelines: collect → analyze → write → QA Shipped
Parallel network All steps run concurrently with the same input; an orchestrator agent synthesizes. Fan-out research, new-client onboarding packages Shipped
QA loop Execute → score via reviewer agent → retry up to N if score below threshold High-stakes client-facing output, regulatory documents Shipped

Choosing a pattern

Set workflows.pattern to one of sequential, parallel, or qa_loop. The workflows.config JSON column carries pattern-specific tunables.

Parallel config

  • No required config. All steps receive the same raw workflow input; the orchestrator uses an inline synthesizer prompt.
  • Every specialist step runs concurrently. Failures are captured but don't abort the batch — the synthesizer handles partial results.
  • A synthesizer pseudo-step is persisted to workflow_step_runs at position = steps.length so the UI shows a full timeline.

QA-loop config

  • minScore (default 4) — threshold on the reviewer's overall 1-5 score
  • maxRetries (default 2) — up to N retries after the first attempt (so max 3 attempts total)

The loop runs the sequential chain, then a reviewer agent scores the output. If the score is below minScore and retries remain, the next attempt folds the reviewer's critique into the first step's input as a "Previous reviewer critique — address these before answering" block. Each attempt's rows are tagged with workflow_step_runs.attempt so the UI can flip between tries.

Data model

  • workflows — metadata (slug, name, pattern, input_schema)
  • workflow_steps — ordered list (position, skill_id, input_template, model_preference)
  • workflow_runs — per-execution record (status, final_output, totals)
  • workflow_step_runs — step-by-step detail (tokens, cost, duration, error)

The input template

Each step has an optional input_template. Two placeholders are supported:

  • {{input}} — the workflow's run input
  • {{prev.output}} — the previous step's output

If a step has no template, the step receives the raw input. This keeps simple chains readable while allowing complex wiring when needed.

Example — Monthly Client Report (ships with marketing-agency pack)

{
  "slug": "monthly-client-report",
  "name": "Monthly Client Report",
  "pattern": "sequential",
  "steps": [
    {
      "name": "Collect data",
      "skillSlug": "full-campaign-audit",
      "inputTemplate": "Collect and structure 30 days of data for: {{input}}"
    },
    {
      "name": "Generate report",
      "skillSlug": "client-report-generator",
      "inputTemplate": "Use this audit output to draft the client report:\n\n{{prev.output}}"
    }
  ]
}

Running a workflow

POST /workflows/:id/run
{
  "input": "ent_acme — September",
  "entityId": "ent_acme",
  "projectId": "prj_q3_report"
}

entityId and projectId propagate to every step — the context loader pulls the client's dossier + the project brief into each step's system prompt automatically. This is why a workflow built for one client works for every client without modification.

Observability

Every step run is persisted to workflow_step_runs with its input, output, tokens, cost, duration, and any error. The UI shows a per-step breakdown.

  • GET /workflows/:id/runs — list recent runs
  • GET /workflows/:workflowId/runs/:runId — step-by-step detail

API reference

  • GET /workflows — list
  • POST /workflows — create (with optional steps array)
  • GET /workflows/:id — detail (includes steps)
  • PUT /workflows/:id — update (replaces step list if steps is included)
  • DELETE /workflows/:id
  • POST /workflows/:id/run — execute with input + optional context
  • GET /workflows/:id/runs — run history
  • GET /workflows/:id/runs/:runId — step detail

Next steps

  • Packs — ship workflows as part of a business shape
  • QA & Approvals — how workflow outputs get reviewed