Launching today
Manifest
Turn any webpage into an action manifest for AI agents
71 followers
Turn any webpage into an action manifest for AI agents
71 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.
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
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
The locators and dependency graph sound genuinely useful, especially the requires field which fixes a real pain point I've hit with ARIA snapshots. One thing I'd love to see is a way to record an action once and replay it across similar pages, like a session that lets the agent reuse a successful interaction pattern instead of rediscovering the DOM map every single time.
Manifest
@mahmutjldv
That’s a sharp ask, and it’s basically describing the next layer we’ve sketched but haven’t built: reusable interaction patterns instead of re-discovering the DOM map on every call.
Where we are today: every call is a fresh extraction, no memory of prior successful runs. What you’re describing — record an action pattern once, replay it across structurally similar pages — is close to a “session” concept we’ve deferred until there’s real usage data to design it around, rather than guessing at the right abstraction upfront.
The open question we’d need to work through: how much a pattern generalizes across “similar” pages. A recorded flow on one checkout page might transfer cleanly to another site on the same platform (e.g. two Shopify stores), but two bespoke checkouts could diverge enough that blind replay breaks. So it’d likely need some fallback — replay the pattern, verify against the current manifest, re-extract if it doesn’t match.
Genuinely useful signal, though — this is exactly the kind of use case that’d shape whether we build that as a caching layer, a recorded macro, or something else. Appreciate you raising it.
Action manifests are a useful primitive for agent workflows. The part I would want to see emphasized is preconditions and permissions: what the page action is allowed to do, what success means, and what evidence gets handed back after the run.
Manifest
The dependency graph between elements is genuinely useful for agent builders, something I've been piecing together by hand for months. One thing that would save a ton of debugging time: let me simulate an action through the same API and tell me whether the requires chain actually cleared or if something is silently blocking it. Right now I can see the map, but I can't trust it until I try it.
Manifest