Agent systems · 2026
Turn a messy ticket export into a release-blocker report you can verify. See how executable steps, source records and checks turn an agent’s answer into inspectable work.
University of Illinois Urbana-Champaign · Meta · Stanford University · Affiliations in the paper
START WITH THE IDEA
This survey examines code as the environment around an agent: interfaces for action, mechanisms for memory and feedback, and ways to coordinate multiple agents. A model’s proposed next step becomes executable work whose artifacts and results can guide what happens next.
THE SIGNIFICANCE
The survey brings together designs in which code connects reasoning, tools and execution feedback. A persistent artifact gives a later step something concrete to inspect, rather than depending entirely on a conversational summary.
Abstract; sections 2–3 ↗Execution results can expose an incorrect assumption and inform repair. This is an architectural pattern across surveyed systems, not a guarantee that an agent will fix every error or a single benchmark reproduced here.
Mechanisms and feedback ↗Our examples turn a ticket export into a traceable report and migrate a configuration without losing its meaning. Both compare a plausible first attempt with explicit transformations and independent checks.
Hopper implementations ↗An export mixes old and new issue updates. Build the current blocker list with the source record that supports each result.
Compare the approaches. Run a simple priority filter and a latest-state workflow on the same CSV. The verifier exposes fixed bugs incorrectly retained by the first draft and rejects conflicting source updates.
From the implementation repository after cloning:
node packages/code-as-agent-harness/cli.mjsSource & instructions ↗
Editable ticket CSV → latest issue state → release-blocker report with source records and verification. Deterministic local tools; no live LLM.
CHOOSE THE RIGHT TOOL
Hopper’s application guidance. Compare on your own task before adopting a more complex approach.
Retain inputs and artifacts, then independently check the result before returning success. Start with one explicit invariant.
Use the report and migration examples as small tool/check boundaries an agent can call.
A plain function plus tests may be enough. These browser examples themselves do not need an LLM to execute.
Add agent planning only when choosing or adapting the steps provides value.
Stop and expose the missing evidence. A confident answer or a passing unrelated test does not resolve conflicting records.
Request better input or an appropriate review; document what the checks actually establish.
Do not turn an educational harness into a shell with unlimited authority. The examples accept bounded data and call fixed functions.
Production execution needs the owning runtime’s isolation, permissions, timeouts and durable recovery.
import { releaseReport } from './packages/code-as-agent-harness/workflow.mjs';
const { report, checks, trace } = releaseReport(csv, {
priorities: ['P0', 'P1']
});
// Invalid or conflicting source records throw.
// Each returned issue includes its supporting record number.
console.log(report, checks);Free open-source code · GitHub ↗Use this pattern for agent-generated reports, migrations or repository changes: define the allowed input, preserve artifacts, and make explicit checks a condition of returning success. Here the model’s role would be to choose or compose the workflow; the tools do the parsing and the verifier checks the result.
This example defines a blocker as the latest unresolved P0/P1 issue. A team may use a different rule. Verification proves these stated checks, not that the export is complete or that the release is safe. It is a deterministic implementation of a harness pattern, not an LLM agent or a reproduction of the survey.
node packages/code-as-agent-harness/cli.mjs tickets.csv
THE ORIGINAL WORK
The original, hosted by arXiv, opens inside this page. CC BY 4.0. Version 2605.18747v1.
Two levels to explore: computation inside a model, and execution around a model. This is an editorial comparison, not a claim of direct citation.
A selected reference for tracing actions and observations.
Survey reference 144; section 3.1.1 · Cited by the paperFirst submitted 2026-05-18. 2605.18747v1.
Original source ↗ · Paper license ↗
Explanations, diagrams and educational code by Hopper Labs. Code: MIT. Original publications and documentation remain with their authors. These are independent educational examples, not endorsements. Any recorded evaluation is described separately with its exact scope.