Launching today
Manifest
Turn any webpage into an action manifest for AI agents
145 followers
Turn any webpage into an action manifest for AI agents
145 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.
Manifest
@noctis06
No DOM-hash keying today — the cache is TTL-based (6 hours) and keyed on URL, not on page state, so it doesn't know two calls mid-checkout are 90% the same page. It'll happily re-run the full Playwright + Sonnet pass each time, even if only the field you filled actually changed.
That's a legitimate gap for exactly the case you're describing — a five-or-six-step checkout where most of the DOM is static and only a fragment moved between calls. A content-hash-keyed cache (or something coarser, like hashing the interactive-elements list rather than the full DOM) would let an unchanged page state short-circuit straight to a cached manifest instead of paying for inference again. Right now that cost is real and undifferentiated — every call is priced like a first extraction, whether it's step 1 or step 6.
Given that, I'd say batch around it for now rather than assume per-step calls are cheap: call fresh when something structurally meaningful changed (new modal, new form section), not reflexively after every field fill. Not a great answer, but the honest one until change-aware caching exists.
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
Really cool approach, the requires field for dependencies is a smart solve. One thing that would make this even more useful for us is a built-in way to record and replay the exact sequence of agent actions against a stored map, so we can diff when a site changes and pinpoint exactly which locators broke. Would save a ton of debugging when a flow stops working after a deploy.
Manifest
@emelkorkune7b0
Thanks — and that's a sharper version of a gap that's come up a few times here: right now every /manifest call is a stateless snapshot with no memory of a prior run, so there's no built-in way to say "here's the sequence that worked, tell me what changed."
A record-and-replay layer — capturing the sequence of manifests an agent actually used for a flow, then diffing a fresh run against that stored baseline — would turn "the flow broke after a deploy" into a direct answer (this locator no longer resolves, this action disappeared) instead of a manual hunt through logs. That's genuinely more useful than a plain diff endpoint since it's tied to the actual path your agent took, not just any two arbitrary snapshots. Noting it as a real direction, closer to a CI/regression feature than a runtime tweak.
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.
@max_nordstrom That's a reasonable trade-off — building for a real pain point beats guessing every time. Makes sense to keep the surface area small until there's clear demand for it.