Skip to content

Arazzo Engine – Architecture

This page explains the core concepts and how the Arazzo Engine is structured.

High-Level View

graph TD
    A[Workflow Definition<br>(Arazzo YAML/JSON)] --> B[Loader & Parser]
    B --> C[Execution Core]
    C --> D[Tooling Layer]
    D --> E[CLI / Python API]
    C --> F[Error Handling & Recovery]
  • Workflow Definition — An Arazzo-compliant YAML/JSON describing the sequence of API calls.
  • Loader & Parser — Validates and parses the definition into an internal representation.
  • Execution Core — Executes steps in sequence or in parallel, handles parameters and state.
  • Tooling Layer — Authentication, conditional logic, data transformation.
  • CLI / Python API — End-user interfaces (e.g., arazzo-runner).
  • Error Handling & Recovery — Handles API failures, retries, and logging.

Execution Flow

  1. Load Workflow — From file path or URL.
  2. Validate — (Planned) Conformance to Arazzo spec.
  3. Initialize Context — Injects credentials, variables, and runtime config.
  4. Execute Steps — API calls, conditional branches, loops.
  5. Handle Errors — Retry logic, fallback paths.
  6. Produce Output — Structured results for logging, downstream automation, or human review.

Where the Runner Fits

The Arazzo Runner is the primary interface to the Execution Core today. It is distributed as:

  • A CLI tool for running workflows directly
  • A Python library for embedding execution into applications

Future tooling will plug into the same Execution Core.