Execution Plan

The task graph is the core data structure of an execution plan, representing tasks as nodes and their dependencies as directed edges. This forms a Directed Acyclic Graph (DAG) that the orchestrator traverses.

• Nodes: Represent individual activities (e.g., 'Call API', 'Run Script', 'Wait for Event').
• Edges: Define execution order and data flow dependencies (e.g., Task B cannot start until Task A succeeds).
• Properties: The graph is annotated with resource requirements, timeout settings, and failure-handling policies for each node.

Execution state is the mutable, in-memory representation of a running plan instance. It is what the orchestrator persistently manages and updates throughout the lifecycle.

• Variables & Payloads: Stores input parameters, intermediate results passed between tasks, and final outputs.
• Control Pointer: Tracks the current position in the task graph (e.g., which tasks are PENDING, RUNNING, SUCCEEDED, or FAILED).
• Checkpoints: For long-running plans, state is periodically saved to durable storage via checkpointing to enable recovery from failures, a feature central to systems like Temporal workflows.

This component determines when and where each task in the graph is executed. It translates the abstract plan into concrete runtime actions.

• Scheduler: Evaluates task dependencies and readiness. A task is dispatched only when all its upstream dependencies are satisfied.
• Dispatcher: Assigns ready tasks to available execution resources (e.g., a worker pool, a serverless function, a specific agent).
• Concurrency Control: Manages parallel execution of independent tasks and enforces limits on simultaneous tasks to prevent resource exhaustion.

Robust execution plans embed policies for handling errors, ensuring idempotent execution and system resilience.

• Retry Logic: Defines rules for automatic re-execution of failed tasks (e.g., 'max 3 retries with exponential backoff').
• Fallback Paths: Specifies conditional branching to alternative tasks or cleanup procedures upon critical failures.
• Circuit Breakers: Prevents cascading failures by temporarily halting calls to a failing downstream service.
• Compensation: For distributed transactions, the plan may include compensating transactions to rollback partial effects, as defined in the Saga pattern.

These are integrated points for monitoring, logging, and tracing, creating a live audit trail of the plan's execution.

• Event Emission: The plan emits structured events for state transitions (task started/succeeded/failed), decision points, and data milestones.
• Metrics Collection: Tracks performance indicators like task duration, queue time, and error rates.
• Trace Context Propagation: Ensures distributed traces span across all tasks, even if they execute on different workers or agents, enabling end-to-end visibility.

This defines the compute, data, and agent resources required for each task, which may be resolved dynamically at runtime.

• Execution Environment: Specifies the container image, runtime, libraries, or agent capabilities needed.
• Data Access: Defines permissions and connection details for databases, APIs, or file stores.
• Agent Assignment: In multi-agent systems, this may include constraints or affinity rules for routing tasks to specific specialized agents (e.g., 'use the Python-coding agent').
• Resource Limits: Sets bounds on CPU, memory, and execution time for each task.

A Directed Acyclic Graph (DAG) is the most common data structure for modeling a workflow definition, which is then compiled into a concrete execution plan. In a DAG:

• Nodes represent individual tasks or activities.
• Directed edges represent dependencies and data flow.
• The acyclic property ensures tasks cannot depend on themselves, preventing infinite loops. This structure allows the engine to calculate a valid topological order for execution.

A process instance (or workflow instance) is a single, specific execution of a workflow definition. It is the runtime manifestation of an execution plan. Key characteristics include:

• Has its own unique execution ID and lifecycle.
• Maintains isolated state variables and an execution history.
• Can be paused, resumed, or terminated independently. Multiple instances of the same definition can run concurrently with different input data.

State persistence is the mechanism by which a workflow engine durably stores the runtime state of a process instance. This is critical for the reliability of long-running execution plans. It involves:

• Saving variables, the execution pointer, and task outputs to a database.
• Enabling fault tolerance; if the engine crashes, it can recover the instance exactly where it left off.
• Supporting features like checkpointing and deterministic replay for debugging.

Declarative orchestration is an approach where developers specify the what (desired end state and task dependencies) rather than the how (imperative step-by-step code). The engine's scheduler then generates the optimal execution plan. Benefits include:

• Separation of concerns: Business logic is separate from control flow.
• Engine optimization: The scheduler can parallelize independent tasks.
• Resilience: The engine manages retries and state recovery automatically. Contrasts with Workflow-as-Code, which is more imperative.

Deterministic replay is the capability of a workflow engine to exactly recreate the execution of a process instance from its stored event history. This is a foundational feature for reliable execution plans. It enables:

• Accurate recovery after failures, without side effects or data corruption.
• Powerful debugging by stepping through historical executions.
• Verification that code changes produce the same logical outcome. It relies on event sourcing patterns and immutable execution logs.