Quickstart

A workflow is a list of actions in a single file. Each action runs one component, the actions pass their results to the actions that follow them, and the engine executes everything in order.

This page builds a small working workflow so the pieces are concrete before the deeper guides. You do not need to be a developer to follow it. If you can edit a text file, you can write a workflow.

Your first workflow

Save this as hello.yml. It asks a model for three facts about a topic, feeds those facts into a second model call that writes a short post, and saves the result to a file. Two model calls, chained by name.

id: example/topic-to-post
name: Topic to post

inputs:
  - name: topic
    type: string
    required: true

actions:
  - name: facts
    component: llm:generate
    vars:
      provider: openai
      model: gpt-5
      prompt: 'List three surprising facts about {{ topic }}.'

  - name: post
    component: llm:generate
    vars:
      provider: openai
      model: gpt-5
      prompt: "Turn these facts into one short, upbeat post.\n\n{{ facts.content }}"

  - name: saved
    component: storage:local:file:write
    vars:
      path: ./post.txt
      content: '{{ post.content }}'

outputs:
  post: '{{ post.content }}'

The second action reads {{ facts.content }}, the text the first one produced. That single reference is the chain. The model that writes the post never sees the topic directly, it works from what the first model returned. Wiring actions this way, a model call feeding an API call feeding a file write, is how every automation here is built.

Run it

Run the file from the command-line app.

awee run hello.yml --topic "the universe"

The same file also runs unchanged over the REST API and from the web app, where its inputs become a form. You write a workflow once and reach it from all three.

The four core ideas

Everything in the rest of these docs builds on what this workflow already does, plus one rule it does not yet need.

• Actions. The actions list is the body of the workflow. Each action has a name and a component, and they run top to bottom. The list is never called steps.
• Wiring. An action reads an earlier action's result with a {{ name.field }} expression. This is the only glue between actions, and it is how data flows through the workflow.
• Outputs. The outputs block names what the workflow returns to whoever ran it, built from the same expressions.
• Absence. A value that is not there is fine to read and never fine to decide on. {{ row.flag | not }} over a column that is missing or null fails the step rather than guessing, and {{ row.flag | default:false | not }} is how you say what absence means.

That last one is the rule that costs the most to learn the hard way, so it is worth reading the templating language for it before writing anything that branches.

Where to go next

Read the guides in order for a full tour, or jump to what you need.

• Workflow anatomy lays out every part of a workflow and every field an action carries.
• Templating language covers the {{ }} expressions that wire actions together.
• Control flow covers conditions, the two forms of iteration, and how to choose between them.
• Inference explains calling models, tools, and forming structured outputs.
• The component reference is the full menu of components, each with its options and its outputs.