AlgorithmShift

Foundation

Workflow builder
turn agents into recipes.

A workflow is a reusable composition of agents. Ship-a-page, add an integration, roll out a schema change — pick a template, adjust, save, and trigger from anywhere.
TemplatesIdempotentScheduled or triggeredVersioned
Book a demoSee the agents
workflow template — ship-a-pageyaml
id: ship-a-page
label: Ship a page
description: |
  Takes a route description and produces a live page
  with schema, components, tests, and a security pass.

steps:
  - id: spec
    agent: requirements
    approval: human

  - id: schema
    agent: schema
    depends_on: [spec]

  - id: design
    agent: design
    depends_on: [spec]

  - id: page
    agent: pages
    depends_on: [schema, design]

  - id: tests
    agent: tests
    depends_on: [page]

  - id: security
    agent: security
    depends_on: [page]
    approval: human

The problem

Every team does the same five delivery routines over and over — ship-a-page, add-an-integration, roll-out-a-schema-change. Without composition, those routines live in a runbook and decay. A workflow is the runbook as data: versioned, testable, and callable from a button click or a cron.
[01]

Pipelines are YAML, not code.

Each workflow is an ordered list of agent steps with dependencies. The runner executes the DAG — parallelising independent steps, waiting on blocked ones, pausing on human approvals.
  • Step `depends_on` declares the graph
  • Independent steps run in parallel automatically
  • Approvals are first-class — they block the DAG cleanly
workflow.yamlyaml
steps:
  - id: design
    agent: design
    depends_on: [spec]

  - id: schema
    agent: schema
    depends_on: [spec]   # runs in parallel with design

  - id: pages
    agent: pages
    depends_on: [design, schema]
[02]

A library of templates, out of the box.

Start from one of the built-in patterns your team probably already runs. Clone, tweak, save as your own — no empty-state anxiety.
acme / workflows / templates
Ship a pageSpec → schema + design → page → tests + security5 steps
Add integrationDraft spec → integration agent → pages update → tests4 steps
Schema changeAlter entities → migration → regenerate affected pages4 steps
Release cutClose iteration → merge master → draft notes → tag → export6 steps
Bug triageDebug runtime → propose fix → reviewer approval3 steps
[03]

Triggers: on-demand, event, schedule, webhook.

Run a workflow when a PM clicks Run, when a requirement is approved, every Monday at 9:00, or when an external system fires a webhook. Every trigger produces a timeline you can audit.
  • Event: approved requirement → ship-a-page (automatic)
  • Schedule: weekly release cut (cron syntax)
  • Webhook: CI green → run integration tests
  • Audit trail captures who / what triggered every run
triggers.yamlyaml
triggers:
  - on_demand                    # user clicks Run
  - on_event:
      source: requirement
      event: approved
  - on_schedule:
      cron: "0 9 * * mon"        # Mondays 09:00 UTC
  - on_webhook:
      path: /hooks/deploy-ready
      secret: env(HOOK_SECRET)
[04]

Idempotent by construction.

The runner claims each step before it executes and records the result atomically when it finishes. Re-running picks up where a crash left off — no duplicate tasks, no half-applied state.
  • Step-level idempotency via orchestration keys
  • Retry picks up only the failed frontier
  • Human-approved steps persist their approval across retries

Run timeline

  1. 09:03specapplied
  2. 09:04schemaapplied
  3. 09:05designapplied
  4. 09:07pagesfailed
  5. 09:12pages (retry)applied
  6. 09:14testsapplied

Retry ran only the failed step — upstream results carried forward.

[05]

Versioned + rollback-able.

Workflows are versioned on publish. Run records capture which version executed. Rolling back to a prior version is one click — useful when a workflow edit introduces a regression mid-week.
  • Semver-style versioning with changelog
  • Run history tags the version used
  • Rollback is a workflow replace, not a state change
workflow revisionslog
ship-a-page  v3.2.0  yesterday   alice@acme   added security step before release
ship-a-page  v3.1.0  last week    bob@acme     swap page tier haiku → sonnet
ship-a-page  v3.0.0  last month   bob@acme     fan schema + design in parallel
[06]

Nested + reusable.

A workflow can call another. Compose once for the routine; reuse as a building block inside larger delivery patterns. No copy-paste sprawl.
  • Reference other workflows by slug
  • Pass inputs, receive outputs, type-checked at publish time
  • Circular dependencies rejected at validation
ship-a-feature.yamlyaml
steps:
  - id: story
    agent: requirements
    approval: human

  - id: pages
    workflow: ship-a-page      # ← call another workflow
    for_each: story.pages

  - id: release-notes
    agent: release-notes
    depends_on: [pages]

5

Built-in templates

clone + tweak

4

Trigger types

demand · event · schedule · webhook

Versioned

Rollback in one click

Nestable

Workflows can call workflows

FAQ

Common questions

Are workflows versioned?
Yes. Every publish bumps a semver-style version, with a changelog generated from the YAML diff. Run records capture the version that executed, so you can always replay.
Can I fork someone else's template?
Yes — clone any built-in or workspace template into your own space, edit freely, republish. Attribution is preserved in the lineage history.
What triggers a workflow?
Four options: on-demand (user click), event (internal platform event like `requirement.approved`), schedule (cron), or webhook (external system). Mix as many as you need on one workflow.
Can a workflow modify itself?
No — workflows are declarative. For dynamic behavior, an agent step can emit a `next_agent` field the orchestrator reads, giving you branching without self-modifying workflows.

See the full platform in action.

Bring a real requirement. Watch it become a running app you can ship.

Start freeBook a demo