Manifest
英文标题:Manifest
Turn any webpage into an action manifest for AI agents Discussion | Link
1.2 KB
4.6 KB
5.5 KB
21.5 KB
20.1 KB
9.6 KB
887 B
564 B
609 B
646 B
1.2 KB
860 B
中文
Turn any webpage into an action manifest for AI agents Discussion | Link
中文全文翻译正在补齐,可先查看下方英文原文。
English / 原文
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.