Skip to main content
HUMΛN

Workflows

A HUMΛN workflow is a callable capability. It declares who may start it, which muscles or connectors run each step, where a human must decide, and what provenance the run leaves behind. Companion, HumanOS, and the API invoke the same contract.

This page is the create-path concept. The workflow builder guide shows the canvas. The create-first-workflow pattern is the beginner recipe.

What you are composing

A humanos.workflow.v1 manifest names:

  1. Triggers — manual, event, schedule, or API (brandvoice/draft.requested is one example).
  2. Steps — muscles, capabilities, or human approval gates. Steps route on capability, not a hardcoded agent id.
  3. Workers — named implementations you may pin in Builder. HumanOS can swap an executor that satisfies the same contract.
  4. Policy — confidence floors, approval required, spend envelopes.

The useful contrast: a script that calls three APIs in a row is not a HUMΛN workflow. A workflow is the script plus identity, delegation, gates, and a signed record.

Where you create one

Surface What it does
Companion builder Visual canvas — describe, drag steps, test, publish. Home is Companion, not Command Plane.
POST /v1/builder/workflows Create a draft from a manifest
POST /v1/builder/workflows/from-companion Hand a Companion intent into Builder
POST /v1/builder/workflows/:id/publish Publish after the readiness checklist

Canon: kb/163 (orchestration), kb/136 (builder).

Human gates are first-class

When a step is human_approval, the run pauses. The reviewer sees the same artifact the agent produced — not a bare notification. Brand Voice uses this twice: editorial, then QA, before content.write may open a pull request. That is Principle Five in the product, not a slide.

Work with workflows