StareBrain

StareBrain's goal is not to build the most capable Agent, but an Agent that "doesn't make you feel like you're talking to something that doesn't know you."

StareBrain's key design decision is that the Agent must resolve parameters from device context before action dispatch, rather than during dispatch or by asking the user afterwards.

Before each action dispatch, StareBrain sets up a ContextResolver step that receives the raw intent and device context and attempts to fill in missing parameters before exposing information to the user.

StareBrain's resolution results fall into three handling paths: high-confidence parameters are filled in automatically; medium-confidence parameters are presented as pre-filled suggestions for the user to confirm or modify; unresolvable parameters are marked as missing and the user is asked.

StareBrain follows the principle "never ask for information the phone already knows," and requires the resolver to return UnresolvedParameter rather than fail silently when it cannot resolve.

StareBrain defines four confidence levels, HIGH, MEDIUM, LOW and UNRESOLVABLE; each parameter value carries a confidence level and source information (ContextSource), which together determine auto-fill, pre-fill confirmation or asking the user directly.

StareBrain's system runs entirely on the device, and no context data leaves the phone; this is a hard constraint of the architecture rather than a preference.

Because the full device context cannot be uploaded, StareBrain cannot use cloud models to reason over the complete context; the resolution logic must be sufficiently deterministic and lightweight to run locally, and must clearly state which signals were used and how they were weighed.

StareBrain's context resolution solves the "should have known" problem at the level of structured data, but does not address open-ended inference (such as "what would I usually do here") or cross-app state that requires actively reading App content.

During beta testing, the StareBrain team repeatedly received complaints from users that the phone AI assistant asked them to re-provide information already stored on the device (such as calendars, contacts, location history, and airline confirmation emails in the inbox).

StareBrain splits the context needed by an on-device AI Agent into two categories: action context (describing the user's requested action, its parameters and the App that can complete it) and device context (information the phone already knows, such as upcoming calendar events, saved locations and recent search history).

StareBrain uses a data structure called AgentContext to aggregate action context and device context, in which DeviceContext includes upcoming events, saved locations, recently used Apps and active notification summaries.

According to StareBrain's technical analysis, in device-side actions, after the accessibility layer confirms the UI operation has been triggered, whether the downstream service provider has recorded that operation belongs to another clock, and the gap between the two clocks is the source of duplicate dispatches.

StareBrain enforces the structural invariant through the tryAccept() method: only when delivery == CONFIRMED is the acceptance state allowed to transition from PENDING, otherwise an exception is thrown.

StareBrain's ActionRecord persists actionId, dispatchId, providerObjectId, the two state enums, and three timestamps together.

StareBrain proposes a dual-axis state model: every action that produces an observable artifact tracks two independent states, with DeliveryState answering whether the artifact exists and AcceptanceState answering whether the artifact is correct.

The common failure chain StareBrain reconstructs is: Agent dispatches an action → the dispatch times out before arrival is confirmed → the system does not see the SUCCESS marker → it is judged as a failure → a retry is triggered → the second dispatch produces a duplicate.

In the StareBrain case, "the most recent experience where you felt something should have been done automatically" is a typical critical-incident question: it anchors the time in the past and the scenario in specific operations, thereby bypassing hypothetical bias.

The StareBrain team completely stopped using "would you use this" to validate features; every user research conversation now begins with a story prompt and ends with a spend-or-effort question.

While developing an Android on-device AI agent, the StareBrain team wasted a great deal of time because it used hypothetical questions for user research.