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.
@max_nordstrom that's a genuinely honest answer, most tools would just quietly claim it handles all cases. the disabled/aria-disabled inference makes sense as the pragmatic v1 scope. for the async-JS-validation gap, would something like a lightweight 'confidence' flag on the requires field be feasible - even a rough signal telling the agent 'this dependency was inferred from static DOM, verify before relying on it' vs 'this one's a hard disabled attribute' - or would that just push the complexity onto the caller without really helping?
Manifest
@omri_ben_shoham1
Thanks, Omri — and yeah, I'd rather be upfront about the gaps than pretend v1 covers everything.
The confidence flag is a fair idea, and I think it could genuinely help, not just push complexity onto the caller — but only if the two levels change what an agent actually does (trust and wait on a hard signal, verify before relying on a softer one). If it's just a label with no behavioral difference downstream, it's not worth adding. Either way, that flag still wouldn't catch the async-JS-validation case — that one's invisible regardless of confidence tier, since there's nothing on the page for either signal to pick up on.
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
@max_nordstrom Ah, a 6-hour TTL makes sense as a balance between freshness and not re-scraping constantly. Is that TTL configurable, or fixed for all users right now?
Manifest
@ark_y_k
Fixed for everyone right now, no per-user config. It’s the kind of knob I’d rather add once someone actually hits a case where 6 hours is wrong for them, rather than guessing at the right defaults upfront.
@max_nordstrom That's a reasonable trade-off — building for a real pain point beats guessing every time. Makes sense to keep the surface area small until there's clear demand for it.
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.
I like the action-manifest angle because the brittle part for agents is usually not reading a page, it is knowing which clicks and fields are safe. Curious how you handle pages that change after login or A/B tests — does the manifest expire or get revalidated?
Manifest
@xiaosong001
Thanks, xiaosong — that's a good way to put it, reading the page was never the hard part, knowing what's safe to act on is.
On login/A/B changes: manifests are cached with a 6-hour TTL, keyed on URL — so it's a time-based expiry, not something that detects "this page just changed because you logged in" or "you landed in a different test bucket." If your agent logs in and the page structure shifts, you'd want to force a fresh extraction rather than trust a cached pre-login manifest, since nothing today automatically revalidates on that kind of state change. Same story for A/B variants — if the URL's the same but the served page differs, the cache can't tell the difference. It's a real gap, not something handled gracefully yet.
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.