Launching today
Manifest
Turn any webpage into an action manifest for AI agents
152 followers
Turn any webpage into an action manifest for AI agents
152 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.
Congrats on the launch. The action-manifest idea is useful because browser agents usually fail on hidden state, auth changes, or brittle selectors. How do you encode uncertainty or required preconditions when a page changes after the manifest is generated, and can developers inspect why an action was skipped?
Manifest
The dependency tracking between elements is genuinely useful, saved me from manually wiring up plan selection logic in my agent. Curious how it handles shadow DOM and dynamic SPAs though, that's usually where these tools fall apart for me.
Manifest
@emrekjvj
Thanks — plan-selection logic is exactly the kind of thing requires is meant to save you from hand-wiring.
Fair question on shadow DOM and SPAs, and I'll be straight about it: extraction runs on a rendered Playwright page using the accessibility tree plus DOM queries, with a wait after load to let client-side rendering settle. That handles most SPA cases fine since it's working off the live rendered DOM, not raw HTML. Shadow DOM is the shakier case — standard querySelectorAll doesn't pierce shadow boundaries, so elements inside a closed (or even open, depending on how it's queried) shadow root can get missed. It's not a solved problem yet, more an honest gap in coverage right now.
i spend a lot of time watching agents guess their way around web pages and it is a mess, so this scratches a real itch. the requires field encoding dependencies is the clever bit. who publishes these first though, site owners or agent builders running it on other people's pages? feels like the chicken and egg question
Manifest
@terminal_candy
Thanks — and yeah, that's the exact right question to ask, because it's the crux of whether this scales past a demo.
Short answer: agent builders first, out of necessity. Right now Manifest works on any page without the site owner doing anything — it's Playwright plus an LLM extraction step running against whatever's already rendered, so there's no cold-start problem on the consumption side. That's deliberate: the extraction layer had to work without any publisher buy-in or it never gets off the ground.
The site-owner side (a publisher SDK letting sites annotate their own semantics) is a later layer, not a launch requirement — and honestly it only makes sense once there's enough agent-side usage that a site owner has a reason to care about agent traffic at all. So the sequencing is: prove value to agent builders on the open web first, let that create the demand that eventually pulls publishers in, rather than trying to bootstrap both sides at once.
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.
The requires field is a really nice touch, caught me off guard how often other tools just hand you a list of clickable things without telling you what's gated. Quick to wire up with the Python SDK too.
Manifest
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."