Paper Explained: Agentic Artifact Creation — Where Generation Ends and Construction Begins

A survey that reorganizes 259 works around a single unit: the delivered artifact. It defines agentic creation through state, edits, and verification, then works through six artifact families, three evaluation targets, four principles, and six open problems — from first principles.

Agentic Artifact Creation: Systems, Evaluation, Principles, and Opportunities

The cliff between a draft and a deliverable

One line of prompt gets you an image, an essay, or a working function. So why is "just let the AI handle it" still hard in production? The paper names the boundary precisely: generative models made the parts cheap, not the deliverable (§1.1).

The running example is Paper2Poster, which turns a paper into a scientific poster. A poster has to preserve the source content, fit a fixed page, and actually communicate — all at once. Worse, those requirements interfere. Add text and it no longer fits; cut text and the content thins out. A plausible-looking image, or a single quality score, is not evidence that the poster is ready to ship (§1.1).

The harder problem is when failures become visible. In video you find out after assembly; in a game, after someone plays it. By the time you see the symptom, you often cannot say which decision caused it, so you regenerate everything. The paper calls this cluster failure propagation, weak localization, and broad regeneration (Figure 1).

The paper's definition

The definition is unusually austere (§3.1). An episode counts as Agentic Artifact Creation only when all three hold:

1. The AI system materially constructs or revises the deliverable itself (systems that only evaluate or consume artifacts are out)
2. It carries artifact or process state across construction decisions
3. At least one intermediate observation redirects later work

Notably, the number of agents and the number of model calls do not enter the definition (§2.2). Conversely, a pipeline whose observations never change what comes next is excluded no matter how many stages it has. That boundary doubles as the screening rule for the review: searching arXiv, Google Scholar, Semantic Scholar, the ACM DL, and IEEE Xplore from January 2023 through August 20, 2026 left 259 works — 230 systems and 29 benchmarks (§1.3).

Three roles, one loop

The backbone of the survey is a split of that definition into three functions (§3.2). It is a division of roles, not of implementations.

The Operational Representation holds the current artifact state and the edits you can apply to it.

Here $R_t$ is the artifact-side state at step $t$ — a draft, an SVG tree, a repository — while $a_t$ is the chosen action and $U$ is the update. Put in words, the line says only this: apply one edit to the current form and you get the next form. Shrinking one figure gives you a different poster — obvious enough. Writing it as state plus operation earns its keep later, when something breaks and you need a place inside the state to trace the breakage back to.

The Construction Policy picks the next move.

$T$ is the task specification and $f_t$ is the feedback in hand. What the line is saying, in words, is that the next move depends on exactly three things: the task, the current form, and what the last step revealed. Read the other way it bites: a loop running with $f_t$ perpetually empty never uses the third argument, so it fails the definition's third condition and falls outside the survey. That choice includes what to revise, who should do it, and whether to stop.

Runtime Verification turns the result into the next feedback.

$o_{t+1}$ is an observation of the updated state and $V$ checks it against the acceptance criteria — which says that this step looks at what the change did and restates it in terms the next move can act on: whether it passed, and if not, what failed and where. When $V$ emits only a number, $\pi$ has nothing to aim a repair at. On acceptance the artifact is delivered; otherwise feedback returns to the policy. Only when these three line up do the paper's affordances — composability, traceability, revisability — appear (§1.2).

The longer the horizon, the faster the space of states you would have to check grows. That is why sampled playthroughs and simulation rollouts "cover only part of the relevant state space" (§4.6).

Six artifact families

The survey groups the literature not by model or task but by the form that is independently accepted (§4): textual, 2D visual, audio, video, spatial (3D/CAD), and behavioral (software and simulators). These expand into 16 profiles, with 251 records assigned (Figure 2).

The interesting claim is that difficulty is not driven by modality. Two other axes do the work: how tightly decisions are coupled, and whether failures become visible while they are still repairable (§4 closing). Text can be read directly, yet a broken setup surfaces many paragraphs later. Video only reveals itself on playback. Software reveals itself on execution, but only along the paths that were exercised. Across families the question is identical: can an observed failure be traced back to a unit of the representation and repaired there?

Worth noting: no system meeting the definition was found for spoken audio at all (§4.3.2). Podcast-style pipelines come close but do not maintain an editable audio artifact.