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.
honestly this looks super useful for shipping agents, the requires field alone solves a headache ive dealt with for months. one thing id love to see is some kind of caching or snapshot diffing so you dont have to re-scan a full page every time the agent loops, basically only re-resolve the parts that actually changed.
Manifest
@sleymanbayrwcs
Thanks, glad the requires field is hitting a real pain point — that was the part I spent the most time getting right.
On caching: there's already a manifest cache under the hood (Postgres, TTL-based) so repeated calls to the same URL within that window don't trigger a full re-scan. But you're pointing at something sharper — diffing within a session so an agent looping on the same page only pays for the parts that actually changed, rather than a flat TTL that's blind to state changes. That's a better model than what's there today, especially for longer agent loops where the page mutates between actions.
Filing this away as a real direction — appreciate you naming the actual mechanism instead of just "make it faster."
Love that the requires field captures element dependencies, that's a real pain point I keep hitting. One thing that would save me a ton of time: a built-in wait helper that knows to poll until those required dependencies are satisfied before resolving the click action. Right now I still end up writing retry logic around it.
Manifest
@kamilkiei
Thanks Kamil — and yeah, that's a fair ask. Right now requires tells you what's blocking an action, but the client doesn't do anything with that information for you — you're stuck writing the poll loop yourself, which sounds exactly like what's biting you.
A helper that takes an action id, watches its requires list, and resolves once those are satisfied (with sane backoff/timeout defaults) is a pretty natural extension of what's already in the SDK — it's sitting right on top of blocked_actions(), which already exists for exactly this check. Feels like the kind of thing that should just be client.wait_for(action_id) rather than something every user re-implements.
Adding this to the list — appreciate the specific pain point, it's a lot more useful than a vague "nice to have."
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.
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.