LazyAgent: Demand-Driven Materialization and Physical Optimization of Agentic Programs
Agent runtimes that plan before acting run every step as soon as it is ready.
Arxiv 2 versions
-
13 new sentences, beginning: “Agent runtimes that plan before acting run every step as soon as it is ready.”
LazyAgent: Demand-Driven Materialization and Physical Optimization of Agentic Programs
Agent runtimes that plan before acting run every step as soon as it is ready. Neither these runtimes nor their benchmarks distinguish a step that is ready from a step the request needs, and the difference is large: across 303 requests on 154 production workflows, an eager runtime that stops once the goal is met spends 62.2% of its CPU on work the request never needed. LazyAgent is, to our knowledge, the first complete formulation of demand-driven execution for agent runtimes. Its rule: run a ready step only if the current request needs it, and keep that answer exact as the plan changes. A demanded set derived from the program decides, in one traversal with no model calls, so LazyAgent spends nothing outside the request. Because demand is defined exactly, its behavior is proved: builders know before any run where demand must save and where it must tie. The bill is known before a plan runs, so LazyAgent can act as a query optimizer to choose among candidate workflows. Measured live against that eager runtime, LazyAgent saves 51.7% and 52.1% of container time on release gates where a frontier LLM writes the patches, 12.8% of tokens on DataSciBench plans at matched quality, and 24.0% of dollars inside a live LangGraph application, with no losses. When the LLM re-plans after real code failures, it solves every solvable goal with 11.7% fewer tokens per goal. On the production workflows it saves 42.0% of CPU, ties exactly where a request needs the whole graph, and adds at most 0.43% overhead. The same set steers every physical operation: projection saves 80-89% of a shared CI step, where the identical eager control saves 0.0%. Public agent benchmarks are designed the same way as eager runtimes, so they cannot show this difference. We compose our test programs from their tasks and call on industry to build benchmarks that measure how efficiently agent workflows run.
-
LazyAgent: Demand-Driven Materialization and Physical Optimization of Agentic Programs
Current agent runtimes that plan before acting generally execute a step once it becomes ready. We present LazyAgent, a unified execution framework for agent-authored programs organized around a live, goal-derived demanded set. LazyAgent refreshes a backward closure from requested outputs as execution state changes and materializes a ready node only when the active goal requires it. This replaces repeated local judgments with one linear-time graph analysis followed by constant-time membership tests, allowing programs to remain broad while execution stays request-specific. On programs that describe more than the current request needs, LazyAgent consistently outperforms the strongest goal-stopping eager baseline by refusing unrelated work before it starts. Adding one unrelated product raises the eager bill by 22.5% and LazyAgent's by 0.0%. LazyAgent saves 42.0% of measured CPU on production scientific workflows and 51.7% of container time on a live release gate spanning four repositories. We also prove and verify exact equivalence when the request reaches the whole graph, leaving no unrelated work to avoid. Beyond permission, goal-relative output projection saves up to approximately 90% of a shared step on two third-party test suites while the identical eager control saves 0.0%; the advantage disappears when the omitted output has no other consumer or the request needs it. Ordering, reuse, and pruning can also save cost, but do not replace permission. Finally, we show that current public benchmarks are eager-shaped and contain almost no unrequested work. A pre-registered planning intervention did not broaden them. These findings motivate benchmarks built from standing programs and sequences.
Versions are compared on the headline and summary the publisher puts in their feed. An edit to the body of an article that leaves both untouched will not appear here.
Why am I seeing this Ranked on source trust — arXiv
It ranks mainly on source trust: arXiv is the most reliable outlet we track on this subject, and is the only one on the story so far.
Link-outLink-out, because it did not clear the bar for a write-up. Link-out means we point at the publisher and say nothing of our own.
| Factor | Weight | Score | Contribution | Where it came from |
|---|---|---|---|---|
| Corroboration | 0.35 | 0.39 | +0.135 25% | 1 independent org on the story. Tier-3 aggregators never corroborate — they can show something is circulating, never that it is true. |
| Source trustleads | 0.25 | 0.85 | +0.212 39% | arXiv is the highest-trust source on this story and is first-party — the organisation announcing its own news. Trust is taken from the best source, not averaged. |
| Pickup rate | 0.20 | 0.00 | +0.000 0% | One counted organisation, so there is no spread to measure — nothing has picked this up to set a rate. |
| Freshness | 0.20 | 0.99 | +0.198 36% | Halves every 10 hours from the newest item on the story. This is the only factor that rewards a story for nothing more than being recent. |
Corroboration counts distinct organisations, once each, and only from tiers 1 and 2. Freshness halves every 10 hours, so this ranking is a snapshot and will differ at the next build.
What happened
Agent runtimes that plan before acting run every step as soon as it is ready. Neither these runtimes nor their benchmarks distinguish a step that is ready from a step the request needs, and the difference is large: across 303 requests on 154 production workflows, an eager runtime that stops once the goal is met spends 62.2% of its CPU on work the request never needed. LazyAgent is, to our knowledge, the first complete formulation of demand-driven execution for agent runtimes. Its rule: run a ready step only if the current request needs it, and keep that answer exact as the plan changes. A demanded set derived from the program decides, in one traversal with no model calls, so LazyAgent spends nothing outside the request.
How this story arrived
Ordered by when each source was first observed, which is what the velocity figure is computed from. Publishers backdate; observed order does not.
- 01 Arxivfirst-party first seen LazyAgent: Demand-Driven Materialization and Physical Optimization of Agentic Programs
Overclock clusters coverage from independent sources and grades it automatically. The figures above are computed, not editorial. This page summarises and links to reporting by the outlets named — follow the links for the original work.