On April 6 I 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 me to launch Chrome.

The fix that morning was a tooling swap, and I wrote that story up separately. This post is about what I noticed after the fix landed, which is the more useful thing. The browser had not been Claude’s. It had been mine, on loan, with a setup ritual nobody had written down. Once I saw that, I started seeing it everywhere.

the ownership question I had not been asking

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 me, and I don’t notice, because I 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 me, the run will stop and wait by design.

I had not framed it that way. I had been treating “Claude needs me to launch Chrome first” as a small inconvenience. It was actually a design statement: the browser belongs to me. The agent is a guest in the browser I open. If I 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 test that surfaces the seam

The seam is not visible from inside a working session, because while everything is running you can’t tell which side is owning what. The test is to ask: if I walked away right now, what would have to happen for the run to finish without me?

Run that test against every tool the agent touches. Here is the audit I now run, 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: 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 I was loading by hand before certain scripts ran, the answer was: the runtime needed a documented, approved way to obtain it. The credential was effectively in my fingers rather than in a managed execution path.

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

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

the language that hides the problem

The phrase that hides this is “agent workflow.” It suggests the agent runs the workflow. Most of the time it does not. Most of the time 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, the kicking-off of the next stage. The agent is a power tool. The operator is the carpenter.

ownership transfers feel like nothing

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

What changed was who held the lifecycle. The browser integration used in this setup managed its own process, startup, session, and cleanup rather than requiring a port and flags I had to remember. The ownership moved from me to the supporting server. From outside, the functional surface looked almost identical.

Inside the run, what changed is that the run finished without me. I queued the batch of review tickets. I went to do something else. The summary appeared. That had never happened before.

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

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

what this generalizes to

The lifecycle-ownership question became a useful lens for agent infrastructure because it turns an abstract design debate into a concrete dependency check.

It helps evaluate tool integrations: an integration 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.

It 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 half.

For each dependency, name the lifecycle owner and make the handoff explicit. Notice every place that ownership still quietly rests with a human, then decide whether that is an intentional approval point or an unattended-workflow gap.