Correctness
Reliability Boundaries in Browser Automation
Over the last few years I have worked across multiple layers of browser automation: building browser agents, infrastructure that runs them, authentication and session reuse, proxy behavior, and operational rules for production systems.
One thing became clear the more end-to-end systems I built: many automation failures are not purely model problems or tooling problems. They are boundary problems.
Automation systems operate across a chain that starts with the person building the system and ends with the website it interacts with.
Builder → Automation → Infrastructure → Environment → Website
Somewhere along that chain there is a point where the system stops being able to explain what happened when something goes wrong. That point is the reliability boundary.
Inside and Outside the Boundary
Inside the boundary, the system can answer: what failed, why it failed, and what can be done next. Outside the boundary, failures become opaque. The automation may still run, but when something changes, operators are left guessing.
Boundaries and Correctness
Correctness is not only producing the right output. A correct automation system must also understand when something has gone wrong and what to do next.
- attribute failures to a specific task input or assumption
- identify whether the issue is inside or outside the system responsibility
- describe the issue clearly to the next component or person in the chain
- provide a path to recover when possible
- record new failure modes so they become diagnosable later
When these capabilities exist, errors become useful signals. When they do not, errors become dead ends.
Learning From Boundaries
The more end-to-end systems I built myself, the fewer unsolvable automation problems I encountered. Not because problems disappeared, but because I controlled what the system was responsible for.
Instead of inheriting unclear boundaries from tools or infrastructure, I could decide what assumptions should be made, what should be verified, and what should happen when assumptions fail.
Once the boundary is well-defined, errors stop being just failures. They become signals about where the system needs more structure.
Connection to ZCA
Much of the later thinking behind Zero-Context Architecture came from this boundary-first view. At its best, ZCA creates tight boundaries around the exact task being solved so irrelevant state and hidden assumptions do not leak into execution.
Choosing the right boundary is not trivial. It requires deep domain understanding. But when chosen well, many automation problems either disappear or become much easier to diagnose.
Question for the Pages That Follow
Where does the system reliability boundary actually lie, and how does that boundary affect the people building and operating automation?
Deterministic Boundary Stack