This survey reframes AI agent work around the delivered artifact rather than the agent architecture, arguing that construction quality depends on whether three roles stay aligned: an Operational Representation that holds editable state, a construction policy that decides what to change, and runtime verification that turns observations into feedback a policy can act on.
You’ve shipped an agent that writes a slide deck, a repo patch, or a marketing poster from a brief. Something’s wrong at the end. Today your options are regenerate everything, or ask the model to critique itself and try again. Both are blunt. This survey is a map of 230 systems that tried to be less blunt, organized by one question: when a failure shows up late, can the system trace it back to a specific editable unit, or does it have to throw the whole draft away? The dominant baseline it positions against is the Reflexion-style loop, where an agent reads its own error text and re-plans. The authors argue that pattern under-delivers unless the artifact itself exposes structure the policy can target.
The paper’s core move is a functional decomposition of any “agent that builds something.” Three roles, defined at the level of one construction episode:
•
The Operational Representation is the artifact-side state: the SVG tree, the scene graph, the repo, the score. It exposes an Edit Interface with three granularities: unit edit (one passage, one file), relation edit (ordering, layout, dependencies), and whole-artifact edit (regenerate).
•
The Construction Policy picks the next action given the task, current state, and feedback. It can be workflow-driven (fixed stages) or autonomous (agent chooses), and can be run by one agent, a central orchestrator, or peer agents.
•
Runtime Verification looks at what changed, compares against acceptance criteria, and returns feedback that is one of: criterion status (pass/fail), failure diagnosis (which unit broke), or revision guidance (what to try).
A plain-English version of the loop the survey abstracts:
state = init_representation(task_spec)
feedback = None
while True:
action = policy.select(task_spec, state, feedback)
if action.is_stop: break
state = edit_interface.apply(state, action)
obs = observe(state)
feedback = verify(task_spec, state, obs)
if feedback.accept: break
return deliver(state)
The survey then uses this frame to compare six artifact families: textual, 2D visual, audio, video, spatial (3D/CAD), and behavioral (software, simulators). For each family it asks: what state is maintained, what edit units exist, and when does a failure become visible, at read time, at render time, at playback, or only during runtime execution.
The common industry framing is that agent quality is about the policy: better planning, better tool use, more agents, smarter self-critique. This survey argues the opposite. What determines whether an agentic system can actually fix its own output is the alignment between the artifact’s representation, the edit interface, and the granularity of the verifier’s feedback. A precise diagnosis is useless if the only available edit is “regenerate,” and a fine-grained edit tool is useless if the verifier only returns a scalar score. The evidence isn’t a headline benchmark; it’s the recurring pattern across families in Table 3 and the Mr. Dre finding that 16–27% of previously-accepted content regresses during later revisions.
The load-bearing observation is structural, not numeric: across 230 systems and six artifact families, the systems that support targeted repair are the ones where three things line up. The representation exposes the unit that failed, the edit interface can modify that unit without touching accepted work, and verification produces feedback at the same granularity. When any link breaks, agents fall back to whole-artifact regeneration.
Secondary findings that stack on top:
•
Decomposition is not free. Multi-agent role division (as in poster or slide pipelines) reduces local complexity but creates handoffs where global commitments (brand, narrative continuity, cross-file dependencies) get dropped. The paper explicitly warns that “how many model calls the system makes” is the wrong unit of analysis.
•
Learned judges share the generator’s blind spots. LM-as-judge signals can be correlated with the generator’s own preferences, so stacking more of them adds little independent evidence. DRACO documents persistent factuality and sourcing errors that multiple LM judges miss together.
•
Late-arriving observations dominate the harder families. Textual and 2D visual failures show up at read/render time. Video and audio failures need playback. Spatial and behavioral failures may only surface under traversal, simulation, or runtime interaction, which is where localization gets hardest.
•
The benchmark landscape is lopsided. Of the 29 construction benchmarks reviewed, only three evaluate any system property beyond task capability (reliability, robustness, efficiency, controllability, update stability), and each covers only one. A Design Arena snapshot shows the same model swinging from top percentile on slides to 34th percentile on mobile apps, so single aggregate ranks hide task-specific behavior.
•
SWE-bench and SWE-agent are the survey’s recurring concrete anchors for how repository state plus test feedback enables local repair, and Paper2Poster anchors the multi-criteria acceptance discussion (source fidelity, layout, one-page fit).
What They Found: Principles
The survey distills four design principles worth naming, because they double as a checklist:
1.
Externalize commitments into addressable state, not just into the prompt or agent memory.
2.
Define control boundaries where dependencies change, and make someone (or something) responsible for what crosses them.
3.
Make feedback actionable by matching verifier granularity to the edit interface.
4.
Revalidate affected state after a change, treating prior acceptance evidence as version-scoped.
Reach for this framework when you’re designing an agent that builds a multi-part deliverable, a report with citations, a slide deck, a repo change, a video with narration, and you’re deciding how much structure to put into the intermediate representation. The survey’s practical advice: before adding more agents or a better planner, ask whether your artifact exposes the unit that typically fails, whether your edit tool can change that unit alone, and whether your verifier reports failures at that same scope. If those three don’t line up, more agents won’t help.
Artifacts: the authors maintain a curated GitHub list at awesome-agentic-artifact-creation and a project site at agentic-creation.github.io. The paper itself doesn’t release code or a benchmark, it’s a survey with a coded corpus of 259 works through August 2026.
An agent can only repair what its representation exposes and its edit interface can touch. Precise self-critique is wasted on a bitmap when what you needed was a scene graph; a fine-grained edit tool is wasted when the verifier only returns a pass/fail. Build the representation first, then decide how clever the policy needs to be.
•
This is a survey, not an empirical study. The four principles are synthesized from patterns across 230 systems, not tested against a controlled baseline. The authors explicitly flag the fourth principle (revalidate affected state) as supported by “comparatively sparse” evidence.
•
The six-family taxonomy assigns each system by its primary delivered artifact, which glosses over systems that produce multiple coupled outputs (e.g., a paper plus a poster plus a video from shared state). The paper acknowledges this as a boundary case rather than resolving it.
•
“Alignment between representation, edit interface, and verifier” is a useful diagnostic frame but not a construction recipe. The survey does not tell you which representation to pick for a new artifact type, only how to notice when the one you picked is fighting you.