When Is an Agent’s Work Ready to Release?

A clean diff and passing tests do not make an agent’s change releasable. Someone still has to accept it, release it, operate it, and repair it.

An agent adds plan-history support to a billing service. It produces code, a migration, and passing tests. Before the team releases it, they need to know whether the migration works on real data, whether old readers remain compatible, and how to recover from a partial rollout.

A proposed rollback might simply delete the new history table. That could undo the schema change while destroying records created after deployment. The team may need a forward repair instead. This is the kind of decision a clean diff and a green test run cannot settle by themselves.

An artifact is a lasting output someone else will use: code, a package, a migration, infrastructure configuration, or a research report. Artifact stewardship means caring for that output beyond generation. It includes understanding its purpose and origin, checking whether it is fit for use, controlling release, and assigning responsibility for operation and repair.

This is Post 22 in The Abstraction Shift: How Software Keeps Moving Up.

Why the final patch is only part of the work

The first coding agent is usually evaluated by its immediate output: a patch, a test, a configuration change, or a generated explanation.

That evaluation is too narrow for production work.

A software change can compile and still violate a design constraint. Tests pass while missing the failure that matters, and a migration that succeeds on a small dataset may fail under production volume. Syntactically valid infrastructure can widen network access. A research report with citations can still overstate what the evidence supports.

As an agent becomes able to inspect repositories, run tools, open pull requests, modify files, execute tests, and prepare deployments, it participates in more of the engineering lifecycle. The agent has moved from the edge of a human editor into the system that turns intent into artifacts, as a variable producer.

The output may include:

source code and configuration;
test cases, fixtures, and evaluation harnesses;
database schemas, migrations, and backfill jobs;
infrastructure definitions, policies, and deployment manifests;
dependency updates, packages, containers, and release notes;
prompts, tools, skills, and agent policies;
research plans, datasets, notebooks, analyses, and reports; or
an artifact bundle containing several of these items and the evidence connecting them.

Each artifact has a lifecycle. Someone defines why it should exist, and someone or something creates it. Checks determine what is known about it, a person or policy decides whether it may be released, and an operator or domain owner carries it afterward.

If those responsibilities are hidden inside one agent run, the system may be fast while becoming impossible to govern.

What review and release pipelines already protect

Software engineering already separates production from acceptance and release.

An engineer writes or changes source code. A compiler transforms it. A build system assembles dependencies. Tests exercise known behavior. Reviewers compare the change with requirements and design. A CI pipeline records checks. A release system publishes an immutable version. Operators monitor it, respond to incidents, patch vulnerabilities, and eventually retire it.

The same pattern appears outside software. A database migration needs a forward plan, compatibility window, data checks, and a rollback or repair strategy. An infrastructure change needs a plan, permissions, drift detection, and an owner. A scientific result needs inputs, methods, assumptions, analysis, and enough record to reproduce or challenge the conclusion.

Supply-chain security adds another layer. A consumer needs to know which source, dependencies, build process, and controls produced a package. NIST’s SSDF includes collecting and sharing provenance for components of software releases. SLSA 1.2 organizes source and build concerns around provenance, attestations, and verification. in-toto frames supply-chain integrity as transparency about which steps were performed, by whom, and in what order.

These practices were created before coding agents. They become more important when the producer can be variable, fast, and difficult to attribute by reading the final diff.

The old system asked whether a human or a build service followed the process. The new system must also preserve what the agent saw, what it proposed, which tools it used, which instructions influenced it, which model and runtime produced the change, and where deterministic or human judgment entered the path.

What Is Agentic Engineering and Artifact Stewardship?

Agentic engineering uses agents to help plan, produce, test, and revise engineering work. The output may be a patch, a migration, a package, a dataset, or a research report. Here, artifact means a lasting output that another person or system may use.

Stewardship is the responsibility for that output after it is created. Someone must understand what it is for, check whether it is fit for use, decide whether to release it, and care for it once others depend on it. For the billing migration, that includes preserving existing reads and planning how to repair a partial backfill.

The table follows those responsibilities through the artifact’s life. They do not need separate products or separate job titles, but they do need decisions and evidence that the team can inspect.

Responsibility	Question it answers	Example evidence
Intent	Why does this artifact need to exist?	Requirement, issue, design decision, research question
Scope	What is included and excluded?	Files, resources, datasets, environments, non-goals
Production	How was it created or changed?	Agent task, model, runtime, tools, inputs, revisions
Validation	Does it satisfy explicit conditions?	Tests, linters, type checks, security scans, evaluations
Review	Does it make sense for the domain and design?	Human review, policy review, design approval, calibration
Provenance	Can its origin and transformation be reconstructed?	Source revision, dependency manifest, build attestation, evidence links
Release	Who or what may make it available for use?	Approval, protected branch, signed release, deployment record
Operation	What happens after release?	Monitoring, SLOs, runbook, ownership, incident path
Repair	How is it corrected, reverted, replaced, or retired?	Rollback, forward fix, migration repair, deprecation plan

The artifact is not ready simply because one row is strong. A passing test suite without an owner is fragile, and a signed package with weak tests is attributable but not necessarily fit. Human approval with no provenance behind it makes later investigation difficult. Stewardship connects the rows without collapsing them into one score.

The production system changes when an agent can propose and assemble the artifact, while acceptance, provenance, release, and maintenance remain explicit.

Following the generated change through its working life

The conventional change path is already a pipeline:

requirement -> design -> change -> review -> build -> release -> operation

Agentic engineering inserts model-mediated interpretation and production into that path:

intent -> context -> agent plan -> artifact bundle -> checks
  -> review -> provenance -> release authority -> operation -> stewardship

Humans stay in the pipeline. What changes is that a system can now generate a substantial candidate artifact, inspect its environment, run tools, react to results, and revise the candidate before a person sees it.

That changes what the organization must preserve.

The final diff is no longer sufficient to explain the change. The organization may need to know:

which task and requirement caused the agent to work;
which repository state and environment it observed;
which instructions, context, dependencies, and examples influenced the proposal;
which model, runtime, tools, and versions were used;
which files, resources, and external systems were changed;
which checks ran, under which environment, with what results;
which reviewer or policy accepted which scope;
which provenance and attestations were attached to the artifact; and
who owns the result, its operation, its rollback, and its future changes.

This is why “automated coding” undersells agentic engineering. A new producer has entered an existing engineering system. The producer is probabilistic and adaptive, so the acceptance boundary must remain inspectable and governable.

Where the familiar comparisons stop helping

A diff is not a design

A generated diff shows what changed. It does not show whether the change belongs in the architecture, whether the requirement was interpreted correctly, or whether an unmodified neighboring system now violates an assumption.

Review the change against intent, invariants, and operational context. A smaller patch can be more dangerous than a larger one if it hides a broken contract.

Passing tests settle only the cases they cover

Tests establish behavior for the cases they cover. They do not prove that the right cases were selected, that the environment is representative, or that the system meets legal, security, product, or operational requirements.

Agent-generated tests may be useful and may also inherit the same mistaken assumption as the implementation. Independent test design, boundary cases, production-like data constraints, and human or domain review remain necessary.

Provenance is not correctness

A signed attestation can establish where an artifact came from and which process produced it. It does not prove that the design is good, the dependency is safe for the use case, or the result solves the user’s problem.

Provenance makes claims inspectable. It does not turn process evidence into semantic validity.

A reproducible build does not imply a repeatable model

Reproducible builds aim for bit-by-bit identical artifacts from the same source, environment, and instructions. A model-mediated planning step may produce a different proposal when the model, context, tool result, or policy changes.

The system should make the generated proposal attributable and preserve the inputs needed to understand it. It should not claim deterministic regeneration when the production process is variable.

Review is not a transfer of responsibility

A human clicking approve does not mean the reviewer owns every downstream consequence. Approval should be bounded by scope, evidence, role, and artifact version. Ownership still belongs to the team or domain responsible for operating and maintaining the result.

Production continues after release

The artifact enters an environment where dependencies change, data grows, threats evolve, and assumptions expire. A release without monitoring, maintenance, vulnerability response, and retirement is an unfinished production process.

Rollback is not always reversal

Reverting source code is different from reversing a data migration, revoking a permission, removing a deployed resource, or undoing an external side effect. The artifact card needs a domain-specific repair strategy, not a generic “git revert” button.

Preparing a change another team can release and maintain

An artifact stewardship path can be implemented as a set of explicit boundaries:

Define the acceptance contract. Record purpose, scope, non-goals, invariants, risk, required evidence, and the person or team that owns the result.
Create a bounded workspace. Bind the agent task to a repository revision, environment, tenant, resource scope, credentials, budget, and expiration. Start with least privilege.
Assemble production context. Capture requirements, design decisions, relevant source, dependency versions, policies, examples, and known constraints with their provenance and freshness.
Generate a candidate bundle. Keep the plan, proposed changes, generated tests, configuration, documentation, and open questions together. Do not reduce the run to the final patch.
Execute in containment. Run tools and builds in an isolated environment with explicit network, filesystem, credential, and resource limits. Record external inputs and side effects.
Run deterministic checks. Apply formatting, type, unit, integration, security, license, dependency, migration, performance, and policy checks appropriate to the artifact.
Perform semantic review. Compare the candidate with requirements, architecture, threat model, data constraints, user impact, and operational readiness. Use human or domain review where the consequence requires it.
Assemble provenance. Identify source revisions, inputs, dependencies, builder or agent, model and runtime versions, tools, checks, reviewers, and artifact digests. Use attestations where consumers need a verifiable record.
Apply release authority. A successful build can be eligible for release without being released. Protect branches, environments, registries, and deployment actions with separate policy and approval boundaries.
Operate and steward. Monitor behavior, preserve ownership, respond to vulnerabilities, track drift, support repair, and retire the artifact when its assumptions or value no longer hold.

Generation is one step in an artifact lifecycle that still needs acceptance, authority, operation, and repair.

The path can loop. A failed check sends the task back to planning. A reviewer can request a narrower scope. A production signal can create a repair artifact. A dependency vulnerability can invalidate a previously accepted artifact. Stewardship is the loop that keeps the artifact connected to its changing environment.

Following the example through the system

Consider a billing service that stores a customer’s plan in one table, while a new product requirement needs plan history and effective dates.

The request to an engineering agent is:

Add plan-history support without breaking current reads. Prepare the migration, application changes, tests, rollout plan, and rollback or repair strategy. Do not release anything.

The agent has access to a bounded repository workspace, schema metadata, test commands, and a task-scoped issue. It does not have permission to modify production data or release to the production environment.

The candidate artifact bundle contains:

Artifact or record	What it must establish
Design note	The invariant for one current plan, history semantics, compatibility window, and non-goals
Schema migration	New table or columns, indexes, constraints, lock behavior, and forward execution order
Backfill job	Bounded batches, resumability, idempotency, observability, and treatment of ambiguous rows
Application change	Dual-read or dual-write behavior, feature flag, compatibility path, and removal plan
Tests	Existing behavior, history edge cases, concurrency, partial backfill, and migration failure
Performance evidence	Query plans, representative volumes, lock duration, and resource assumptions
Repair plan	How to stop, resume, correct, or forward-fix data without assuming source rollback is enough
Provenance record	Base revision, agent task, model and runtime, tools, dependency state, generated files, and checks
Review record	Product, data, security, and service-owner decisions with the exact artifact revision
Release package	Immutable revision, build provenance, deployment plan, approval boundary, and monitoring gates

The agent may produce a strong first bundle. The bundle is not ready because the code compiles.

Several people still have decisions to make. The service owner judges whether the data model expresses the business meaning, and the data owner whether the backfill is permitted and safe. The operator needs to know the rollout can be observed and repaired. The release authority decides when the package can enter an environment, and the team owns the system after the agent’s task ends.

Suppose the agent generates a rollback script that deletes the new history table. That may be syntactically correct and operationally dangerous. Once historical data has been written or downstream consumers have observed it, the safe repair may be a forward migration, a restore from a verified backup, or a domain-specific reconciliation. Artifact stewardship exposes this decision before release.

A subtler case: all tests pass, but the agent used a stale schema snapshot and missed a trigger maintained by another team. Provenance and context freshness make the gap visible. The right response is to expand the acceptance contract and rerun the relevant checks, rather than trusting the green build more strongly.

Or the source change is approved, but the build cannot produce an artifact whose provenance identifies the source revision and dependencies. The artifact may still be usable in a low-risk development environment. It should not silently receive the same release status as a traceable production artifact.

The valuable output is therefore the migration plus a governed bundle that another team can inspect, verify, release, operate, and repair.

A stewardship card makes the artifact’s purpose, production path, acceptance boundary, release authority, and long-term owner explicit.

What the team needs to design and operate

Architecture

Follow the billing change from its task to the package that runs in production. The workspace contains the candidate, source control identifies its revision, and the build and test systems record how it was checked. Release controls decide whether it enters production; monitoring and ownership records establish who cares for it afterward. Connect those stages without letting permission to edit a file automatically grant permission to deploy it.

Represent artifact state explicitly. A candidate, checked candidate, reviewed change, releasable package, released version, operating artifact, and retired artifact should not collapse into one boolean called done.

Give artifacts stable identities and immutable references where possible. A name such as latest is convenient for humans and dangerous for audit or rollback. Use revisions, digests, manifests, and environment records to distinguish what was actually reviewed and released.

Engineering

Make the agent produce a bundle, not only a patch. Include its plan, open questions, changed files, tests, check results, dependency state, provenance, and repair strategy. Preserve the context needed to explain the proposal without retaining sensitive data unnecessarily.

Separate generated checks from independent acceptance. An agent can write tests, but the system should also run established suites, invariant checks, security analysis, policy validation, and domain review appropriate to the artifact.

Build for artifact classes. Code, migrations, infrastructure, prompts, policies, datasets, and research reports have different failure modes, release boundaries, and rollback strategies. A single “AI-generated output” status is too coarse to govern them.

Product and UX

Show users the artifact’s status and remaining responsibility. “Generated,” “checked,” “reviewed,” “releasable,” “released,” and “verified in operation” are different product states.

Let a reviewer inspect the scope, change summary, evidence, provenance, uncertainty, and affected resources without reading an unbounded agent transcript. Make it clear which decisions remain with a person, a domain owner, or a release policy.

Operations and governance

Assign ownership before release. The owner receives vulnerability notices, responds to incidents, reviews drift, decides when to retire the artifact, and maintains the acceptance contract as the environment changes.

Treat provenance and attestations as evidence for policy, not decorative metadata. Consumers can ask whether the artifact came from an allowed source, builder, dependency set, review process, or environment. The answer should be machine-checkable where the consequence warrants it.

Measure stewardship health: unowned artifacts, releases without provenance, changes that bypass review, checks that have not run against current dependencies, rollback paths that have never been tested, and artifacts whose operating assumptions have expired.

Failure Modes

The final diff becomes the entire record

The system keeps the patch and discards the task, context, tool inputs, checks, and decisions. Preserve a bounded artifact bundle and link the final revision to its production and acceptance evidence.

Agent-generated tests certify the agent’s own assumption

The agent writes an implementation and tests that encode the same misunderstood requirement. Add independent acceptance criteria, existing regression suites, invariants, domain review, and adversarial cases.

Green checks hide an incomplete artifact

Formatting, unit tests, or a successful build create release confidence even though the migration plan, dependency record, runbook, or monitoring is missing. Define artifact completeness as part of the acceptance contract.

Provenance is added after the fact

Someone reconstructs the source revision and model name after release, but cannot recover the context, tools, environment, or intermediate decisions. Capture provenance during production and bind it to immutable artifact identities.

Release authority is attached to generation

The tool that can create a package can also publish or deploy it. Separate production, acceptance, release, and operation permissions. A productive agent does not automatically become a release authority.

Rollback is treated as a universal operation

The team assumes every change can be undone by reverting a commit. Data, permissions, external messages, infrastructure, and model or policy changes may require forward repair, reconciliation, or a compensating action.

No one owns the artifact after the task

The agent’s run is complete, but no team owns its dependencies, alerts, vulnerabilities, drift, or retirement. Require an accountable owner before an artifact becomes operational.

Research artifacts are judged like code

A report or experiment has citations and a clean pipeline, so it is treated as valid. Preserve datasets, methods, assumptions, versions, analysis steps, uncertainty, and review criteria. Reproducible execution is not the same as a supported conclusion.

Reviewing the artifact before release

Before an agent-produced artifact can be released, complete this stewardship card:

Question	Record
Why does the artifact exist?	Requirement, user or research purpose, design decision, and non-goals
What is in scope?	Files, resources, datasets, environments, dependencies, and affected owners
Who produced it?	Human, agent, model, runtime, tools, task, and source revision
What changed?	Diff, generated files, configuration, data effects, external calls, and open questions
Which inputs influenced it?	Context, instructions, examples, schemas, dependency versions, and freshness
What checks ran?	Tests, evaluations, security, policy, license, performance, migration, and reproducibility results
Who reviewed the meaning?	Domain, design, security, data, product, and service-owner decisions
What provenance is attached?	Artifact digest, source revision, build or execution metadata, dependencies, attestations, and signatures
Who may release it?	Release authority, environment scope, approval, timing, and policy decision
How will it be operated?	Owner, monitoring, SLOs, runbook, support path, and dependency watch
How will it be repaired?	Rollback, forward fix, compensation, data repair, restore, or retirement strategy
When does stewardship end?	Deprecation trigger, retention, archival, deletion, and successor artifact

The card turns “the agent made a change” into “the organization knows what this artifact is, what it claims, who may release it, and who will care for it.” The label “agentic engineering” may be absorbed into software, platform, or research engineering as agents become ordinary producers. The responsibilities on the card stay. Whether a person or an agent wrote the billing migration, the team still needs to know why it exists, which evidence supported its release, who operates it, and how it can be repaired.

Sources

NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: augments the SSDF with AI-specific practices, tasks, and considerations across the software development life cycle.
NIST Secure Software Development Framework: defines outcome-based secure-development practices and highlights provenance, change control, protection, production, and vulnerability response.
SLSA specification v1.2: organizes source and build supply-chain guarantees around tracks, levels, provenance, attestations, and verification.
SLSA Provenance: defines provenance as verifiable information about where, when, and how an artifact or source revision was produced.
SLSA Source requirements: describes source identity, change history, provenance, technical controls, review, and verification summaries.
in-toto: provides an open framework for making software supply-chain steps transparent, including who performed them and in what order.
Reproducible Builds definition: defines reproducibility as the ability to recreate bit-by-bit identical artifacts from the same source, environment, and build instructions.