"Works on My Machine" Now Includes the Agent's Machine

The agent ran the test. The result was green. Another engineer checks out the branch and cannot get the application to start.

That hypothetical handoff doesn't require the model to have lied. It may have accurately described a result from an environment the next person does not have.

I think the useful question is what made that result possible: runtime, installed artifacts, configuration, test data, processes and state. A commit identifies code. It doesn't identify all of those inputs.

AI-assisted development doesn't invent this old problem. It adds more environments that can appear, validate work and disappear before a teammate sees them.

A worktree isn't a complete environment

A separate Git worktree is useful for isolating source changes. It doesn't automatically isolate ports, databases, home-directory configuration, credentials or services shared by several tasks.

Two branches can be separate on disk while their tests talk to the same local service. One session can migrate a database the other expected to remain unchanged. A process started earlier can serve a different revision from the files currently being inspected.

The agent may see a healthy page without establishing which server produced it.

I would identify the actual application instance, its revision and its relevant configuration before using an interaction as evidence. That can be a build identifier, an explicit process path or another practical observation. It need not become a ceremony after every refresh.

The current GitHub application card describes ephemeral environments for its cloud agent and distinguishes them from local execution. Those are meaningful differences in lifecycle and access. They are not a promise that every tool called an agent runs in the same reproducible container.

The lockfile is necessary evidence, not the whole story

A manifest expresses requested dependencies. The lockfile records a more specific resolution. The installation on disk is the artifact the process actually loads.

Those can disagree because of a stale installation, workspace linking, local tarballs or generated output. An agent can make a correct diagnosis of the code it loaded while the committed project still produces something else.

The versioned npm 11 documentation for npm ci makes its frozen-install behavior explicit: it requires a lockfile, rejects manifest/lockfile disagreement and doesn't rewrite those inputs. It also says tree-shaping flags used when creating the lockfile must be supplied consistently.

I wouldn't present that as a universal command for every package manager or npm release. Use the repository's supported install path and actual tool version. The point is to make dependency reconstruction deliberate rather than inherit a convenient node_modules directory.

A clean installation still depends on artifact availability, platform support and permitted lifecycle scripts. A lockfile cannot provide an unavailable private package or a native library missing from the host.

Reproducible dependency selection is one boundary. Reproducible execution is larger.

Configuration needs a contract without exposing its values

An agent's environment might contain an environment variable that makes a service reachable or silently selects a mock. A fresh checkout may not.

I would document required configuration names, their purpose, safe defaults and how an authorized person obtains them. I would not copy secret values into a PR, task record or agent transcript to make the handoff convenient.

Missing configuration should fail visibly where appropriate. A fallback to a mock can be useful for local tests, but it must remain distinguishable from a real integration check. Otherwise a working simulation can be reported as evidence about a system it never contacted.

Build-time and runtime settings also differ. A browser bundle may already contain a selected public setting even after the environment changes. Checking the shell's current value doesn't establish what the built application uses.

This is why I want configuration provenance, not a dump of configuration. The next engineer needs to recreate the intended conditions without inheriting sensitive information they don't need.

Test state can be the hidden dependency

Consider an illustrative account-management test that passes only because a user record was created manually in an earlier session. The fixture isn't in the repository. The setup step isn't in the task notes.

The agent's test result can be real and the validation can still be nonportable.

I would prefer explicit fixtures with controlled ownership and cleanup. If a shared environment is unavoidable, record the relevant preconditions and limits. Don't reset shared state merely because it would make the current task easier.

Time, locale, timezone and network responses can also influence results. Not every test needs a simulated clock or a hermetic network. But a result used to justify a behavioral claim should identify the inputs that decide it.

The same caution applies to retries. A flaky success after several attempts isn't equivalent to a stable result, and an agent shouldn't erase the failed attempts from the explanation.

Caches deserve similar treatment. A warm cache can make a path work that a first-time user cannot complete. A stale build cache can preserve implementation bytes the source no longer describes.

Record a reconstruction path, not an entire machine

For a meaningful handoff, I would keep a small environment record alongside the evidence: relevant revision, runtime and package-manager versions, install procedure, configuration contract, fixture setup, and the exact check performed.

That is a proposal for useful evidence, not a requirement to archive every process and environment variable. Excessive collection creates privacy and maintenance problems of its own.

The record should also say what was not reconstructed. An unavailable external provider, a mocked payment step or a local-only service is a limitation, not an embarrassing detail to hide.

I would check the reconstruction in a fresh authorized environment when the risk justifies it. The aim is to remove accidental dependencies, not to claim that a clean checkout guarantees production behavior.

A container image can package more of the environment. It still needs controlled inputs, external contracts and an explanation of which mounted files or services sit outside it.

The evidence should survive the session

My green-checks article asks what a check actually established. Environment provenance makes that question answerable after the agent's session ends.

An ephemeral runner is useful precisely because it doesn't preserve incidental state forever. That also means useful setup and result evidence must live somewhere appropriate before the runner disappears.

There is a balance here. I don't need a permanent recording of every terminal screen. I need enough non-sensitive information to understand and repeat the decisive check.

If the only reconstruction method is asking the original agent to remember what it did, the environment hasn't really been handed off.

Leave the next engineer a smaller mystery

I want agents to validate their changes. I also want validation to leave something more durable than the sentence that it worked.

The handoff should help another engineer distinguish a code defect from a missing setup step, a dependency-resolution difference from a changed requirement, and a mocked success from a real integration result.

That is ordinary engineering discipline, made more important by the number of disposable workspaces we can now create.

When an agent finishes a task in your environment, which part is hardest to reproduce afterward: the dependencies, the service state, or the exact conditions of its checks? I'd be curious what you preserve and what you deliberately avoid collecting.