BAP can give an agent a stable ref inside one browser session, like @e4. Close the browser and that ref is gone. uSEID is the layer I built for the next question: how does an agent find the same element tomorrow?
The problem shows up quickly. A page has three "Submit" buttons. Or the "Sign In" label changes to "Log In." Or a deploy inserts a "Sign Up" button above the old target. CSS and session refs do not give the agent enough identity to say, "this same element as before."
uSEID builds a signature from three signals:
| Signal | What it captures |
|---|---|
| Semantic | ARIA role and accessible name, like button "Sign In". |
| Structural | Ancestor roles, nearby labels, sibling context, and depth. |
| Spatial | Where the element appears in the viewport. |
Build phase: pass DOM and accessibility snapshots plus the target element. uSEID returns a JSON signature you can store.
Resolve phase: pass the stored signature and the current page snapshot. uSEID scores candidates, returns the best match, or abstains when the match is too weak or ambiguous.
build signature today
deploy changes the page
resolve signature tomorrow
return match or abstain The abstention behavior is the part I care about most. In browser-agent workflows, clicking the wrong element is usually worse than stopping. uSEID checks origin and path binding, role compatibility, confidence, and ambiguity before returning a target.
This is useful for monitoring, regression checks, multi-session workflows, and agent memory. If an agent learns that a specific control starts checkout, I want that memory to be a portable reference, not a brittle CSS path.