tonyww

6 ms·

1.
by tonyww 5mo ago
Browser use is a token hog
2.
Show HN: A 3-line wrapper that enforces deterministic security for AI agents
1 points by tonyww 6mo ago|0 comments
3.
by tonyww 7mo ago
AI agents currently operate on a flawed security model: they inherit the ambient permissions of the terminal they are spawned in. If an agent gets prompt-injected or hallucinates, a broad blast radius is guaranteed. I built predicate-claw t
4.
Show HN: Predicate-Claw – Run Time Assurance (RTA) for OpenClaw via Rust Sidecar(github.com)
2 points by tonyww 7mo ago|1 comments
5.
by tonyww 8mo ago
Yeah, that’s a pretty good analogy. The main difference is that the “tests” are predicates over live browser state and are often proposed alongside the plan on the fly, not written upfront by a developer. But conceptually it’s very close: m
6.
by tonyww 8mo ago
Absolutely agree on the compounding error point - that’s exactly what pushed us toward verification. On “verification wrong”: we try hard to keep predicates grounded and re-evaluated, not “check a cached handle”. Assertions do re-snapshot &
7.
by tonyww 8mo ago
It’s mostly the former: there’s a small set of generic checks/primitives, and we choose which ones to apply per step. The binding between “task/step” and “what to verify” can come from either: the user (explicit assertions), or th
8.
by tonyww 8mo ago
I’m absolutely not AI, I dedicate this morning to technical discussion with HN community on my post, which I’ve spent weeks building the technology behind it
9.
by tonyww 8mo ago
Totally agree - hybrid approaches can work well, especially on messy pages. We’ve seen the same tradeoff. On the verification side though, dynamic pages are exactly the reason why we scope assertions narrowly (specific predicates, bounded r
10.
by tonyww 8mo ago
Importance ranking is just a heuristic pass that scores/prioritizes elements (size, visibility, role, state) so the snapshot stays small and focused. It’s deterministic, not ML. The verification layer absolutely still exists without it
11.
by tonyww 8mo ago
The WASM pass is fully deterministic: it’s just code running in the page to extract and prune post-rendered elements (roles, geometry, visibility, layout, etc), no agent involved in the chrome extension . The “deterministic overrides” aren’
12.
by tonyww 8mo ago
Thanks — that’s exactly our motivation. The key shift for us was moving from “did the agent probably do the right thing?” to “can we prove the state we expected actually holds.” The property-based testing analogy is a good one — once you ma
13.
by tonyww 8mo ago
The accessibility tree is definitely useful, and we do look at it. The issue we ran into is that it’s optimized for assistive consumption, not for action verification or layout reasoning on dynamic SPAs. In practice we’ve seen cases where A
14.
by tonyww 8mo ago
A quick clarification on intent, since “browser automation” means different things to different people: This isn’t about making scripts smarter or replacing Playwright/Selenium. The problem I’m exploring is reliability: how to make age
15.
A verification layer for browser agents: Amazon case study(sentienceapi.com)
56 points by tonyww 8mo ago|19 comments
16.
by tonyww 8mo ago
Sorry for the misunderstanding, I intended to post it as news or engineering article, which is why I didn't include *Show HN* in the title
17.
by tonyww 8mo ago
Good question. On the surface, it does look very similar to the traditional scraper/script, but there's a subtle difference in where the logic lives and how failures are handled. A traditional scraper/script hard-codes select
18.
by tonyww 8mo ago
yes, the repo is publicly available: https://github.com/SentienceAPI/sentience-sdk-playground you can pull it and set up the dependencies including sentience API key, then run the main.py in the planner_executor_local
19.
by tonyww 8mo ago
One clarification since a few comments from coworkers/friends are circling this: Amazon isn’t the point here. We used it because it’s a dynamic, hostile UI, but the design goal is a site-agnostic control plane. That’s why the runtime a
20.
A verification layer for browser agents: Amazon case study(sentienceapi.com)
28 points by tonyww 8mo ago|8 comments
21.
by tonyww 8mo ago
A useful way to think about this: browser-use is the runner, Sentience is the assertion layer. Agents act → Sentience verifies. If you’ve built flaky E2E tests or agent demos that “usually work”, this is an attempt to make those workflows i
22.
Show HN: Browser-use, Qwen 2.5 3B, Sentience – Jest assertions for AI web agents
1 points by tonyww 8mo ago|1 comments
23.
by tonyww 8mo ago
One thing I didn’t emphasize enough in the post: I originally tried the “labeled screenshot + vision model” approach pretty hard. (see this screenshot labeled with bbox + ID: https://sentience-screenshots.sfo3.cdn.digitaloceanspa
24.
Show HN: Sentience – Semantic Visual Grounding for AI Agents (WASM and ONNX)
2 points by tonyww 8mo ago|1 comments
25.
by tonyww 9mo ago
Example JSON Response (Simplified): ``` [ { "id": 42, "role": "button", "text": "Add to Cart", "bbox": { "x": 935, "y": 529, "w": 20
26.
Show HN: Semantic geometry visual grounding for AI web agents (Amazon demo)
2 points by tonyww 9mo ago|1 comments