The Engine That Runs 10 Million Agents a Month: Inside the AACFlow DAG Executor

The result is not a "script" in the traditional sense. It's a compiled plan that the executor can pause, resume, retry individual nodes on, and observe in fine-grained detail.

State Persistence: Never Lose Progress

One of the hardest problems in workflow automation is: what happens when something fails mid-execution?

In most systems, the answer is: "Start over." This is unacceptable for production workloads. Imagine a workflow that's been running for 15 minutes, has called 8 different APIs, and then hits a rate limit on the 9th call. Starting over means: re-running all 8 previous calls, potentially creating duplicate records, re-consuming tokens, and wasting time.

AACFlow solves this with state snapshots. After every node execution, the engine persists:

• Which nodes have completed (with their outputs)
• Which nodes are in progress
• Which nodes are pending
• The exact state of every variable and context value

If a node fails, the engine can retry just that node — or pause the entire execution and wait for manual intervention. When resumed, it picks up exactly where it left off. No re-execution of completed work. No duplicate side effects.

Idempotency: The Safety Net

Retry logic is meaningless without idempotency. If a node that creates a record in a CRM fails after the record was created but before the response was received, retrying it would create a duplicate.

We solve this with idempotency keys. Every node execution carries a unique key. External API calls include that key in a header. The external system can use it to deduplicate. And our internal state tracking ensures that even if the external system doesn't support idempotency natively, we never re-execute a node that already completed.

Parallel Execution: 3-5x Faster

The compiler identifies branches that have no mutual dependencies and executes them simultaneously. A research workflow that needs to query 5 different APIs doesn't wait for each one sequentially — all 5 run in parallel, and the results are merged when they all complete.

This isn't just an optimization. It's a fundamental design choice. In a world where API calls take 500ms-2s each, parallelism is the difference between a workflow that runs in 2 seconds and one that runs in 10.

Our engine uses a Promise-based concurrency model with configurable limits per workspace. No thread pools. No complex scheduling. Just clean, observable parallelism.

Retry Logic With Backoff

Transient failures are a fact of life: rate limits, network timeouts, temporary service unavailability. The executor handles them with:

• Exponential backoff — each retry waits longer than the last
• Jitter — random variance to prevent thundering herd on retry storms
• Max retry count — configurable per node
• Retryable vs non-retryable errors — a 400 Bad Request shouldn't be retried; a 429 Too Many Requests should

Combine this with state persistence, and you get a system where transient failures are invisible to the user. The workflow either succeeds or surfaces a clear, actionable error.

The Visual Editor: Build Without Code

All of this complexity is accessible through a visual editor built on ReactFlow. Users drag blocks onto a canvas, connect them with edges, and configure parameters through side panels. The editor handles:

• Real-time validation — shows you if a connection is invalid before you even try to run
• Auto-layout — keeps the graph readable as it grows
• Zoom and pan — handles graphs with hundreds of nodes
• Undo/redo — full history, not just "oops"
• Search — find any node by name or type

The editor doesn't just look pretty. It's a professional tool for building complex, production-grade automation. Think of it as an IDE for AI agents.

What We Learned Building It

ReactFlow is powerful but finicky. We spent months wrestling with performance on large graphs, custom edge routing, and touch support. There's no alternative that handles our level of customization, but it requires deep investment.

DAG compilation is theoretically simple but practically hard. Edge cases abound: what if a node depends on itself through a cycle? What if a node has no inputs? What if two parallel branches write to the same variable? Every edge case is a potential production bug.

State persistence must be designed in from day one. Retrofitting state management onto an existing executor is nearly impossible. We built it into the first version and it has paid dividends ever since.

What's Next

We're working on:

• Streaming node outputs — right now you see results when a node completes; we want you to see partial results as they're generated
• Conditional branching in the visual editor — if/else logic directly on the canvas
• Sub-workflows — reusable graph fragments that can be embedded in larger workflows
• Performance profiling — per-node timing and cost breakdowns

The engine that runs your agents is the most important piece of infrastructure we build. It's invisible when it works — and that's exactly how it should be.

— Alexandr Chibilyaev