商业产业 Product Hunt 2026-07-20T03:28 正文 ok 224 words

Manifest

英文标题:Manifest

Turn any webpage into an action manifest for AI agents Discussion | Link
打开原文相关 2.7 · 机会 1
media1.2 KB media4.6 KB media5.5 KB media21.5 KB media20.1 KB media9.6 KB media887 B media564 B media609 B media646 B media1.2 KB media860 B

中文

Turn any webpage into an action manifest for AI agents Discussion | Link

中文全文翻译正在补齐,可先查看下方英文原文。

English / 原文

@noctis06

Great questions, both go right at the current limitations.

Re-fetching: Right now it’s stateless — one call per page state. When your agent fills a field and the SPA re-renders, you call Manifest again for a fresh manifest. There’s no live session that diffs the DOM for you yet. That’s a real cost (extra round-trips mid-flow), and it’s the explicit next layer on the roadmap — a stateful hosted session that would track re-renders without a full re-extraction each time. Not built yet, so today: re-call after any state-changing action.

Re: how requires is derived — it’s inferred, not probed. The pipeline extracts structure via Playwright + DOM analysis, and an LLM (Claude Sonnet) resolves the dependency relationships from that static snapshot. It’s not driving the page to trigger async server-side validation and observing what actually unlocks.

So your checkout example is the honest limit: if “submit” only enables after a server round-trip validates something (not just a sibling changing client-side), Manifest’s requires won’t currently capture that — it’ll reflect what’s inferable from DOM/state at extraction time, not runtime async gating. For agents, that means requires tells you the known preconditions, but you still want a retry/wait pattern for submit actions rather than treating “requires satisfied” as “guaranteed clickable.”

Appreciate you pressure-testing this — it’s useful signal for prioritizing the stateful-session layer.