ForjioHuudisIdentityPlugipayPaymentsCatentioAgentsStorlaunchE-commerceFulkrumaFulfilmentRiplloMarketingLinkSnapShort URLsPawpadoGPU streaming
Catentio Docs
⌘K

Workflows

A workflow is the blueprint a project runs against: an ordered graph of phases, each phase a set of steps — agent runs, deterministic actions, and human gates — with dependency edges, per-step tool/skill bindings, and a declared output schema per step.

Templates live in the database, not in a repo file. They're versioned, collectable, taggable, and fully manageable from the portal and the REST API.

The catalog

Dashboard → Templates lists every active template: name, slug, latest version, collection, tags, and phase count. Ten built-ins ship seeded:

content, micro-saas, blog-post, sticker-pack, landing-page, content-slideshow, childrens-book, motion-graphics, worksheet, digital-planner

Built-ins are seeded from the runtime's code registry on startup (idempotently) and are DB rows like everything else from then on.

Anatomy of a spec

A workflow spec declares, per phase:

  • slug + position + depends_on — the phase DAG.
  • Steps (subtasks), each with:
    • kind — agent (a Claude run), action (a deterministic runtime action), or gate (a checkpoint, human gates shipping first — see Gates & approvals).
    • role — producer, reviewer, tester, assembler, gatekeeper, or utility. The role decides what input the runner threads in and whether the step's output is promoted to the phase's artifact.
    • tools / skills bindings — required for agent steps; see Step bindings.
    • output_schema — the schema slug the step's output must validate against.
    • Optional consumes_artifacts, reviews, retry-limit overrides, parallelism settings, and a per-step cost budget.

Versioning

Template versions are immutable. Projects pin (workflow_slug, workflow_version) when they expand, and the pin never changes — so a spec edit can never silently rewrite a running project's plan.

  • Editing a workflow's spec mints a new version (max + 1).
  • Editing metadata (collection, tags, description) updates the latest version in place — metadata isn't part of the pinned contract.
  • The version history is on the workflow's detail page and at GET /v1/workflows/{slug}/versions.

Authoring in the portal

Dashboard → Templates → New template opens the authoring sheet. Like every create surface in the portal it has two tabs:

  • Agentic — describe the pipeline in plain language; the assistant drafts the full spec (phases, steps, roles, bindings, schemas) against the real validator schema, and you review before applying.
  • Manual — edit the spec directly.

The Edit button on a workflow's detail page opens the same sheet against the existing spec — remember that applying a spec change creates the next version.

Every write is validated server-side before any row is created: structural checks (phase/step graph, role constraints) plus binding resolution (every declared tool must exist in the tool registry, every skill must be a loadable active skill, and every agent step needs at least one of either).

Collections and tags

Templates carry an optional collection (the project-create picker groups by it) and free-form tags. Both are filterable on the list endpoint (?collection=, ?tag=).

Archiving

Archive on the detail page (or DELETE /v1/workflows/{slug}) soft-deletes all versions of the slug:

  • The template disappears from the default catalog list.
  • New projects can no longer use it (creation fails with 400).
  • Existing projects pinned to any version keep resolving — a pin outlives the archive.

There is no hard delete; the version history is the audit trail.

Via the API and SDK

The full CRUD surface is documented at API → Templates. The SDKs expose templates.list() only; everything else (detail, versions, create, new-version PATCH, archive) is via the REST API.

Next