PaperlayerView exact revision on arXiv

Source-linked AI summary

Design Anything, Design at Scale

Xuchao Ren, Siyuan Feng, Jing Huang, Yanhua Yao, Jing Wang, Lingyu Alina Wang, Anan Chen, Hangjie Yuan, Tao Feng, Qiong Wu, Sai Ma

arXiv:2610.24771v1cs.CV

TL;DR

Long-horizon design agents must preserve constraints and prior decisions while producing coordinated deliverables, yet alignment remains difficult as projects grow. Design Anything stores intent in an intent–execution graph and uses a controller to track delivery, and its benchmark evaluation reports stronger constraint satisfaction than same-model baselines across scales and domains. The results also include higher designer preference for its complete deliverable sets.

  • Problem

    Long-horizon agents can lose constraints, stop too early, or fail to carry earlier design decisions across coordinated artifacts, making alignment harder as deliverables multiply.

    Source: §1 · p. 2

  • Method

    Design Anything stores deliverables, constraints, and decisions in an intent–execution graph, links selected designs as inputs to later generations, and uses execution records to direct work on outstanding deliverables.

    Source: §1 · p. 3

  • Results

    Design Anything satisfies more constraints than the strongest same-model baseline overall and at every project scale, leads or ties in 18 of 19 domains, and receives the highest designer preference.

    Source: §4 · p. 11

  • Takeaways & Limitations

    Design Anything’s complete deliverable sets receive the two highest estimated preference scores among five configurations in a blind evaluation by professional designers.

    Source: §1 · p. 3

    The controller checks bindings, execution, output forms, and quantities, but cannot determine whether an artifact is what the brief requested or whether its content satisfies constraints.

    Source: F Limitations · p. 47

Abstract

from arXiv · show

As multimodal resources are transformed into media outputs, agentic AI is expected to stay aligned with design intent over long horizons. Designers follow briefs specifying goals, constraints, and deliverables, with later work building on earlier decisions. Recent work reuses design experience across tasks, yet alignment among artifacts within one project remains challenging. Agents therefore need to preserve and apply this intent across domains and as projects grow. We introduce Design Anything, a graph-based harness that preserves design intent outside the model and binds deliverables to the workflow steps that produce them through an intent-execution graph. A task contract retains constraints and decisions, selected designs become explicit inputs to later generations, and a deterministic controller uses bindings and execution records to check output types and counts, identify outstanding deliverables, and guide subsequent turns. We also introduce DesignAnything-Bench, with 228 tasks across 19 design domains, including 38 project families at scales of 6, 14, and 24 artifacts. With the LLM held fixed, Design Anything satisfies 85.0% and 92.5% of the brief's factual constraints with DeepSeek V4.1 Flash High and GPT-5.6 Sol High, respectively, exceeding the strongest same-model baselines by 15.4% and 14.4%. These gains reach 25.1% and 23.0% on 24-artifact tasks. Under each model, Design Anything leads or ties in constraint satisfaction in 18 of 19 domains. Professional designers also prefer its complete deliverable sets over those of same-model baselines in a blind evaluation.

1 Introduction

Design Anything addresses the difficulty of keeping requirements, deliverables, and prior design decisions aligned across long-horizon projects. It introduces a graph-based harness and a benchmark for testing that alignment across domains and project scales, reporting stronger constraint satisfaction and designer preference than same-model baselines.

Motivation

  • Long-horizon alignment requires delivering every requested artifact, satisfying each applicable constraint, and carrying earlier design decisions into later work.These demands become harder as deliverables multiply; models may lose constraints, use long-context information unreliably, or stop too early in long tool-use runs.Source: §1 · p. 2

Research gap

  • Existing approaches either rely on a model to judge completion, check one artifact at a time, or reuse design experience from earlier tasks.The paper frames reliable tracking of unfinished deliverables and continued guidance from recorded constraints and decisions as harness challenges.Source: §1 · pp. 2–3

Design Anything Harness

  • Design Anything keeps design intent outside the model in an intent–execution graph that binds each deliverable to the workflow steps producing it.A persistent task contract retains deliverables, constraints, and decisions; selected designs can become explicit inputs to later generations, and a deterministic controller checks output kind and count to identify outstanding work.Source: §1 · p. 3

DesignAnything-Bench

  • The benchmark tests alignment across 228 tasks in 19 domains, with 38 project families posed at 6, 14, and 24 artifacts.The project families share background and inputs across scales.Source: §1 · p. 3

Evaluation

  • With the LLM fixed, Design Anything satisfies more constraints than the strongest baseline overall and at every project scale, leads or ties in 18 of 19 domains, and receives the highest designer preference.The benchmark comprises 228 tasks across 19 domains and 38 project families scaled from 6 to 24 artifacts.Source: §1 · p. 3

2 Method

Design Anything represents design intent outside the model and uses an intent–execution graph to connect deliverables to the workflow that produces them. An agent loop builds and executes that workflow, while a delivery loop checks execution status and directs subsequent work toward unfinished deliverables.

2.1 Problem formulation

  • Alignment is measured on exported artifacts by whether each requested deliverable is produced, its applicable constraints are met, and earlier decisions carry into later artifacts.As deliverables multiply, each turn needs relevant constraints, earlier decisions, and current delivery status.Source: §2.1 · pp. 3–4

2.2 Intent–execution graph

  • The intent–execution graph stores a task contract, workflow graph, and execution records, with bindings connecting deliverables to producing nodes.The contract keeps deliverables, constraints, goals, success criteria, open questions, and recorded design decisions available across turns.Source: §2.2 · p. 4
  • Selected concepts and supplied references enter later generations as explicit inputs through typed dependencies between workflow nodes.Each node computes its output from its configuration and the outputs of its parent nodes.Source: §2.2 · p. 4

2.3 Agent loop

  • The agent loop builds and revises the state through PLAN, BUILD, EXECUTE, and AUDIT operations, which take effect only when deterministic validity checks accept them.Checks cover tool arguments, node configurations, references, port types, and bindings; rejected operations leave state unchanged and return an actionable error.Source: §2.3 · p. 5

2.4 Delivery loop

  • The delivery loop marks deliverables outstanding when they are unbound, their bound work is unfinished, or their outputs fail kind or item-count checks.The controller uses workflow and execution records to identify outstanding work and start another turn naming deliverables and their blocking reasons; a model's statement that it has finished is insufficient.Source: §2.4 · p. 5
  • The controller checks declared node capabilities and output counts, while constraint satisfaction and consistency are evaluated from exported artifacts.Reduced execution configurations are compared with the full harness for delivery and efficiency.Source: §2.4 · p. 5

3 Experiments

The experiments evaluate Design Anything across design domains and project scales, then examine delivery mechanisms and professional preference. Across these evaluations, it leads or ties in constraint satisfaction across most domains and retains an advantage at larger scales.

3.1.1 Task composition

  • The benchmark contains 228 tasks across 19 domains; 38 project families have matched versions at 6, 14, and 24 artifacts.The matched-scale set comprises 114 tasks, while other projects are independent at one scale.Source: §3.1.1 · p. 5, Figure 4 · p. 6

3.1.2 Evaluation measures

  • Constraint satisfaction requires each applicable factual constraint to hold in every eligible artifact, whereas delivery completion measures the share of requested files delivered.Set consistency scores shared visual rules such as palette and typography; design quality is weighted by delivery completion.Source: §3.1.2 · p. 6

3.3.1 Overall and cross-domain results

  • 85.0% on DeepSeek and 92.5% on GPT constraint satisfaction make Design Anything the within-model leader across 228 benchmark tasks.It also leads on reference fidelity and identity consistency, while some baselines score higher on set consistency or other measures.Source: Table 1 · p. 7, §3.3.1 · p. 7

3.2 Experimental setup

  • Systems receive the same briefs and materials, and each task contributes one final result scored by a common evaluator; comparisons use 95% bootstrap intervals over project families.The main comparison groups configurations by LLM and evaluates each complete system with its own tools and execution policies.Source: §3.2 · pp. 6–7

3.3.1 Overall and cross-domain results

  • Design Anything leads or ties in 18 of 19 domains under each LLM, with 12 tasks per domain.JarvisHub leads in product design on DeepSeek, and Codex in exhibition design on GPT.Source: Figure 5 · p. 7, §3.3.1 · p. 7

3.3.2 Results at scale

  • At 24 artifacts, Design Anything reaches 85.7% constraint satisfaction on DeepSeek and 91.9% on GPT, leading OpenDesign by 25.1% and Codex by 23.0%.The advantage persists across the 38 matched project families as requested artifact counts rise from 6 to 24.Source: Figure 7 · p. 8, §3.3.2 · p. 8

3.4 Ablation studies

  • Complete raises delivery from 73.9% to 96.1% and constraint satisfaction from 57.5% to 90.4% versus Stop at model end.Compared with Generic prompt, Complete has similar delivery (96.1% versus 96.9%) at about one-third the mean LLM cost: $0.43 versus $1.30.Source: Table 2 · p. 10, §3.4 · p. 10

3.5 Human evaluation

  • Designers prefer Design Anything to each same-LLM baseline in blind pairwise judgments: 82% against OpenDesign, 70% against Codex, and 51% against JarvisHub.The evaluation comprises 1,019 judgments from 12 designers on 185 tasks; its GPT and DeepSeek configurations rank first and second in estimated preference.Source: Figure 9 · p. 10, §3.5 · p. 10

4 Conclusion

The paper presents Design Anything, a harness that externalizes design intent in an intent–execution graph, alongside a benchmark spanning domains and project scales. Its results show stronger constraint satisfaction across domains and scales, high designer preference, and lower LLM cost than generic prompting in the delivery-loop study.

4 Conclusion

  • Design Anything externalizes design intent in an intent–execution graph that binds deliverables to the workflow steps producing them.DesignAnything-Bench contains 228 long-horizon tasks across 19 domains and three project scales.Source: §4 · p. 10
  • With the LLM fixed, Design Anything satisfies more brief constraints than the strongest baseline overall and at every scale, leads or ties in 18 of 19 domains, and receives the highest designer preference.In the delivery-loop study, the full harness delivers nearly as many artifacts as generic prompting at about one-third its LLM cost.Source: §4 · p. 11

A Implementation and Runtime Details

Design Anything separates project intent from execution state, links deliverables to producing workflow nodes, and uses deterministic checks to track completion and guide further work. The appendix specifies how DesignAnything-Bench tasks, outputs, metrics, and human judgments are constructed and evaluated.

A.1 Task contract

  • The task contract stores deliverables, success criteria, constraints, decisions, and open questions separately from execution progress.Revising the contract updates intent rather than recording progress.Source: §A.1 · p. 15

A.2 Graph construction and artifact ownership

  • Delivery groups bind graph nodes to contract deliverables, while ownership rules prevent shared outputs from counting automatically toward multiple deliverables.Dependencies express ordering between groups; port-level edges carry operation inputs.Source: §A.2 · p. 15

A.3 Operational delivery checks

  • The controller checks bound executable nodes and declared output capabilities, while quantity checks count supported output items rather than generation nodes.A completed node does not establish realized page counts, so artifact evaluation remains necessary.Source: §A.3 · p. 15

A.4 Observation and new turns

  • Between turns, the controller derives obligations from graph state and execution records, then stops, waits, terminates, or starts another turn according to their status.A successful root obligation requires every deliverable and no unresolved question, pending decision, or running execution.Source: §A.4 · p. 15

A.5 Automatic verifier

  • After delivery, deterministic structural checks and a verifier return findings against success criteria; visual critique is an optional agent-called tool.The verifier is enabled in the main comparison and complete delivery-loop configuration, but not reduced delivery-loop or planning configurations.Source: §A.5 · p. 16

B.1 Task construction and benchmark independence

  • The benchmark contains 228 tasks across 19 domains and 152 project identities, with three shared-input scale variants for base families and separate reference-material and breadth projects.Only base tasks support within-family scale comparisons; systems receive English briefs and materials, and scoring uses frozen task specifications.Source: §B.1 · pp. 16–17

B.2 Output processing and assignment

  • The evaluator assigns delivered files to requested categories using artifact content and specifications, avoiding duplicate counts for alternate formats or copied inputs.Category assignment fills expected quantities, uses each image at most once, and can record excess images as overflow.Source: §B.2 · p. 17

B.3 Measures, eligibility, and aggregation

  • The measures distinguish delivery, constraint fulfillment, fidelity to supplied references, consistency among outputs, image quality, and designer preference.Delivery completion caps category counts at requested quantities; design quality multiplies image-checklist scores by pooled delivery completion.Source: Table 3 · p. 17, §B.3 · pp. 18–19

B.5 Designer evaluation protocol

The designer study uses blinded, randomized whole-set comparisons of system outputs on the same brief. It estimates preference across configurations from designers’ choices, with task- and designer-level bootstrap intervals.

B.5 Designer evaluation protocol

  • Twelve designers rated 185 tasks across five discipline groups, using the same system runs scored by the automatic measures rather than appearance-selected runs.Some tasks received a second rating from another designer in the same group.Source: §B.5 · p. 20
  • In 1,019 blinded whole-set judgments, designers chose which deliverable set they would rather hand to the client, with randomized sides and ties allowed.They saw the brief and a reference translation, but not system names, reasoning, or completion claims.Source: §B.5 · p. 20
  • The reported preference is each configuration’s average fitted Bradley–Terry probability against the other four, with equal opponent weights and 95% intervals bootstrapped over tasks and designers.It is not a raw head-to-head win fraction.Source: §B.5 · p. 20

C.1 Controlled comparisons and experimental settings

The main comparison uses five configurations on the same task identifiers with frozen specifications, while evaluator and runtime settings are documented. Metric-count tables provide the underlying counts and coverage for aggregate results.

C.1 Controlled comparisons and experimental settings

  • The main model-group comparisons hold the LLM fixed but not media-generation tools, orchestration, or execution policies, so they compare complete system configurations.The main groups share briefs except for three tasks in one book project family, and use a common evaluator.Source: §C.1 · p. 20, Table 4 · p. 21
  • All five configurations use the same 228 task identifiers, with frozen evaluation specifications matched to the brief version each received.OpenDesign alone used a different evaluator version for script-rendered HTML deliverables, which were re-imported and rescored.Source: §C.1 · p. 20

C.2 Metric counts and aggregate results

  • Independent scorings of the same outputs differ by about three points on judged measures, and differences of that size are not interpreted.Table 6 reports observed numerators, denominators, and coverage counts underlying the main results.Source: §C.1 · pp. 20–21, §C.2 · p. 22, Table 6 · p. 22

C.3 Results by task condition

Design Anything has the highest constraint satisfaction within each model group across every tested task condition, while some baselines deliver more artifacts in particular conditions. Domain-level comparisons indicate breadth of performance, not significance in every domain.

C.3 Results by task condition

  • The three scale rows within each base project family are dependent observations because they share the same 38 families.Source: §C.3 · p. 22
  • The supplementary task-level pass test requires filled categories, all critical constraints to hold, and presentation and report page minima to be met.Unmeasurable tasks remain in the denominator, and the all-deliverables test includes requested intermediate outputs.Source: §C.3 · p. 22
  • Each domain contributes 12 tasks and 25 to 80 applicable constraints, so domain rates describe performance breadth rather than significant differences in every domain.Source: §C.3 · p. 22
  • Design Anything leads same-model baselines in constraint satisfaction in every task condition, reaching 85.3% and 96.0% on breadth tasks.OpenDesign delivers more on breadth tasks under DeepSeek, while Codex delivers more at every base scale under GPT.Source: §C.3 · p. 22, Table 7 · p. 23

C.4 Robustness of the paired comparisons

Paired comparisons support Design Anything’s constraint-satisfaction advantage at each project scale, while sensitivity checks preserve the main ranking under alternative treatments of missing deliveries and judge abstentions.

C.4 Robustness of the paired comparisons

  • 95% intervals for all paired constraint-satisfaction gaps at 6, 14, and 24 artifacts are above zero; gap growth is supported only against JarvisHub.The point-estimate gaps widen with scale against each baseline, but only the growth interval against JarvisHub excludes zero.Source: Table 8 · p. 24, §C.4 · p. 24
  • Excluding 2–39 wholly undelivered-category constraints per configuration changes same-model gaps by at most 1.9 points; every paired gap at 14 and 24 artifacts still excludes zero.After exclusions, gap growth is 10.0 points [−4.2, 24.3] against Codex and 18.9 [0.8, 37.6] against JarvisHub.Source: Table 9 · p. 24, §C.4 · p. 24
  • Among Codex’s 191 unmet constraints with per-file records, 117 hold in at least half of their targets, showing many failures are omissions within a delivered set.Table 11 decomposes Equation 7 to distinguish partial coverage from satisfaction in every target.Source: §C.4 · p. 24
  • Excluding judge abstentions raises Design Anything identity consistency to 90.1% and 93.4%, while its within-model ranking on identity consistency and reference fidelity remains unchanged.The table reports both abstentions-counted-as-mismatches and abstentions-excluded measures.Source: §C.4 · p. 24, Table 10 · p. 25
  • On GPT, per-file constraint coverage is 97.9–99.1% for Design Anything versus 86.1–88.6% for Codex across scales, but coverage does not establish full constraint satisfaction.Coverage pools successful constraint–target checks; a constraint passing only some targets remains unsatisfied.Source: §C.4 · p. 25, Table 11 · p. 25

C.5 Reference coverage

This block examines reference use, resource demands, design quality, and the scope of the ablation studies. Reference reuse is associated with identity consistency, while resource counts have differing scopes across models.

C.6 Resource use in the main benchmark

  • DeepSeek input-token medians rise from 1.4M to 6.6M to 9.1M at 6, 14, and 24 artifacts; GPT orchestrator medians are 5.6M, 16.6M, and 18.4M, but the scopes differ.The GPT counts exclude helper sessions, and token records differ in scope across harnesses, so cross-system token or cost comparisons are not made.Source: Table 12 · p. 26, §C.6 · p. 26

C.5 Reference coverage

  • Design Anything uses references in 95.3% of image generations versus 39.4% for JarvisHub, and coverage is positively associated with JarvisHub identity consistency (ρ = 0.40).On 24-artifact tasks, coverage is 97.9% for Design Anything and 40.2% for JarvisHub; within-condition ranking gives ρ = 0.47 for identity consistency.Source: §C.5 · pp. 25–26, Figure 11 · p. 27

C.7 Design quality

  • Design Anything leads all four delivery-weighted design-quality dimensions under DeepSeek; under GPT it scores 88.5 on aesthetics and 92.5 on domain criteria, while Codex leads technical quality and text rendering narrowly.Codex’s GPT leads are 0.1 and 0.5 points, respectively, below observed judging variability.Source: Table 13 · p. 27, §C.7 · p. 27

D Ablation Studies

  • The delivery-loop study uses 19 main-corpus tasks, while planning-interface and state-summary studies use separate tasks and harness versions; their results do not contribute to the 228-task benchmark aggregates.No ablation study uses skills written for a particular design domain.Source: D Ablation Studies · p. 28

D.1 Delivery loop and execution efficiency

The ablations compare delivery and efficiency mechanisms with reduced configurations, then test planning interfaces and state summaries. The qualitative examples show recorded outputs and dependencies from selected runs.

D.1 Delivery loop and execution efficiency

  • 96.1% delivery and 90.4% constraint satisfaction: Complete improves both over Stop at model end, but neither outcome differs significantly from Generic prompt.The comparison with Generic prompt does not isolate any one component of the full harness.Source: Table 14 · p. 28, §D.1 · p. 28
  • Six Stop-at-model-end runs deliver fewer than half their artifacts, while none of the Complete runs do; Generic prompt recovers each to 23 or 24 deliverables.At least 12 fewer satisfied constraints occur in runs that still deliver 20 or more artifacts.Source: §D.1 · p. 29
  • Complete costs $0.43 per run versus $1.30 for Generic prompt on 17 paired tasks; Generic prompt takes more agent steps on all 17.The Generic prompt configuration also issues more generation requests than Complete on 15 tasks and fewer on 3.Source: Table 15 · p. 29, §D.1 · p. 29

D.2 Planning-interface study

  • On eight tasks, delivery completion is 7.7 points lower with Planning tools off than with Structured, and 2.1 points lower with Text plan.Other channels for tracking requirements remain available in all three configurations.Source: §D.2 · p. 29

D.3 State-summary efficiency

  • Nine of ten paired tasks devote a larger fraction of tool calls to active canvas reading without the state summary; the geometric mean ratio is 2.06.The study measures direct state inspection, not final design quality.Source: §D.3 · pp. 29–30

E Qualitative Examples

  • The qualitative examples enlarge a matched 14-artifact animation comparison, trace one selected design through a 24-artifact project, and index selected gallery runs across domains and scales.These examples illustrate delivered work and recorded dependencies.Source: E Qualitative Examples · p. 31

E.1 Enlarged outputs for Figure 6

The examples enlarge outputs from a matched animation comparison, trace dependencies in a recorded product-design project, and show selected workflow graphs and artifact boards across domains and scales.

E.1 Enlarged outputs for Figure 6

  • The enlarged 14-artifact animation outputs retain deliverable order and mark five checked content errors; examples include a mistaken case handoff and storyboard departures from the brief.A slashed-circle marker means the evaluator did not credit an artifact, not that no file was exported; the marked errors are not exhaustive.Source: §E.1 · p. 31, Figure 12 · p. 32, Figure 13 · p. 33

E.2 A recorded project and its shared dependencies

  • In the LUMA project, the selected Continuum direction board has 18 recorded outgoing connections feeding later boards, video, and a presentation; the run delivers all 24 artifacts but satisfies 6 of 7 constraints.The graph has 79 connections total, and the identity judge rates 16 of 18 image pairs as the same product; reuse alone does not guarantee full fulfillment.Source: Figure 14 · p. 34, §E.2 · p. 34

E.3 Agent-built workflow graphs and image boards of thirteen projects

  • The selected gallery contains thirteen GPT-5.6 Sol High runs across domains and requested artifact counts, with workflow graphs and delivered boards shown for projects including landscape, packaging, UI/UX, exhibition, and furniture design.The gallery is illustrative and projects were selected for display.Source: §E.3 · p. 35, Table 16 · p. 35, Figure 15 · p. 36

F Limitations

The limitations concern what the controller can verify, the evaluation setup, the scope of system comparisons, and benchmark coverage.

F Limitations

  • Each configuration contributes one final result per task, so repeated runs would better characterize run-to-run variation.Design-quality image checklists rely on a vision-language judge, and whole-set designer preferences do not identify which properties drive preference.Source: F Limitations · p. 47
  • Main comparisons hold the LLM fixed but evaluate complete systems, while the delivery-loop comparison bundles several mechanisms.Planning-interface and state-summary studies examine narrower changes within their own configurations.Source: F Limitations · p. 47
  • The controller checks bindings, execution, output forms, and quantities, but cannot verify whether artifacts match the brief or satisfy its constraints.Artifact evaluation remains necessary.Source: F Limitations · p. 47
  • The benchmark uses English briefs and scripted checkpoint questions, and excludes 3D meshes, audio, other languages, and live client feedback.3D meshes and audio are excluded for fair comparison because not all compared systems can generate them.Source: F Limitations · p. 47

Related papers

Loading 2610.24771v1…