Skip to main content
Version: Next — Unreleased

Workflows

This page explains the workflow model and the reasoning behind it. It does not give step-by-step instructions — see the How-to Guides and Tutorials for those.

The model​

An AgentForge4j workflow is a declarative document: a set of steps, each with a behaviour that determines what the step does, connected by transitions that determine what runs next. Definitions are data, validated against the published schemas before execution, so a malformed workflow fails fast rather than partway through a run. The shortest such document — the quick-start example's single agent step — looks like this:

quick-start.workflow/workflow.json
{
  "kind": "WORKFLOW",
  "schemaVersion": 1,
  "id": "quick-start",
  "name": "Quick Start",
  "description": "A single agent step that completes immediately — the shortest runnable workflow.",
  "steps": [
    {
      "kind": "STEP",
      "stepId": "greet",
      "name": "Greet",
      "behaviour": {
        "type": "AGENT",
        "agentRef": "quick-start-agent",
        "transition": "AUTO"
      }
    }
  ]
}

Why declarative​

Keeping workflows as validated data — rather than code — means they can be authored, reviewed, versioned, and validated independently of the application that runs them, and the runtime can reason about them (reachability, transitions) ahead of execution.

Vocabulary​

The execution vocabulary is fixed and documented in the reference section. For example, a conditional step uses the BRANCH behaviour, and an LLM step can emit a CREATE_FILE command; these identifiers are checked against the generated reference at build time, so a typo or a removed identifier fails the build.