Phase 2: The Upgrade Orchestrator
Classifying upgrades is only the beginning. The Upgrade Orchestrator turns this classification into action by coordinating five specialized agents that blend AI reasoning with deterministic execution. The orchestrator follows a structured workflow, triggering agents sequentially based on results while maintaining context and data flow across steps. The diagram below shows the orchestrated flow between agents:
Figure 3. Flow of the Upgrade Process
The orchestrator follows a multi-agent supervisor-with-tools model. It operates as a ReAct (Reasoning and Acting) agent with access to specialized tools, each corresponding to an agent with focused capabilities:
Repository Analysis Agent: Maps the codebase and identifies relationships between Dockerfiles, Helm charts, scripts, and configuration files.
Helm Agent: Updates Kubernetes deployment configurations within strict boundaries that preserve critical infrastructure.
Script and Config Agent: Manages auxiliary files that make blockchain nodes operational, working both proactively and reactively to resolve deployment issues.
Docker Agent: Manages the build process, iteratively debugs failures, and oversees infrastructure operations in GitHub Actions.
Deploy Agent: Performs progressive deployments to testnets and then mainnet, validates sync status, analyzes logs, and delegates fixes when needed.
The orchestrator uses pattern matching and LLM analysis to map relationships between Dockerfiles, build scripts, Helm charts, and configuration files across each repository. These mappings remain accessible to all agents through a shared in-memory context store, ensuring that repository details identified early in the process are preserved as the orchestrator’s context grows. Future iterations will embed repository data and enable agents to semantically search codebases for more intelligent change handling.
The Docker Agent is designed for iterative problem-solving at scale. Building blockchain nodes requires compiling complex software with many dependencies, where even minor version changes can cause failures.
Figure 4. Build Execution and Debugging Flow of the Docker Agent
The Docker Agent operates in three phases:
Update Phase: Updates Dockerfiles with new version details, preserving structure while applying required upgrade changes.
Build and Debug Loop: Runs builds through GitHub Actions and monitors progress. On failure, it analyzes error patterns to identify common issues, such as missing dependencies or incompatible libraries, and generates targeted fixes.
Iteration Management: Repeats this cycle until the build succeeds or a set attempt limit is reached, gathering more insight into the upgrade’s requirements with each iteration.
For example, when a blockchain upgrades from OpenSSL 1.1 to 3.0, the agent may update the base image from Ubuntu 20.04 to 22.04 to ensure compatibility, then rebuild and validate the fix.
Finally, the Deploy Agent applies a philosophy of careful, validated rollouts. Deployments occur first in sandbox testnet canary environments, enabling easier recovery and minimizing impact on downstream services.
Validation includes monitoring node status endpoints, tracking block height progression, verifying peer connections and consensus participation, and detecting configuration issues for remediation. When nodes fail to sync despite successful builds, the agent recognizes patterns and remediates by updating configuration flags, adjusting peer settings, or modifying startup sequences.