A task rarely respects the boundaries between apps. A meeting moves, a message needs context from the calendar, or a shopping request ends with a checkout in another service. People understand these as one piece of work. Software often turns them into a series of separate screens, each with its own controls and its own way of describing the next step.
Surf starts from the task rather than from a single destination. It is an Android assistant that can read the screen through Accessibility and act in apps, a cloud browser or connected services. The idea of one brain is a way of describing that continuity: the request remains the centre of the work while the available route changes around it.
Start with what the person means
“Move this meeting to later” contains an intention, a reference and a missing detail. The intention is a change to a calendar event. The reference is the meeting on the screen. “Later” may need clarification. A useful assistant needs to keep those pieces distinct instead of replacing a vague instruction with a confident guess. Screen context can help identify the subject; it does not automatically answer every question.
The same reasoning applies when the person draws around an item. The drawing gives the request a location. It can make “this one” easier to interpret without requiring the person to type a long description. Text, voice and drawing are different ways into the same task. The assistant still needs to connect the input to the intended outcome and notice when a detail remains uncertain.
The task should stay coherent even when the interface changes.
Choose the route that fits the task
Surf can work in the app on the screen, use a cloud browser or act through connected apps. Those are routes to an outcome, not reasons to ask the person to reformulate the whole request. A service connection may provide the relevant action. A visible app may be the place where the person is already working. The route depends on access and the task in front of Surf.
Connectors bring another part of the picture into reach. Surf connects to 1500+ apps through Composio, with access depending on the service and permissions granted. That number is a description of connection breadth, not a promise that every action in every app is available. A coherent assistant should make the relevant boundary understandable when it affects what can happen next.
Reuse a pattern, not a person's private life
The phrase “learns from each task” needs care. It should not be read as permission to train a model on private messages, passwords or personal screen content. Surf does not train on user data. Passwords and OTPs use secure input and are never sent to the model. Those boundaries belong in the explanation, not in a footnote beneath an exciting claim about learning.
This research direction is about how general task patterns might inform better assistance: identifying the intended object, noticing a missing constraint, selecting an available route and checking an outcome. These are reusable questions. The personal details that happen to appear during a task are something else. This draft does not claim that a particular cross-user learning system or retention mechanism has shipped.
Skills make a repeated intention explicit
A Skill gives the person a way to describe work they want to use again. Rather than hoping that an assistant infers a hidden routine, the person can ask Surf to build a Skill from a sentence. For example, turning meeting notes into a follow-up is a recognisable piece of work with an input and a desired result. Giving it an explicit form makes the repeat easier to discuss.
Automations address the timing of a routine. The person describes what should happen and when; Surf builds and runs it. This does not remove the rule around spending. Any action that spends money still needs approval. A useful repeat preserves the important constraints of the task instead of treating familiarity as a reason to stop checking them.
Continuity needs a visible result
A conversation can feel continuous while the underlying work is still incomplete. Moving between apps is not, by itself, success. The important question is whether the requested outcome happened. A calendar opened is not necessarily an event changed. A basket filled is not necessarily an order placed. The final explanation should match the state of the task, including any step still waiting for the person.
This distinction is particularly important when a service changes or a permission is missing. The assistant should be able to describe the boundary in terms of the task: what it could do, what remains and what information or action would help. A polished sentence cannot substitute for that clarity. A useful assistant needs to remain understandable at the moment its preferred route stops working.
One conversation, many surfaces
The long-term value of a general assistant is not that every app becomes identical. Different tools will continue to have different strengths and constraints. The opportunity is to let the person keep the purpose of the task intact while Surf helps with the details of moving through those tools. The interface should make that continuity feel practical, not mysterious.
For now, this is a draft about the direction behind Surf's Skills, Automations, screen context and connections. It separates what Surf does from questions still being explored. One brain is a useful shorthand only if the product remains clear about access, secure input, approval and outcomes. The person should be able to follow the work even when more than one app is involved.
Draft for review. Examples are illustrative; no metrics, customer quotations or research results are claimed.
Back to the notebook ↗