Real work has phases
Migrations, refactors and roadmap-driven features all unfold across many discrete steps - a single prompt can’t carry that load.
Product · Workflow Builder
Compose AI engineering pipelines. Visually.
Drop a designer, attach a checker, gate it with an evaluator, schedule the whole thing. Workflow Builder is the orchestration layer for your fleet of coding agents - every step typed, every run replayable.
workflow · ship-the-fix · v12
Prompter
refine
Designer
running
Checker
verdict
Evaluator
score 87
Open PR
queued
5 steps · 1 loop · 1 trigger ready to publish
The problem
Engineering work isn’t linear.
Quality is multi-pass
Designers write, checkers test, evaluators score, judges arbitrate between branches. None of that fits in a chat window.
Maintenance never ends
Dependency audits, doc drift, dead-code sweeps - recurring jobs deserve their own cadence, not yet another Monday-morning ticket.
How it works
Anatomy of a workflow.
A workflow is a typed blueprint of agents, steps and gates. Every node has a persona binding, every edge a clear contract, every run a permanent record.
Designer
Checker
pass ⇒ open PR
Open PR
Weekly · Mon 09:00
Step - one persona, one job, fully typed
Persona binding - model, tools, skills, learnings
Checker agent - verdict ⇒ pass or feedback
Branch on result - quality gate or fallback
Recurring trigger - fires on a cadence
Step types
Eight building blocks. Endless compositions.
Every block in your pipeline is a typed step with its own persona, sandbox config and learnings. Mix and match - the orchestrator handles the rest.
Designer
Primary coding agent. Ships the change inside a fresh sandbox.
Checker
E2E reviewer that returns a structured pass / feedback verdict.
Evaluator
Scores the diff across five dimensions and a composite quality score.
Judge
Compares parallel branches and picks the winner with rationale.
Prompter
Turns a vague ask into a detailed, file-cited specification.
Investigator
Reads code, reproduces bugs, writes a report for downstream steps.
Optimizer
Runs after approval to polish naming, comments and dead code.
Answerer
Resolves open questions surfaced by issue investigation.
Compound work
Sprint Chains turn a plan into shipped code.
A Sprint Chain runs the same workflow once per sprint - each sprint a separate, reviewable pull request. Phase 1 lays groundwork; phase 2 builds on it. If sprint 3 fails, resume from sprint 3 - the chain remembers everything: prompts, PR URLs, sandbox config, the lot. This is how multi-month migrations actually ship - not in one heroic mega-PR, but as a typed sequence of small, mergeable steps.
chain · migrate-to-app-router · 5 sprints
- 1#1428mergedSprint 1 · Scaffolding
- 2#1431mergedSprint 2 · Data layer
- 3#1442reviewSprint 3 · UI rewrite
- 4-runningSprint 4 · Tests
- 5-queuedSprint 5 · Cleanup
2 / 5 mergedresume from sprint 3 anytime
On a cadence
Recurring Tasks keep your repo healthy while you sleep.
Schedule any workflow daily, weekly, biweekly or monthly. The platform fires the run, captures the diff and opens a PR - no calendar invites, no Monday tickets.
schedule
Every Monday · 09:00 · weekly tech-debt sweep
next fire · 2d 14h
Dependency auditStale PR reviewDoc drift check
Editor showcase
Visual canvas. Versioned manifest. Live runs.
Compose your pipeline on a drag-and-drop canvas, ship the YAML to your repo, then watch each step stream in real time. Same workflow, three views - pick your poison.
Visual canvas
Drop nodes, wire edges, bind personas. Round-trips losslessly to the manifest.
canvas · ship-the-fix · draft
Prompter
Designer
Checker
Evaluator
Built for engineers
Workflows that survive a real code review.
Six properties that distinguish a serious orchestration tool from a no-code toy.
Git-native
Workflow manifests live in your repo. Pull requests can change a workflow exactly the way they change any other code.
Version-controlled
Every revision is recorded. Roll back to last week’s pipeline in one click and the run record points at the matching version.
Typed schema
Steps, personas and triggers all validate against a strict TypeScript schema. Bad workflows fail at edit time, not in production.
Local testing
Run any workflow against a synthetic prompt before promoting it. Costs $0, finishes in seconds, catches contract drift.
Deterministic re-runs
Re-fire any run with the same SHA, env, and persona snapshots - months later - and get a comparable result.
Observability built-in
Token cost, sandbox seconds, quality score and step timeline are recorded on every run. No exporters, no glue code.
Programmable
Define workflows from your editor.
Anything the canvas can build, the SDK can build faster. Workflows are just typed TypeScript - review them, diff them, ship them with your code.
workflows/ship-the-fix.ts
// Define a workflow programmatically
import { createWorkflow, step, loop } from "@codecourier/sdk";
export const ship = createWorkflow({
name: "ship-the-fix",
trigger: { recurring: "weekly" },
steps: [
step("prompter", { persona: "prm_42" }),
loop({ max: 3 }, [
step("designer", { model: "claude-opus-4-6" }),
step("checker", { model: "claude-sonnet-4-6" }),
]),
step("evaluator", { threshold: 80 }),
step("open_pr"),
],
});
await ship.publish(); // → v13 liveA five-step pipeline with a designer-checker loop, an evaluator gate and a weekly trigger - defined in a dozen lines.
Playbooks
Three pipelines worth stealing.
Migrations at scale
A six-sprint chain that scaffolds, ports, tests and cleans up - one PR per sprint, each reviewable in isolation.
Read the playbookNightly maintenance
A weekly recurring task that audits dependencies, sweeps dead code and drifts docs back into shape - silent unless something needs you.
Read the playbookMulti-repo refactors
Parallel branches across a frontend, a backend and a shared package. A judge step picks the strongest implementation before any PR opens.
Read the playbookWorkflow Builder is the first thing my staff engineers protected, not avoided. They write workflows the way they write libraries - and now the boring half of the roadmap ships itself.
MV
Mathieu Voss
VP Engineering · Northwind Systems
FAQ
Engineering lead questions.
Can I version-control my workflows?
Yes - every workflow is a typed manifest that lives in your repository. Pull requests can change a workflow the same way they change application code, with full history, blame and review. The platform also records every published revision so you can roll back without touching Git if a recent change misbehaves.
How is this different from GitHub Actions or a CI pipeline?
Actions runs containers; Workflow Builder runs agents. Each step is a typed AI persona with a model, a sandbox, a skill set and a learnings store, not a shell script. Steps emit verdicts and quality scores that the orchestrator uses to branch, loop and gate - behaviour you’d otherwise hand-write in YAML for weeks.
Can workflows talk to internal services?
Yes. Workflows run inside isolated E2B sandboxes that can reach private endpoints via your own networking config. Webhooks and the SDK let workflows kick off external systems, and the API lets external systems kick off workflows - both directions are first-class.
What’s the rollback story when a workflow change goes wrong?
Pick the previous version in the workflow editor and click revert. The platform creates a new published revision pointing at the old definition, so in-flight runs finish on their original version and new runs use the rollback. Every run record stores the exact version it executed under for audit.
How are secrets managed?
Secrets live in project-scoped vaults and are injected into the sandbox at step start. The orchestrator never logs secret values, sandboxes are torn down at the end of each run, and audit trails show which step read which secret without ever exposing the value itself.
Free for 14 days · no credit card
Hire your first AI engineer.
Ship by lunchtime.
5 minutes to onboard. First PR within an hour. Cancel anytime.