Launched this week
Manifest
Turn any webpage into an action manifest for AI agents
176 followers
Turn any webpage into an action manifest for AI agents
176 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
That's the honest answer I'd rather have than an optimistic one — batch on structural change, don't re-call per field. The catch is knowing a structural change happened without paying for a full extraction to find out. Would a cheap fingerprint endpoint help here — one that returns just a hash of the interactive-elements set, so my agent compares cheaply and only triggers the full Playwright+Sonnet pass when that fingerprint moves? Even coarse, it'd let me avoid both reflexive re-calls and missing a new modal.
Manifest
@noctis06
That's a well-targeted ask — you're right that "batch on structural change" only works if detecting the change is cheap, otherwise you've just moved the cost around instead of cutting it.
A fingerprint endpoint is a genuinely feasible shape for that: something that skips the Sonnet call entirely and just returns a hash of the interactive-elements set from the Playwright pass, so your agent can compare cheaply and only trigger the full extraction when it actually moves. Even coarse, that's a real win — it turns "did anything change" from a full-price question into a near-free one, and a new modal appearing would show up as a fingerprint change even before you know what's in it. Worth thinking through as a lighter-weight companion endpoint alongside the main one rather than folding it into /manifest itself.
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.
@max_nordstrom — the framing that browser automation hands you "a browser" and extraction hands you "the content," but nobody was giving agents the affordance layer — what's clickable/fillable and in what order — nails a gap I keep hitting.
I've spent too many hours babysitting hand-written selectors across checkout flows that break the second a merchant reships their DOM, so a requires graph that encodes "fill this before that submit unlocks" is exactly the primitive I kept wishing existed.
One thing I didn't see raised: since the manifest comes from a server-side Playwright pass, how does it hold up on bot-protected sites? A lot of the checkout surfaces I care about sit behind Cloudflare/Akamai/HUMAN, and a headless extraction is exactly what they tend to block — does Manifest still get a clean map there, or is that the current edge of what it can reach?
Either way, love that your replies here are upfront about static inference vs driving the page. 👌
Manifest
@akbar_b
Thanks, Akbar — and yeah, that framing (browser access vs. content extraction leaving the affordance layer untouched) is exactly the gap this is trying to sit in, so glad it's landing.
Bot-protection is a fair and honest edge to raise, and I won't oversell it: since extraction runs through a server-side headless Playwright pass, sites behind Cloudflare/Akamai/HUMAN are exactly the kind of surface that's likely to challenge or block it — same category of problem any headless automation runs into, Manifest doesn't have special evasion built in. So for those checkout surfaces specifically, today's honest answer is "it depends on how aggressive that particular site's protection is," not "solved." It's a real edge of current reach rather than something quietly handled.
Appreciate you noticing the pattern in the replies — I'd rather be upfront about where the line is than let people find out the hard way in production
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.