Launching today
Manifest
Turn any webpage into an action manifest for AI agents
147 followers
Turn any webpage into an action manifest for AI agents
147 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.
Having a built-in way to record and replay a full user flow during integration testing would be huge. Something like a "golden path" capture from one successful Manifest call so my agent team can replay it on staging and catch drift before it bites production.
Manifest
@tansuorbacogbk
That's a good use case — a different ask from a runtime helper, this is more of a regression net.
Right now every /manifest call is a stateless snapshot — there's no notion of "this is the golden run for checkout" that later calls get compared against. Building that would mean capturing a manifest (or a sequence of them across a flow) as a baseline, then giving you a diff against staging: which actions disappeared, which requires changed, which locators broke. That's genuinely useful for catching silent drift before an agent hits it in prod instead of after.
It's a bigger lift than a simple SDK convenience — closer to a testing/CI feature — but it's a real gap. Noting it as its own thing.
the requires field is honestly such a nice touch, most tools i've tried just hand you a flat list and you have to figure out ordering yourself. this feels way more usable out of the box.
Manifest
@fadimea2ds
Thanks, Fadime — that ordering problem is exactly what I built requires to solve. A flat list of clickable things looks useful until you actually try to drive it and realize you have no idea what needs to happen first, so you end up guessing or brute-forcing the sequence. Glad it's landing as usable out of the box rather than something you have to fight with.
finally something that gets the dependency thing right, you know? the requires field saving me from writing all that state-checking logic is honestly a huge time sink off my plate
Manifest
@beyzaokhan
Thanks — that state-checking logic is such a silent time sink until you actually have to write it, and then it's suddenly half your integration code. Glad requires is taking that off your plate instead of just being another thing you have to reverse-engineer yourself.
The dependency graph is a really smart touch since most selector tools miss those relationships entirely. One thing I'd love to see is a built-in diff endpoint that compares two Manifest snapshots over time, so when a site silently changes its checkout flow the agent can detect the break before it fails mid-task.
Manifest
@mahiry1rs
Thanks, Mahir — and that's a sharp distinction from what most selector tools give you, since they don't even try to encode the relationships in the first place.
The diff-endpoint idea is a good one: right now every /manifest call is just a fresh snapshot with no memory of what came before, so a silently changed checkout flow only shows up when the agent fails mid-task, not before. An endpoint that takes two manifests and returns what actually changed — actions added/removed, requires shifted, locators broken — would let an agent (or a CI check) catch that drift proactively instead of finding out the hard way in production.
Noting it as a real direction, not just a nice-to-have.
Tried it on a gnarly multi-step checkout flow and the dependency graph actually caught a hidden "select plan before continue" rule I had been missing. The resolved CSS plus role locators side-by-side saved me a ton of selector soup.
Manifest
@masalyxsz
Thanks, Masal — that's a great real-world case, and exactly the kind of hidden rule requires is meant to surface, since "select plan before continue" is the sort of thing that's obvious to a human eye but easy to miss when you're just working off a flat element list. Glad the CSS/role locator pairing cut down the selector soup too — having both was meant to give you a fallback when one breaks rather than betting everything on a single brittle selector.
honestly the requires field sounds super useful, would love to see some kind of caching layer for repeat calls on the same URL so agents aren't paying the extraction cost every single time
Manifest
@emircandemtyvr
Thanks, Emircan — good news, that part's already in place: manifests are cached (TTL-based) under the hood, so repeat calls on the same URL within that window skip the full extraction cost instead of re-running it every time. Appreciate the ask lining up with something already shipped.
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.