Launched this week
Manifest
Turn any webpage into an action manifest for AI agents
180 followers
Turn any webpage into an action manifest for AI agents
180 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.
the requires field is genuinely useful, been burned by agents clicking submit before the form was complete way too many times. one thing id love to see is a way to mark elements that trigger async loads, like a dropdown that fetches options after you click it. right now my agents try to interact before the data is there
Manifest
@ecebedk3yvp
Thanks, Ece — that "clicking submit too early" failure is exactly the class of bug requires is meant to prevent.
The async-load case is a good catch though, and a bit different from ordering: it's not that the dropdown depends on another action, it's that the dropdown's own options aren't populated yet when the manifest is captured, so your agent has correct ordering but stale data. Flagging elements that trigger a fetch-on-interact (and maybe hinting the agent should wait/re-resolve after clicking) would close that gap. Noting it as its own case rather than folding it into requires.
Really useful for browser agent work, the requires field alone is a nice touch. One thing I'd love is a built-in way to test the generated map against an actual page session, so you can catch mismatches between the JSON output and what the DOM actually looks like before your agent runs.
Manifest
@can4ojy
Thanks Can! Good ask, and a real gap. Right now the manifest is generated once and handed over as-is, so there's no built-in check that it still matches the live DOM by the time your agent uses it, if the page shifted between the call and the run, you find out mid-task instead of before. A validation step that replays the manifest against a fresh session and flags mismatches (locator no longer resolves, action missing, etc.) before the agent commits to it would catch exactly that class of bug. Noting it as a real direction.
Finally something that gets rid of the brittle XPath mess my scraper has been held together with. The requires field is a nice touch, saved me from another broken dropdown flow.
Manifest
@emin6zgn
Thanks — that XPath brittleness is exactly the kind of thing I wanted this to replace, since a selector that snaps the moment a site tweaks its layout is a maintenance tax nobody should have to keep paying. Glad requires caught a dropdown flow before it broke on you instead of after.
the requires field is honestly the standout for me, it captures context i've been missing when agents just blow past dependencies and fail silently. one api call returning resolved locators plus that semantic info is way cleaner than juggling aria snapshots.
Manifest
@aligndoduz2fn
Thanks — "fails silently" is exactly the failure mode requires is meant to prevent, since an agent blowing past a dependency doesn't even know it did anything wrong until something downstream breaks. Glad the single call is landing cleaner than juggling raw aria snapshots yourself — that consolidation (semantics plus resolved locators in one response) was the whole point of not making you stitch it together on your end.
The action graph idea is really clever, especially encoding those prerequisite relationships between elements. One thing that would help me a lot is a built-in diff or change-detection endpoint, so when a site updates its structure I can quickly see which locators broke and get suggestions for replacements instead of manually hunting through the JSON map. Would save a ton of debugging time in production.
Manifest
@rmeysaertuvujj
Thanks — and that prerequisite encoding is the piece I spent the most time getting right, so glad it's landing.
The diff/change-detection ask is a real gap. Right now every /manifest call is a fresh snapshot with no memory of a prior state, so when a site's structure shifts, you find out by hunting through the JSON yourself rather than being told what broke. An endpoint that takes two manifests and surfaces the actual delta — locators that no longer resolve, actions that disappeared, requires that shifted — would turn that into a quick lookup instead of a manual diff. The "suggested replacement" part is the harder half (matching an old locator to its likely new equivalent isn't always clean), but even the plain diff alone would save the debugging time you're describing. Noting this as a real direction.
the requires field for encoding element dependencies is genuinely clever, that's the kind of context aria snapshots miss and usually breaks agents. gonna test it on a gnarly multi-step checkout flow
Manifest
@diyars9zv
Thanks — that's exactly the gap requires is meant to close, since raw aria snapshots give you what's on the page but not what order it has to happen in, and that's usually where agents quietly fail. A gnarly multi-step checkout is a good stress test for it — that's precisely the kind of flow where dependency ordering actually matters. Let me know how it holds up.
honestly the requires field is the part that sold me, most selectors break for me when modals depend on prior actions. gave it a quick spin on a messy form and it nailed the dependency mapping first try.
Manifest
@alparslan5ths
Thanks, Alparslan — that modal-depends-on-prior-action pattern is a really common way this stuff breaks, so glad requires caught it instead of you having to debug it after the fact. And nailing it on a messy form first try is a good sign — that's usually where the DOM signals get noisy enough to trip things up. Appreciate you giving it a real spin.