---
title: "What Three Stopped Batches Taught Us About Who Owns Chrome"
canonical: https://dxdev.com/everyday-ai/step-i-had-been-doing-without-noticing/
datePublished: 2026-04-06
---
Three times in one week, a batch of review tickets stopped before it got very far. There was no flashing warning or broken screen. The task simply asked us to open Chrome.

At first we treated that as a small favor. Open the browser, get the work moving, carry on with the day. It was easy enough that we did not see the problem. But the work could not continue unless one of us was there to do the same little ritual. A task that is supposed to keep moving on its own was waiting at the starting line for us to turn a key.

By the third stop it had cost more than a few seconds. It had taken our attention, then our patience, and finally a morning to make a better change. Our first approach had never been a fix. It only got one session past the point where the next session would stop again.

## Who was responsible for the browser?

That was the question underneath the request. There is a technical phrase for it, **lifecycle owner**. It sounds bigger than it is. It means the person or system that gets something ready, keeps it running, and cleans it up when the job is done. A pot on the stove has one. Somebody turns on the burner, checks it, and turns it off. The pieces of a computer task work the same way, even when most of the work looks automatic.

In our case the browser was ours. We had to start it with the right setup, and only then could another program use it. The task was not in charge of that step. It was borrowing something we had prepared. If we walked away before opening Chrome, the work stopped exactly as it was designed to stop.

## The same question, asked of everything else

Once we saw that, we asked it of the other things the task needed. If we walked away right now, what would have to happen before this finishes without us?

The answers were awkwardly familiar. A credential was being loaded by hand before some scripts ran. In plain English, the program needed proof that it was allowed to do its job, and that proof was living in our routine instead of in an approved path the runtime could use. A folder also had to exist. We had made it on that machine months before, then forgotten we had ever made it. The task could not know that history.

So three small things were holding up the whole run: a browser, a credential, and a folder. None of them had been written down as a requirement. All three depended on us doing something we did so often that we barely noticed it.

That is an easy trap. We get good at our own work by building shortcuts in our heads. We remember which window to open first. We know where a file belongs. We know which little problem goes away with one quick click. The trouble starts when a task is meant to continue after we leave the room. What feels like common sense to us is an invisible locked door to everything else.

## What we changed

From the outside, the work did not look much different. The browser still opened pages, filled in forms, and took screenshots. The difference was underneath. The browser setup could now start and manage its own process, session, and cleanup. The credential moved out of our hands and into an approved path the runtime manages. The runtime also creates the folder when it is missing.

Those changes sound small because they are small. Nobody had to invent a new kind of work. The needed pieces simply stopped depending on our memory and our presence.

After that, we queued the batch of review tickets and went to do something else. The summary appeared later without another request for us to come back and open something. That had not happened before.

## It is not really about browsers

The lesson has nothing to do with whether a job uses a browser or a computer helper. A payroll report that only works when one person remembers a spreadsheet trick has the same weakness. So does a landscaping schedule that only one person knows how to update, or a family bill that gets paid only because somebody remembers which drawer holds the account number. The work may look regular, but it is being held up by a person-shaped gap.

One browser, one credential path, and one folder were the whole obstacle. None of them needed a new invention to fix, only a transfer of ownership away from our memory. If a job only works when someone remembers a step, that step is a missing requirement, and it belongs on the list before the job is ever called unattended.