On April 6 we sat down to run a batch of review tickets through an agent loop, and for the third time that week the agent stopped to ask us to launch Chrome.

The fix that morning was a tooling swap. What matters more is what we noticed after it landed. The browser had never been Claude’s. It had been ours, on loan, with a setup ritual nobody had written down. Once we saw that, we started seeing it everywhere.

Who owned the browser process

For every tool an agent uses, somebody owns the lifecycle: spawning, configuring, cleaning up, restarting after a crash. In a normal dev loop that owner is us, and we don’t notice, because we have hands on the keyboard the whole time.

In an unattended agent loop, the lifecycle needs an owner other than the human at the keyboard. That may be the agent, a tool server, an orchestrator, or a managed service. If it still depends on us, the run will stop and wait by design.

We had not framed it that way. We had been treating “Claude needs us to launch Chrome first” as a small inconvenience. It was actually a design statement: the browser belongs to us, the agent is a guest in the browser we open, and if we forget, the workflow halts.

That is a perfectly fine model for a developer using an IDE. It is the wrong model for autonomous work.

The walk-away audit

The seam is invisible from inside a working session, because while everything is running you can’t tell which side owns what. So the test is a question: if we walked away right now, what would have to happen for the run to finish without us?

Run that against every tool the agent touches. This is the audit we now use, with the fix each failing answer points to:

The walk-away audit (run per tool in the loop)


For every tool the agent touches, ask one question and act on the answer:


  "If I walked away right now, what would have to happen for this run to finish without me?"


  Browser     -> a tool server or orchestrator must launch and manage it.
                 Fix: use an integration that owns its browser process rather
                 than depending on a browser the operator starts manually.
  Credential  -> a managed runtime or secret store must supply it.
                 Fix: load it through an approved secret-management path at
                 runtime, never from shell history or copied commands.
  Directory   -> the runtime must create or verify it. Fix: create required
                 paths at startup instead of assuming a one-time manual setup.


If any answer is "the human does it," that tool is owned by you, and the loop
cannot run without you. Move ownership, then re-run the question.

For the browser, the answer that morning was that some supporting process would need to launch it with the right configuration. Nothing in the loop owned that long-running browser process, so the run halted at the first navigation.

For a credential we were loading by hand before certain scripts ran, the answer was that the runtime needed a documented, approved way to obtain it. The credential was effectively in our fingers rather than in a managed execution path.

For a directory our scripts assumed existed because we created it once on this machine months ago, the answer was that the agent would have to know to create it. It could not. The knowledge was in our history.

Three things. None of them documented. All of them ours.

The phrase that hid it

The phrase that hides this is “agent workflow.” It suggests the agent runs the workflow. Most of the time it does not. The operator runs the workflow and the agent runs the executable steps inside it, while the operator handles the surrounding setup, the recovery from minor failures, and the kicking-off of the next stage. The agent is a power tool. The operator is the carpenter.

What the ownership transfer looked like

The Playwright switch took a morning. The functional surface barely changed. Claude opens browsers, fills forms, takes screenshots, the same as before, and from the outside you’d see the same screenshots in the same admin pages.

What changed was who held the lifecycle. The browser integration in this setup managed its own process, startup, session, and cleanup, so there was no port and no flags for us to remember. Ownership moved from us to the supporting server.

Inside the run, the difference was that it finished without us. We queued the batch of review tickets, went to do something else, and the summary appeared. That had never happened before.

The credential fix had the same shape: out of our fingers and into an approved runtime-managed secret path. The directory fix was similar, since the runtime now creates the directory if it is absent. Both removed an unacknowledged human setup step.

Each change was small. Together they closed the unattended loop for the tasks we had handed it, because every required dependency now had an explicit non-human lifecycle owner.

Using the question on everything else

The lifecycle-ownership question turns an abstract design debate into a concrete dependency check.

It helps evaluate tool integrations: one that can manage or clearly declare its required resources may fit an unattended loop better than one that relies on operator setup. It also helps evaluate scripts for scheduled execution. A script is a stronger candidate when it can start from a documented clean environment with its dependencies and authorized secrets available.

If walking away breaks a workflow because an undocumented human step is missing, it is not yet unattended automation. It is a procedure with a memorized prerequisite.

The question also tells you what to write down. The setup steps you do by reflex are the ones that aren’t in any document, because you stopped noticing them years ago. Those are the exact steps an agent has no way to learn. Writing them down is the first half. Moving them out of your hands is the second.

Name the owner

For each dependency in an agent workflow, name the lifecycle owner and make the handoff explicit. Wherever ownership still rests with a human, decide whether it is an intentional approval point or a gap that stops unattended work.