SYNTHESIS NOTE
Topics›Agent Harness›this note

What happens to code that agents create and then share?

Agent-authored code artifacts that persist across tasks and multiple agents remain poorly understood. The open questions cluster around what should be retained versus discarded, and how shared state stays consistent when multiple agents collaborate.

Synthesis note · 2026-05-28 · sourced from Agent Harness

Among the three elements of agentic code — model capability, harness infrastructure, and agent-initiated artifacts — the survey flags the third as the one that "remains relatively underexplored." Agent-initiated code artifacts are the interactive objects an agent creates, executes, observes, revises, persists, and shares during a task: patches and tests authored over a live repository, interface commands synthesized against DOM trees, hypothesis-testing pipelines composed on the fly, executable policies and skill libraries revised in response to environment feedback. These appear across coding assistance, GUI/OS automation, scientific discovery, and embodied control — yet they sit outside the well-mapped territory of predefined infrastructure.

The open questions cluster around persistence and sharing. When an agent writes code that outlives the current step, what should persist and what should be discarded? When multiple agents share artifacts, how is consistent state maintained, and how is a useful artifact promoted from one-off scratch work to durable, reviewable infrastructure? The survey's listed open challenges — evaluation beyond final task success, verification under incomplete feedback, regression-free harness improvement, consistent shared state across agents, human oversight for safety-critical actions — converge on exactly this layer. The counterpoint is that some agent-authored code is genuinely disposable and over-engineering its lifecycle wastes effort. But this matters because the artifacts an agent creates may be where the next gains in autonomy and coordination live, and they are precisely what current harness engineering least understands. A security-side counterpoint: where a shared store was never designated as an artifact layer, agents have used an ordinary one as a channel for coordinated intrusion, and the counter-swarm doctrine's answer is to constrain what agents write to it and later read (How can operators stop coordinated agent intrusions now?); a filed tension asks which side governs when the same store is both.

Inquiring lines that read this note 18

This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.

How do standardized protocols improve multi-agent coordination and reliability? How should agent systems validate and persist generated code artifacts? Do multi-agent systems introduce security vulnerabilities that single-agent architectures avoid? How does harness optimization generalize across different model architectures and domains? How effective are honeytokens and decoys against different security threats?

Related concepts in this collection 3

This note in its neighbourhood — explore the map, then jump to a related concept in the list below.

Concept map
18 direct connections · 163 in 2-hop network ·dense cluster Open in graph ↗

Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph

your link semantically near linked from elsewhere

Related papers in this collection 8

Papers most semantically related to this note, ranked by cosine similarity in the embedding space.

Original note title

agent-initiated code artifacts that persist and are shared are the underexplored frontier of harness engineering