OpenClaw Run Graph and Critical Path Optimizer for workflow automation

TL;DR

The latest release brings a visual Run Graph and a Critical Path Optimizer that remove guesswork from complex pipelines. The optimizer focuses resources on the longest dependent chain, which cuts end to end time under spiky load. This update also adds group level concurrency, consistent backoff with jitter, and a clean replay path. If you run large programs for workflow automation, you will notice faster finishes and clearer bottleneck detection within the first week. OpenClaw surfaces the graph and the optimizer in every run so teams can act on the path that matters.

What shipped and why now

Marketing operations have moved from simple sequences to rich orchestration. Campaigns blend paid, lifecycle, product triggers, and data transforms. A small delay on a single enrichment can ripple across reporting, experimentation, and delivery. This release addresses that reality by giving teams a precise picture of how their processes actually run and a way to shorten the most expensive chain without constant tuning.

The Run Graph is a visual and programmatic representation of each run as a directed acyclic graph. That means every task is placed relative to its true prerequisites, not just the order it was authored in a playbook. The scheduler then uses that structure to decide what to run now, what to queue, and what to throttle when external APIs push back. The result is less waiting at idle nodes and fewer surprise retries that mask real contention.

For customers on ButterGrow's platform, this feature appears automatically in new runs. You can open any execution and see nodes, edges, and live status. That single view replaces the habit of having five tabs open across logs, queues, and metrics. If you are new to the product, the overview of our AI marketing automation features is a good primer on how orchestration, agents, and data all fit together. See the entry on AI marketing automation features to understand what the product covers today. The graph helps automation workflows stay predictable as programs scale.

How the Run Graph works

The Run Graph converts your playbook into nodes and edges at start time and then updates the map as tasks move through waiting, running, success, or failure states. Under the hood, the scheduler performs a topological pass to find tasks that have no unmet prerequisites, then assigns those to runners based on available capacity and resource policies.

Nodes and edges

Each node represents a single actionable unit. Examples include a CRM enrichment, an attribution merge, a media upload, or a custom script step. Edges represent hard dependencies. If an edge connects Enrichment A to Merge B, then Merge B cannot start until Enrichment A completes successfully. Soft dependencies like advisory checks are rendered as light edges with non blocking semantics so you can still see advisory flow without delaying critical work.

Because every run produces a concrete graph, you can identify bottleneck nodes with clarity. Nodes that fan in from many parents are potential pressure points. Nodes that fan out to many children are potential amplifiers of delay. This is often hard to see from logs alone, which present a timeline instead of a structure.

Topology and concurrency controls

The scheduler uses a ready set built from nodes with all prerequisites satisfied. From there it applies concurrency rules, which you can set on a connector, a group of tasks, or a whole run. This matters when partner APIs enforce per account caps. If an external system allows three in flight uploads, you can set a cap of three and the scheduler will respect that while still moving other branches forward.

You can also define priority groups so that small, latency sensitive branches are not starved by long, throughput heavy branches. The ready set is partitioned by priority and fairness rules trade off latency and cost. Under mixed workloads, this keeps near real time signals like webhooks responsive while batches render in parallel. The visualization shows these choices as color coded lanes so your team can confirm the effect after a deploy.

Critical Path Optimizer

The Critical Path Optimizer computes the longest dependent chain in the graph, often called the critical path. The scheduler then favors nodes along that chain when assigning scarce resources. The effect is similar to project management where shortening the longest chain shortens total duration even if other chains are slower. In practice, teams see lower median and tail latency because fewer resources idle while a single long branch waits.

What the optimizer does

At run start, the optimizer scores nodes by the length and weight of their downstream chains. Weighting factors include expected duration, failure rate, and whether the node touches a quota limited connector. These scores influence dispatch when runners are limited. If a non critical branch would otherwise monopolize capacity, its score drops in favor of the chain that determines finish time.

Teams exploring critical path optimization for marketing pipelines can start with Balanced and adjust after measuring tail latency.

During execution, the optimizer adjusts scores as new information arrives. If a node completes faster than expected, the downstream chain loses weight. If a node retries, its branch temporarily loses priority unless it belongs to the current critical chain. This balance ensures that failures do not starve unrelated work and that successful branches keep advancing.

Scheduling strategies and backoff

The new scheduler supports three strategies you can choose per run. Throughput First advances the most tasks at once subject to concurrency caps. Latency First focuses on finishing a single path quickly. Balanced adapts per minute based on backlog and service level targets. Each strategy respects backoff with jitter to avoid synchronized retries.

Backoff policies now live at the run level. That means you can set consistent retry spacing across heterogeneous tasks with different authors. The policy also decides when to move a task to a dead letter queue. When something moves to a DLQ, the Run Graph keeps the context so you can replay safely without re executing successful parents.

Setup in minutes for existing customers

The feature is enabled for all new workspaces and is opt in for older ones. You can start with defaults and tune later. The steps below show how to enable the new scheduler and visualize impact. This guide shows how to visualize DAG based runs without changing your playbooks. If you are new to ButterGrow, you can get started in minutes and run this on a sample playbook within your first session.

Step 1Enable the Run Graph view

Open any execution and click Run Graph in the header. The view loads the live structure and initializes the critical path overlay. The header shows path length, current ready set, and queued tasks. You can hover to see the exact parent set for any node.

Step 2Set group level concurrency

Select a group like Media Upload or CRM Enrichment and set maximum in flight tasks. Start with the cap your partner docs recommend. This prevents spike failures and improves fairness by keeping capacity for other branches.

Step 3Choose a scheduling strategy

Pick Balanced to start. If a launch requires strict end to end latency, switch to Latency First. For overnight backfills, choose Throughput First. The strategy can change at runtime without restarting the run. The scheduler previews how many nodes will move in the next minute under each option.

Step 4Define retry policy and jitter

Set base backoff and jitter percent at the run level. This stops synchronized retries from spiking traffic on the same second. You can still override at task level for rare cases that need tight control.

Step 5Confirm improvements with metrics

Use the run metrics panel to track duration and queueing. The panel shows median and p95 values, plus a histogram of path lengths and a table of bottleneck nodes. For additional context on replay and failure handling, see our reliable retries and DLQs guide which explains how dead letter queues work with replays.

Performance gains in numbers

To help you estimate impact, the table below shows results from a set of typical customer programs after enabling the optimizer and modest concurrency caps. Your mileage will vary based on partner quotas and branch balance, but these numbers are representative of what we see in production.

Program type	Before median duration	After median duration	Before p95 duration	After p95 duration	Retry rate before	Retry rate after
Enrichment heavy B2B lead flow	26 min	16 min	68 min	39 min	9.4 percent	5.7 percent
Creative feed with media uploads	41 min	24 min	102 min	58 min	11.8 percent	6.1 percent
High volume offer batch	55 min	33 min	134 min	80 min	7.1 percent	4.2 percent

These improvements come from capacity focused on the longest chain and from limits that keep noisy neighbors from starving short branches. The shift is especially visible in tail latency where a single slow branch can drag everything else past the deadline.

How this changes daily work

Teams no longer manage by log scans. Instead they start by opening the Run Graph to see structure and current backpressure. If a node is red and has many parents, they know to seek a connector configuration or a quota increase. If a node is green but has many children, they know to verify that the downstream queues are advancing fast enough.

Faster investigations

A single link from a failing node opens a pre filtered log view for that node and its direct parents. This speeds up the first response loop. Because the graph tracks context, responders can replay just one branch without touching successful work.

Safer approvals and governance

Approvers can see which nodes belong to sensitive connectors in one overlay. That makes it clear when a change affects a regulated system. The audit trail records which strategy ran and which caps were in force so change reviews can match run behavior with policy intent. For readers who want product context, check ButterGrow's platform to see how roles, audit logs, and controls are mapped in the app.

Better planning for experiments

Teams that run tests across channels can isolate experiments into small priority groups. That prevents long running batch branches from starving small tests. It also makes it easier to run minimum viable experiments because the visual shows exactly how much new work was added and where it intersects existing chains.

Compatibility and rollout plan

The feature works with all current connectors. It reads existing playbooks and constructs a graph automatically. No schema migration is required. For workspaces that use Git sync, the graph view is available in preview environments so you can validate behavior before merging. For a tour of default capabilities, revisit the features overview in the app.

If you are making your first connection, the answers to common questions explain how quotas, keys, and runners are handled in managed deployments. If you need a step by step tour, the get started in minutes guide shows the onboarding flow from invite to first run.

The next steps for this area include a path level service level target and an advisor that suggests initial caps based on past runs. Both features are in early access. If you want to try them, talk to your account team after you enable the optimizer on a production program.

This release fits into our broader push to make orchestration smarter without forcing authors to write more boilerplate. The platform brings these controls into the scheduler so agentic workflow patterns behave consistently across connectors and agents. You get repeatable behavior and less fragile bespoke scripts.

ButterGrow integrates the Run Graph across list building, media pipelines, and enrichment paths so the same mental model works everywhere. That consistency matters for onboarding new team members and for staying fast when your program grows.

Your teams can design better experiments, reduce time to delivery, and spend less effort on firefighting. Most importantly, you can show a clear line from a faster pipeline to higher revenue and healthier agent workloads.

The optimizer does not remove the need for good hygiene. You still want idempotent tasks, narrow scopes per node, and a stable schema. The graph just surfaces where practice needs attention.

Pairing tracing and live replay with the Run Graph gives you visibility and control in one place.

Finally, to connect concepts, note that a graph model and critical path logic are not unique to this platform. They are proven tools across orchestration engines and project management. What matters is how they are tailored for marketing and the APIs those programs rely on every day.

ButterGrow customers can take advantage of this today. New users can see what the product offers in the features list.

If you want a predictable way to keep large programs moving through busy seasons, this is a practical upgrade. The work is already paying for itself in saved hours and fewer missed windows.

Enable the feature, pick a strategy, and check the Run Graph on your next launch day. The improvement will show up in your first set of metrics.

This is one of several updates focused on control and clarity. It sits alongside cost guardrails, approvals, and better diffs so the platform can stay flexible while guardrails remain strong.

ButterGrow remains the fastest way to build and operate complex orchestration for growth. The Run Graph is a big step toward a world where complicated programs stay understandable and reliable at scale.

This paragraph serves as a natural call to action. Try the Run Graph and Critical Path Optimizer in your workspace and see how the visual model changes planning and debugging. You can get started in minutes when you are ready to try it.

References

• Directed acyclic graph overview - background on graphs used to model dependencies.
• Critical path method explained - project management technique that inspired the optimizer.
• Topological sorting concepts - how schedulers identify runnable nodes without unmet prerequisites.