AXL Workflows

Build multi-step, durable, AI-powered processes - research-then-notify, triage-and-route, draft-and-refine, fan-out-and-merge - as a graph of nodes you author in a small language called AXG (AXL Graph). The engine runs each workflow durably: it survives restarts, coordinates across many server instances, and executes side-effecting steps exactly once.

You write a .axg file, submit it over HTTP (or the axl CLI), and poll or stream its progress.

axg 1
workflow hello {
  input name
  greet = agent greeter:
    "Write a one-line friendly greeting for {{ input.name }}."
  greet -> return {
    greeting: greet.response
  }
}

That's a complete, runnable workflow: it takes a name, asks an agent to greet them, and returns the greeting.

Where to go

Runnable examples

Every example in examples/ is a complete .axg file that compiles (a test enforces it). Start with hello.axg, then triage_branch.axg, refine_loop.axg, parallel_join.axg, and the rest.

The mental model

• A workflow is a graph of nodes. Each node does one thing - call an agent, branch, run a tool, loop, fan out, wait, return.
• Edges (a -> b) mean b runs after a. The graph is a DAG (no cycles); the engine runs nodes as soon as their dependencies are done, in parallel where it can.
• Nodes pass data by reference: {{ input.x }} reads the run input, {{ research.response }} reads an upstream node's output. References are checked at submit time, so typos fail fast.
• A workflow ends when a return node runs; its body becomes the run's output.
• Everything is durable: submit returns a run_id, and the engine drives the run to completion in the background, surviving restarts.

Next