Artifact-Centered Agent Loops: Redefining Human-AI Collaboration with Harness

From Conversation-Centered to Artifact-Centered Agent Loops

Most current agent products organize tasks around conversation: the user states a requirement, the agent reads context, calls tools, modifies files, and returns the process and result to the chat. Even when a code editor, terminal, file browser, and preview window are present, the conversation log remains the primary carrier of goals, process explanation, and context linking.

In coding scenarios this works because the true task state also lives in the repository, file contents, symbol relationships, Git diffs, compilation results, and test reports. If the agent loses part of the chat context, it can re-read the project, locate relevant code, run tests, and recover the environment.

Once a human starts directly manipulating the artifact, the conversation no longer holds the complete work scene.

When the work object becomes a slide deck, spreadsheet, architecture diagram, mobile device, or 3D scene, the situation changes. Between two chat turns the user may have manually adjusted a slide, moved a node, edited cells, or switched pages in a simulator. At the next interaction the agent cannot merely review the chat history; it must re-understand the already-changed artifact and the intent the user expressed through direct manipulation but did not fully record in the conversation.

Artifact-Centered Agent Collaboration Loop

An artifact-centered agent collaboration loop is a process where humans and agents collaborate around a single continuously evolving work artifact; conversation still expresses goals and explains judgments, but the true work scene is the artifact and its state that both parties jointly maintain.

The artifact can be code, a presentation, an architecture diagram, a workbook, a running device UI, or a simulated world with spatial and physical state. Their internal structures differ, but they share one trait: they are not one-off generated files but work objects that are continuously entered, modified, verified, and reviewed.

Example: Browser Agent Loop Centered on the Web Page

A browser agent goes beyond "sending a page screenshot to the model" because the web page owns a browser runtime: the agent can see the page, click, type, scroll, screenshot, and combine page elements, console logs, and network requests to understand changes before and after an operation. The page is not a final delivery image but an environment that can be repeatedly observed, operated on, and re-observed.

In the new generation of coding agents (e.g., Cursor, Qoder browser design mode), users directly select elements in the running page and add modification requests via drawing, voice, or text. The system passes the selected element, its underlying code, surrounding layout, and visual relationships to the agent. Here the artifact itself starts to shoulder part of the context and instruction entry role; the user no longer needs to translate "what I see" into a full natural-language description and then tell the agent "which part I mean."

Example: From Web Page to Interactive Canvas

Canvas capabilities in Cursor/Qoder extend this to artifacts the agent itself generates. Users can directly select and annotate UI elements on the canvas, letting the agent continue modifications based on local feedback, or trigger subsequent actions via embedded buttons. The key is not a prettier preview window but that the artifact becomes the entry point for the next interaction round — the user no longer needs to re-translate "where I mean" into text.

When the agent organizes code reviews, test reports, architecture explanations, or research results into a readable, filterable, operable interface, the canvas should not be a one-off HTML output. It should further bring the team's experience in information organization, evidence presentation, and next-step actions into the artifact. Structured nodes on the canvas can become action entry points, allowing users to launch fixes, explanations, or follow-up questions directly from a risk, a diff, or a recommendation without returning to the chat box to re-describe context.

Browser Agent and Qoder Canvas implementations differ, but they jointly embody a shift: the agent's interaction interface is moving from "a result attached in chat" to "humans and agents jointly operating one artifact."

How Harness Becomes the Human-Agent Collaboration Environment

Adding a canvas or preview window alone easily falls back to "look at the picture and talk." The canvas solves how humans directly enter the artifact ; the domain runtime solves how the agent understands and operates the artifact ; Harness must connect human intent, agent operations, and artifact changes into a continuously running loop.

Specifically, Harness must handle at least four things:

Maintain continuously evolving task intent. Record not only the initial prompt but also what the user selected, annotated, rejected, and why the result was finally accepted.

Ground operations on a definite artifact version. Whether a web element, a chart in a slide, or a node on the canvas, every selection, modification, and verification should point to the same version and semantic object, preventing the agent from operating on stale screenshots, coordinates, or content.

Let different artifacts use their own runtimes. Web pages go to the browser, code goes to the repository and build system, documents, spreadsheets, charts, and simulators retain their own structures, operations, and verification methods.

Preserve inspectable verification evidence. The agent must not just say "done"; Harness needs to record what changed in the artifact, which results are verified, which remain unconfirmed, and present this to the human for judgment.

In Better Harness's current artifact model, an artifact is no longer just a file path but a work object with explicit version, structure, and presentation. Human selections, agent modifications, and subsequent verifications should all land on the same artifact version so both parties truly face the same work scene.

This does not mean forcing all artifacts into one canvas. Documents can become structured data snapshots with semantic addresses; content that requires execution to render can go through constrained builds and isolated previews. Harness unifies intent, version, operation, receipt, and evidence , not the internal models of each domain.

The most critical link is human ↔ artifact : in the traditional agent loop humans indirectly change the work object via prompts; in artifact-centered collaboration both humans and agents can directly modify the same artifact. Harness maintains the intent, version, and verification relationships behind these operations.

Therefore, an artifact-oriented Harness does not need to unify all domain models; it unifies the collaboration method, not the domain implementation . The current artifact view solves version binding, structure understanding, and safe presentation; next steps will progressively connect selection, annotation, write-back, version comparison, and verification evidence to form a complete artifact-centered agent loop.

Summary: From a Single Loop to Diverse Loops

From code and web pages to presentations, spreadsheets, and simulated worlds, different artifacts each form their own observation, operation, and verification loops. A diversified agent loop lets each artifact have its suitable collaboration mode, while Harness connects human intent, agent operations, and verification results.

When conversation is no longer the sole center, the artifact truly becomes the place where humans and agents work together.