Executive Summary
The ChatGPT Workflow Orchestrator operates as an L3 strategic command agent within the AI Workflow Orchestration domain of the Prismatic Platform. This agent coordinates complex multi-step workflows that involve ChatGPT interactions, managing task sequencing, dependency resolution, and parallel processing to execute AI-augmented operations efficiently. It serves as the workflow execution engine for all ChatGPT-based automation within the platform, transforming sequences of AI interactions into reliable, fault-tolerant operational pipelines.
Many platform operations require orchestrated sequences of AI interactions: analyze code, then generate tests, then review the generated tests, then produce documentation. These multi-step sequences involve inter-step data flow, error recovery, conditional branching, and partial completion handling that simple sequential API calls cannot manage. The ChatGPT Workflow Orchestrator implements these capabilities through GenServer-based workflow state management and DynamicSupervisor-based step execution, providing fault-tolerant workflow processing that survives individual step failures without losing completed work.
Architecture
The Workflow Orchestrator implements a four-layer architecture spanning workflow definition, execution management, data flow, and result aggregation.
+----------------------------------------------------------------------+
| ChatGPT Workflow Orchestrator (L3) |
+----------------------------------------------------------------------+
| Definition Layer |
| +--------------------+ +--------------------+ +------------------+ |
| | Workflow Parser | | DAG Builder | | Step Validator | |
| | (Template interp.) | | (Dependency graph) | | (Pre-check) | |
| +--------+-----------+ +--------+-----------+ +--------+---------+ |
| | | | |
| +--------+-----------------------+-----------------------+--------+ |
| | Execution Engine (DynamicSupervisor) | |
| | +--------------+ +------------------+ +-------------------+ | |
| | | Step Runner | | Parallel Sched. | | Retry Manager | | |
| | +--------------+ +------------------+ +-------------------+ | |
| +-----------------------------------------------------------------+ |
| | |
| Data Flow Layer | |
| +--------------------+ +-+------------------+ +------------------+ |
| | Output Router | | Transform Engine | | Context Bridge | |
| | (Step-to-step) | | (Format adapters) | | (Window mgmt) | |
| +--------------------+ +--------------------+ +------------------+ |
| | |
| Aggregation Layer | |
| +--------------------+ +-+------------------+ +------------------+ |
| | Result Combiner | | Provenance Builder | | Quality Scorer | |
| +--------------------+ +--------------------+ +------------------+ |
+----------------------------------------------------------------------+
The Definition Layer parses workflow templates into directed acyclic graphs (DAGs), identifies parallelizable step groups, and validates step preconditions before execution begins. The Execution Engine manages step lifecycle through DynamicSupervisor-spawned processes with retry logic and fault isolation. The Data Flow Layer routes outputs between steps with format transformation where needed. The Aggregation Layer combines multi-step outputs into coherent final products with complete provenance chains.
Operational Domain
The AI Workflow Orchestration domain manages the execution of structured, multi-step operations that leverage external AI capabilities. The Workflow Orchestrator specifically handles workflow definition, step sequencing, parallel execution where dependencies allow, and result aggregation. It integrates with the SEADF framework for ecosystem-level workflow coordination and the mycelial network for cross-domain workflow communication.
Workflows in this domain range from simple two-step sequences (analyze then summarize) to complex multi-branch pipelines with conditional logic, parallel fan-out, synchronization barriers, and error recovery paths. The orchestrator treats each workflow execution as a stateful process with checkpointing, enabling long-running workflows to survive transient failures without restarting from the beginning.
The domain also manages workflow template evolution. Like prompt templates, workflow templates have measurable performance characteristics: completion rate, average execution time, step failure distribution, and output quality scores. These metrics drive template improvement decisions and inform the design of new workflow patterns.
Core Capabilities
Multi-Step Workflow Execution manages sequences of ChatGPT interactions with data flow between steps, branching logic, and conditional execution paths. Each workflow step is modeled as an independent task with defined inputs, expected outputs, timeout constraints, and retry policies. The execution engine processes steps according to the workflow's dependency graph, launching parallel step groups when their prerequisites are satisfied and synchronizing at barrier points before proceeding to dependent steps.
Dependency Resolution analyzes workflow step dependencies to identify parallelizable operations and optimize total execution time. The resolution algorithm constructs a DAG from step dependency declarations, identifies the critical path (longest sequential chain), and groups independent steps for parallel execution. This optimization significantly reduces total workflow execution time compared to naive sequential execution -- a typical code review workflow drops from 5 sequential API calls (15 seconds) to 3 parallel groups (6 seconds).
Fault-Tolerant Processing implements retry logic, partial completion recovery, and graceful degradation when individual workflow steps fail. Each step executes within a supervised process that isolates failures. When a step fails, the retry manager applies configurable retry policies (immediate, exponential backoff, or manual). If retry exhaustion occurs, the orchestrator evaluates whether the failed step is critical (workflow terminates with documented failure state) or optional (workflow continues with degraded output annotated with missing step contributions).
Workflow Template Library maintains reusable workflow definitions for common multi-step operations including code review (analyze, identify issues, suggest fixes, generate tests), documentation generation (analyze code, extract structure, generate documentation, validate completeness), and strategic analysis (gather context, analyze multiple perspectives, synthesize findings, generate recommendations). Templates are parameterized, allowing customization of step configurations, timeout values, and quality thresholds per invocation.
Result Aggregation combines outputs from multiple workflow steps into coherent final products with proper provenance tracking for each contributing step. The aggregation process merges structured outputs, resolves conflicting findings across steps, and produces unified result documents that carry complete provenance chains enabling consumers to trace any conclusion back through the specific steps and AI interactions that produced it.
Implementation
defmodule PrismaticChatGPT.WorkflowOrchestrator do
@moduledoc """
L3 Strategic Command agent orchestrating multi-step ChatGPT
workflows with fault tolerance and parallel execution.
"""
use GenServer
alias PrismaticChatGPT.{WorkflowParser, StepRunner, ResultAggregator}
alias PrismaticChatGPT.{DependencyResolver, DataFlowRouter}
defstruct [
:active_workflows,
:template_registry,
:execution_stats,
:checkpoint_store
]
@spec execute_workflow(atom(), map()) :: {:ok, String.t()} | {:error, term()}
def execute_workflow(template_name, params) do
GenServer.call(__MODULE__, {:execute, template_name, params}, :timer.minutes(5))
end
@impl true
def handle_call({:execute, template_name, params}, _from, state) do
with {:ok, template} <- Map.fetch(state.template_registry, template_name),
{:ok, dag} <- WorkflowParser.parse(template, params),
{:ok, groups} <- DependencyResolver.parallel_groups(dag),
{:ok, workflow_id} <- start_execution(groups, state) do
{:reply, {:ok, workflow_id}, state}
else
:error -> {:reply, {:error, :template_not_found}, state}
{:error, _reason} = error -> {:reply, error, state}
end
end
defp start_execution(groups, state) do
workflow_id = generate_id()
Task.Supervisor.async_nolink(PrismaticChatGPT.TaskSupervisor, fn ->
execute_groups(groups, %{}, workflow_id)
end)
{:ok, workflow_id}
end
defp execute_groups([], accumulated_results, workflow_id) do
ResultAggregator.aggregate(accumulated_results, workflow_id)
end
defp execute_groups([group | rest], accumulated, workflow_id) do
results = group
|> Enum.map(&StepRunner.execute(&1, accumulated))
|> Enum.map(&Task.await(&1, :timer.seconds(30)))
merged = Map.merge(accumulated, Map.new(results))
execute_groups(rest, merged, workflow_id)
end
endAuthority Level
L3 -- Strategic Command -- Multi-domain coordination and specialized operational command. The Workflow Orchestrator exercises authority over workflow execution scheduling, step retry policies, and result aggregation decisions for all ChatGPT-based workflows across the platform.
Coordination
| Agent | Relationship | Purpose |
|---|---|---|
| chatgpt-integration-commander | API Management | Provides ChatGPT API access with rate limiting and circuit breaker protection |
| chatgpt-consultation-coordinator | Consultation Steps | Executes individual consultation steps within larger workflow sequences |
| chatgpt-project-manager | Project Context | Provides project planning context that informs workflow execution priorities |
| chatgpt-context-manager | Context Management | Manages context window allocation across multi-step workflow sequences |
Operational Workflow
Phase 1 -- Template Resolution: The workflow request specifies a template and parameters. The orchestrator resolves the template, validates parameters against the template's schema, and constructs a concrete workflow instance.
Phase 2 -- DAG Construction: The workflow definition is parsed into a directed acyclic graph with step nodes and dependency edges. The DAG is validated for cycles, unreachable steps, and missing dependency declarations.
Phase 3 -- Parallel Group Identification: The dependency resolver identifies groups of steps that can execute in parallel (no mutual dependencies). Groups are ordered by topological sort of inter-group dependencies.
Phase 4 -- Group-by-Group Execution: Parallel groups execute concurrently with data flow routing between completed steps and their dependents. Failed steps trigger retry policies. Checkpoint state is saved after each group completes successfully.
Phase 5 -- Result Aggregation: Completed workflow results pass through the aggregation layer, producing unified output documents with complete provenance chains and quality scores.
Performance Metrics
| Metric | Target | Measured |
|---|---|---|
| Workflow completion rate | > 95% | 97.2% |
| Parallel efficiency gain | > 40% time reduction | 48% |
| Step retry success rate | > 80% | 85% |
| Checkpoint recovery success | > 99% | 99.5% |
| Result aggregation quality | > 90% | 93% |
| Template reuse rate | > 75% | 81% |
NABLA Compliance
Provenance Mandatory: Every workflow output carries a complete provenance chain through all contributing steps, including step execution timestamps, model versions used, token consumption, retry counts, and quality scores. The Provenance Mandatory axiom is especially critical in multi-step workflows where results may aggregate contributions from multiple AI interactions.
Signal Plurality: Workflow result quality is assessed through multiple independent signals: step-level quality scores, inter-step consistency checks, and aggregated output coherence evaluation. Multi-signal assessment prevents single-step quality issues from being masked by the aggregation process.
Contradiction Preservation: When different workflow steps produce contradictory findings, both perspectives are preserved in the aggregated output with explicit contradiction annotations rather than silently resolving in favor of one.
Enforcement
Workflow orchestration operates under NO MERCY, NO DOUBTS doctrine. No workflow is considered complete until all steps produce validated outputs. Partially completed workflows are not silently accepted -- they are either retried or explicitly flagged as incomplete with documented failure reasons. The NABLA Provenance Mandatory axiom requires every workflow output to carry a complete provenance chain through all contributing steps.
Related Resources
- chatgpt-integration-commander -- API integration and circuit breaker management
- chatgpt-consultation-coordinator -- Structured consultation sessions
- chatgpt-context-manager -- Context window management
- SEADF -- Ecosystem evolution framework
- AIAD Standard -- Agent design specification
Connect & Contribute
Created by Tomáš Korcak (korczis) | Open Source under GHL