Jev, Laya, and Manifest aren't competing for the same job
5
min read
Agent Infrastructure
There's a comparison worth making between Manifest and the new wave of "System 1" decision models — TypeSafe's Jev and its open-weight counterpart, Laya, from Convai Innovations. People keep putting these in the same bucket as browser-agent tooling, so it's worth being precise about what each one actually does. They're not competing for the same job.
What Jev and Laya actually do
Both are small, fast models built for one narrow task: given a state and a typed question, return a calibrated decision. You hand them something like a numbered table of the controls visible on a page, ask "which of these should I click next," and they answer in tens of milliseconds with a selection and a probability — not a sentence. Laya is the open-weight version of the same idea, small enough to run locally with no API key and no cloud dependency.
That's a genuinely useful property. A model that can only choose from a fixed set of typed answers can't hallucinate an instruction that wasn't in the set. It's the deciding half of an agent loop, and it's fast and honest about its own uncertainty in a way a general-purpose LLM writing free text isn't.
What they need to work
Neither model produces the table it's deciding over. Something upstream has to look at a real page — with its cookie banners, nav chrome, client-side rendering, and inconsistent ARIA support — and turn it into a clean, numbered list of actions before Jev or Laya can do anything with it. Right now that upstream step is usually a raw accessibility-tree dump or hand-rolled DOM parsing: noisy, unresolved locators, no sense of which fields are gated behind which others.
That's the extraction problem, and it's the one Manifest solves. A Manifest action manifest is already the shape a System 1 model wants to consume: every clickable, fillable, and submittable element, with a resolved locator instead of a guessed one, and a requires dependency graph so the decision layer doesn't have to infer on its own that "place order" isn't valid until "shipping confirmed" is true.
Where each one sits
Layer | Job | Example |
|---|---|---|
Session/browser access | Run the browser, manage the session | Browserbase |
Content extraction | Pull readable text/data off a page | Firecrawl |
Action extraction | Turn a page into a structured set of actions with locators and dependencies | Manifest |
Decision | Given a set of actions, pick the next one | Jev, Laya |
Manifest sits one layer below Jev and Laya, not beside them. The realistic pipeline is: Manifest extracts the action set → that set becomes the numbered table → Jev or Laya decides which one to act on → something executes it (Playwright, agent-browser, whatever's driving the actual click).
The honest limitation
This isn't a seamless fit today. Manifest's output format wasn't designed against TypeSafe's /v1/systemone wire format or Laya's element-table convention, so there's real adapter work to go from a Manifest manifest to what these models expect as input — mapping resolved locators into their indexed-table format, deciding how to represent the requires graph as a constraint the decision model can use rather than ignore. It's not automatic just because both pieces exist.
The other limitation is coverage: Manifest's extraction quality is only as good as the page's accessibility surface, and long-tail sites with heavy client-side rendering or no meaningful ARIA will produce thinner manifests — which means a thinner table for Jev or Laya to decide over, no matter how good the decision model is. Garbage state in, calibrated-but-wrong decision out.
The takeaway
If you're evaluating Jev or Laya for a browser agent, the question isn't "Manifest or Jev" — it's what you're currently feeding Jev's state input, and whether it's clean enough for a decision model to be worth the speed it buys you.
