An assistant that works on a phone operates in an environment it does not own. Screens change. A keyboard covers a button. A service asks for authentication. An item disappears between a search and a checkout. The interesting reliability question is not whether a demonstration can follow a neat path once. It is whether the assistant can remain useful when the path is no longer neat.
Surf reads screen context through Android Accessibility and can act inside apps, a cloud browser or connected services. Each route brings different constraints. This draft sets out the product and engineering questions behind reliable assistance. It is not a report of measured success rates or a claim that every recovery path has already been solved.
Observe the state before choosing a step
A screen is evidence about what is possible now. It might show a list, a dialog, a form or an error. Before acting, the assistant needs to connect that evidence to the user's request. A familiar-looking button is not enough: it matters which object the button affects and whether the surrounding screen matches the task the person actually asked for.
Screen context makes that grounding possible, but access is not the same as understanding. Accessibility permission allows Surf to read and act on screen content. The person controls that permission in Android Settings and can revoke it. If the relevant information is unavailable, a useful assistant should work within that limit and make the missing step understandable rather than acting as if the screen were fully known.
A confident reply is not evidence that a task is done.
An action should answer a specific question
It helps to think about an action in terms of the change it is meant to produce. Opening an event should expose its details. Choosing a time should change the selected value. Saving should leave evidence that the change was accepted. These examples are design questions, not a fixed implementation recipe. They make the relationship between a tap and a goal easier to inspect.
The alternative is to treat a sequence of inputs as proof of progress. That is fragile. A tap could hit a different control after the layout moves, or a request could arrive while the service is still loading. The intended effect matters more than the fact that an input was attempted. The assistant needs a reason to believe it has reached the next useful state.
Check the outcome, not the confidence
Natural language is good at making a story sound complete. A reliable agent needs a stricter standard. “Done” should describe an observed outcome that matches the task. If the evidence only shows a prepared basket, the assistant should say that. If a payment is waiting for approval, that is the current state. A polished reply cannot turn either situation into a completed order.
For the person using Surf, this is a practical issue. They may move on with their day based on the result they are shown. The explanation should distinguish between work completed, a decision waiting for them and something the assistant could not finish. That distinction is more useful than a generic success message, even if it means the final answer is less satisfying in the moment.
Some interruptions are deliberate boundaries
A password prompt is not simply another obstacle to automate past. Passwords and OTPs use secure input and are never sent to the model. The person may need to take part in authentication. The assistant should preserve that boundary and avoid asking for a secret in ordinary chat. Handling the interruption carefully is part of the task's correctness.
Payments have another explicit boundary. Surf asks before anything that spends money, showing a pay card for the person to review and tap to approve. A routine does not make that approval optional. Nor does the user's original request settle details that only become visible at checkout. Reliable behaviour includes stopping at the right moment, with enough context for the person to decide.
Make uncertainty actionable
“Something went wrong” describes a feeling, not a next step. When assistance stops, the explanation should help the person understand what remains. Did the relevant app need access? Was an important detail missing? Is a payment waiting for approval? Those situations call for different responses. Surf should not compress them into a single reassuring line that hides the distinction.
The same principle helps people report problems. A useful account includes the app, the request, the observed result and the expected result. Private information is not needed to describe most of that structure. On this website, the support form is explicitly a preview and does not send a request. Showing that limit clearly is a small example of the honesty an agent needs at larger scale.
Test more than the happy path
A convincing evaluation needs to ask what happens when the environment changes. A slow screen, an unavailable item, a missing permission or an ambiguous instruction can reveal weaknesses a clean demonstration misses. The important question is whether the assistant's action and explanation remain appropriate to the evidence. Completing every task is not the only useful outcome; a clear and safe handoff can be correct too.
This article does not attach invented numbers to that ambition. Surf's reliability has to be judged through real tasks and observed results, with the limits reported alongside the successes. The goal is straightforward: help people complete ordinary work without making them guess what happened. Observe carefully, act toward a specific result, and check before claiming the task is done.
Draft for review. Examples are illustrative; no metrics, customer quotations or research results are claimed.
Back to the notebook ↗