Launching today
Manifest
Turn any webpage into an action manifest for AI agents
133 followers
Turn any webpage into an action manifest for AI agents
133 followers
Manifest turns any webpage into a structured JSON map of what an AI agent can click, fill, and submit. One API call, no fragile selectors. Every action comes with resolved CSS/role locators, plus a requires field that encodes dependencies between elements (e.g. "select a plan before this button is clickable"). That's context aria snapshots don't give you. Python SDK, LangChain support, and an MCP server included. Built for anyone shipping browser agents.
Manifest
The requires field is the part that sets this apart from an aria snapshot — encoding "select a plan before this button is clickable" is exactly what breaks naive agents. Two setup questions: since it is one API call per page, when my agent fills a field and the SPA re-renders, do I re-call Manifest for a fresh manifest each step, or does it hold a live session that diffs the DOM? And is that requires graph inferred from static DOM heuristics, or does it probe actual element state — I am thinking of a checkout where submit only unlocks after async server-side validation, not just after a sibling select changes?
Manifest
@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 <select> 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.
Treating requires as known preconditions rather than a guarantee, and keeping a retry/wait around submits, is a clear enough contract to code against. On the stateless re-call: since every extraction is a Playwright pass plus a Sonnet call, is there any caching keyed on a DOM hash so an unchanged page state returns the cached manifest instead of re-running inference? A checkout is five or six calls where most of the page is identical each time, and that cost is what would decide whether I call it per step or batch around it.
The requires field that encodes element dependencies is the part that actually matters. We've hit ordering issues where submitting before filling a required predecessor causes silent failures that are painful to debug. How do you handle SPAs where element availability changes based on async state not yet reflected in the DOM at snapshot time?
Manifest
the requires field is the clever part here, most of these tools stop at "here's a button" and skip the ordering constraints entirely. how do you actually detect those dependencies though - is it driving the page and observing which elements become clickable after which actions, or some static analysis of the DOM/JS? asking because sites that gate steps behind async validation (like a plan check that hits an API before enabling the button) seem like they'd be hard to catch without actually executing the flow.
Manifest
@omri_ben_shoham1
Right now it's static DOM signal inference, not driving the page — that's the honest limitation. When Playwright pulls the page, I capture things like disabled/aria-disabled attributes, which fields sit in the same form as a disabled element, and which required fields map to which submit button. Those signals get handed to the LLM extraction step along with the accessibility snapshot, and it infers requires from there (e.g. "this submit button is in a form with these three required fields" → requires: [field_a, field_b, field_c]).
So it catches the common cases — disabled-until-valid buttons, forms with required fields — but you've correctly identified the gap: anything gated behind async JS validation (a plan check hitting an API before enabling a button) is invisible to this approach if the element doesn't expose it via disabled/aria-disabled in the initial DOM snapshot. No custom validation logic execution, so it can miss dependencies that only manifest through JS side effects rather than DOM state.
The more accurate version would mean actually driving the flow — filling fields, watching what enables/changes — but that's a much heavier (and slower/costlier) operation than a single-page snapshot, so it's a real tradeoff, not just an oversight. Right now requires is explicitly best-effort: good enough to unblock naive agents on the common patterns, not a guarantee.
The MCP server integration is a nice touch for getting started quickly. One thing that would really help in production is some kind of caching layer for repeated calls to the same URL, since right now it seems like every API request would re-scan the whole page. Even just an optional ETag-style header so we can skip re-mapping when the page structure hasn't changed would save a ton of tokens and latency when agents are looping through tasks on stable sites.
Manifest
Turning any webpage into an action manifest for agents is a clever abstraction. How does it handle pages that change their DOM structure frequently — does the manifest need to be regenerated, or does it adapt automatically?
Manifest
@max_nordstrom Ah, a 6-hour TTL makes sense as a balance between freshness and not re-scraping constantly. Is that TTL configurable, or fixed for all users right now?
Manifest
@ark_y_k
Fixed for everyone right now, no per-user config. It’s the kind of knob I’d rather add once someone actually hits a case where 6 hours is wrong for them, rather than guessing at the right defaults upfront.
Congrats on the launch. The action-manifest idea is useful because browser agents usually fail on hidden state, auth changes, or brittle selectors. How do you encode uncertainty or required preconditions when a page changes after the manifest is generated, and can developers inspect why an action was skipped?
Manifest