Imprint
AI-Assisted
Architecting
Deterministic page interpretation system
Move the AI spend from every call to the repeating patterns of a site. Making flows deterministic, fast and low cost. Tailored per user, per site, per task.
Agentic interaction with web pages elevated
First agentic browsers like Comet and Atlas took the blogs by storm. The hype around the magic actually scared away innovation in different directions, scared away both innovators and stakeholders — why devote energy going against the Holy Grail? We shared the enthusiasm but had strong pragmatic concerns. A year later Doomsday and optimistic singularity narratives are still alternating, the parallel existing, complementary approach is still the most viable, resilient. Cheetah, our connectivity ecosystem purposely supports both visual interaction, full source level transfer and predefined, structural extraction at the perimeter.
(In a not web-only perspective, an interesting historic debate between John Carmack and Andrej Karpathy: see the thread.)
Importantly, no purely agentic initiative has so far disrupted classic browsers’ dominance: people stick with them and insist on keeping control. Permanently elevating the level of interaction - that Imprint is doing for repeated scenarios - can be adopted as a seamless and gradual way between the two ends.
What visual navigation costs
Relying on visual navigation offers the ultimate flexibility. Schema free processing, resistant to site changes, site restructuring. No need for initial experience beyond common sense, the best, although slow chance for unique tasks. The downside is that it comes at a price in many dimensions. Learning sites, recognizing patterns, moving routine from slow brain to muscle memory mirrors the strategy humans or even any organism develop for efficiency.
Fundamental constraints
- slow (pulsing animations while selecting a single next move)
- expensive (vs. milliseconds to process)
- stochastic (not just hallucinations, but reproducibility)
- availability (service outages, limited calls per second)
- model behavior (vendors can change, tweak under the hood)
These are the limitations that cannot be just stepped over as 'it improves over time'. In many aspects they can, but the mathematical and architectural constraints will never equate. Fundamental differences compare as measuring symbolic processing efforts in thousands of CPU cycles, while generative models burn billions of floating point operations, that is eventually paid in time and money by someone despite any purpose built hardware. Assuming technology gets times faster still preserves the proportional difference.
Direct (code generation) approaches
Seasoned engineers with sufficiently capable AI agents can generate suitable JavaScript or Python candidate code for processing web pages, as long as properly collected samples, insights and clean intentions exist. Also critical that observed inaccuracies, arising corner cases and periodic site changes should be quickly addressed. An updated solution should be built fast and find its way quickly to CI/CD.
- This however addresses only cases where ahead-of-time code creation is feasible. Does not offer a real-time alternative of replacing the permanently agentic navigation even for repetitive tasks.
- The bigger problem is that deploying code on the fly to high trust environments (like browser plugins) is not feasible or even impossible. Chrome plugins for example will not accept specialized or updated executable codes without rebuild, redeployment - and in most cases tedious review process if publicly distributed. Per-user and realtime distillation and improvement is not possible.
Declarative approach
Imprint turns the problem to a description approach. A parser and result description format with suitable representational capabilities was developed and tested against variety of websites. We have implemented a runtime component that can be deployed to these restricted environments (including browser extensions). Once integrated to any application (either browser extension or other strictly controlled frameworks), as long as the DSL and runtime do not need new capabilities, advancing the supported website or page type set is a matter of uploading the proper definitions for all new page types.
Cheetah carries the trade-off in its protocol
Nothing above forces a single choice, and Cheetah is built so a product does not have to make one. Any command sent to a browser client can ask, in the same round trip, for the state of the page after that command was applied:
- the full serialized source
- the values a parser extracted from it
- a screenshot of what a person would have seen
One page moment, up to four useful views - the command's own result beside those three. A product can start by shipping whole pages to its own server, move to extracted values when the page types are known, and keep the screenshot for the cases where a human still has to look. The transport does not change when the level of interaction does.
The main point: injecting into trusted environments
A definition is data. Code is not.
A browser extension is a high-trust environment, and everything that earns that trust also makes it rigid. New executable code means a rebuild, a redeployment and, in public distribution, a review queue. That is the correct trade for the platform to make - and it is precisely what blocks per-user, per-site improvement.
A parser definition is not code. It is a bounded description that an already-reviewed runtime interprets: it names the fields, points at the elements that hold them and declares how to read them, and it cannot express anything the runtime does not already implement. Delivering one is delivering data, so an installed extension can learn a new page type without a new version, a store submission or a user action.
Growing what the language itself can express is a different matter and still requires a runtime release. That boundary is deliberate. It is what keeps this from being remote code execution wearing a declarative costume, and it is the reason the arrangement is acceptable inside an environment that is right to be suspicious.
Both sides can narrow what happens; neither can widen it. The server decides what it is willing to ask for, the browser decides what it is willing to do, and a denial on either side stands. A parser arriving from the server does not acquire authority by arriving - it is still executed under local policy, beside the page, by a runtime the platform already approved.
Descriptive language and runtime
Parse where the page already is.
The obvious way to read a page on a server is to send the page to the server. It works, and it means every visited page - including everything a user happened to have on screen - crosses a network boundary and lands in someone's logs.
Parsing beside the page inverts that. The runtime executes the definition in the browser and only the named values leave: a price, a title, an identifier. The full source is available when a product genuinely needs it, but it is requested deliberately rather than shipped by default. Less traffic is the smaller benefit; the larger one is that the trust question becomes answerable, because what leaves the machine is a short, inspectable list rather than everything.
What a definition looks like
A parser definition is deliberately small and boring to read. It names a page family, the region that holds the interesting part, the repeated item inside it, and the fields to read from each one:
A fragment of a definition for a fictional listing page
{
"id": "example-shop/search-results",
"applies_to": { "url": "^https://example\\.test/search" },
"scope": { "region": "main[role=main] .results" },
"items": {
"each": "article.result-card",
"fields": {
"title": { "read": "text", "from": "h3 a" },
"url": { "read": "attribute", "from": "h3 a", "name": "href" },
"price": { "read": "text", "from": ".price", "transform": "money" },
"in_stock": { "read": "presence", "from": ".badge--available" }
}
}
}Everything a reviewer needs is on the page: where the value comes from, how it is read, what happens to it afterwards. There is no branching logic to follow and no place for behaviour to hide, which is what makes the artifact reviewable, diffable and safe to hand to a runtime that will not question it.
The runtime does the same thing every time.
Two inputs go in - the serialized page and a definition - and the same values come out every time for the same inputs. No inference, no network call, nothing that varies with load or vendor. It runs in a backend, a batch job or a browser extension without changing behaviour, because there is nothing in it that could vary.
What comes back beside the data matters as much as the data. A field that could not be read says so, a region that was missing says so, and a value that was transformed reports what it looked like before. Extraction stops being a black box that either works or mysteriously does not.
When a page changes
A parser is deterministic, which also means it can be confidently wrong once a site is restructured. That failure is at least visible: the runtime reports which fields stopped extracting, and the failing capture can be replayed against the previous definition to see exactly what moved.
Where a fallback path exists, visual interpretation can cover the gap until a corrected definition is delivered - slower and more expensive, but working. Determinism is not a promise that a page will never change; it is a promise that when one does, the failure has an address.
The output is a parser: a small declarative document recording where each intended value lives and how to read it. A model authors that document under supervision against saved page evidence, and a deterministic runtime executes it afterwards, returning the same structured values for the same HTML every time.
Cost moves from per page view to per page template, and the extraction behaviour becomes something that can be read, diffed, versioned and replayed.
Where this stands
The parser language and the runtime are the settled part: a documented format and a small engine with a narrow public API, with real generated parsers included as examples. Automatic generation is active research - exercised against a curated corpus of saved captures across a small set of site and page-type families, improved through measured failures, and still moving enough that no success ratio belongs on a public page.
AI assistance moves from execution time to authoring time.
Nothing here removes the model. It is spent once, while the parser is being written, and it is absent afterwards. Authoring is where a page genuinely needs judgment - machine-generated markup, values hidden in attributes, the same content rendered twice for different viewports, fields legitimately absent on some pages. Execution needs none of it: the runtime follows a definition that has already been checked.
The model proposes; it does not decide when its own work is good enough. Checks run cheapest first - valid and expressible by the language, then every requested field extracted from the demonstration captures, then screenshots that do not contradict the values produced - and a candidate that passes is tried again on held-back captures it never inspected. Failures come back addressed: which field, which capture, what the value looked like before a transform touched it.
Why a generation service, when a capable model can already do this
Because it can, and that is not the interesting question. A frontier model handles megabytes of HTML today, fills a context window with a dynamic social or marketplace page, and a disciplined engineer can steer it to a working parser. The bill for that arrives in dollars per attempt, sometimes tens of dollars once a page family is complex and the sampling is honest - and it arrives again for the next site, and again after the next restructuring.
The generator harness exists to move that from dollars to cents. It replaces open-ended prompting with strict, experimentally validated internal workflows designed around what smaller and cheaper models can reliably do, and spends the expensive capability only where nothing else will serve. That is an engineering problem with a measurable answer, not a limitation being worked around.
It is also a moving target, deliberately. What the cheap tier can be trusted with changes every few months - a fivefold price drop in a mainstream model tier reopens choices that were settled a quarter earlier - so the harness is re-measured against current models rather than fixed at the point it first worked.
What remains solved
Declarative parser artifacts
The deliverable is a definition naming each field, the element that holds it and how to read it. It can be reviewed without replaying the authoring conversation, diffed against a regenerated version, versioned alongside the application, and replayed against saved captures at effectively no marginal cost.
Deterministic local runtime
A small engine takes a parser definition and serialized HTML and returns structured values, with the same inputs always producing the same output. It runs in a backend, a batch process or inside a browser extension, without sending pages to a third party.
Gated generation loop
Generation is a supervised loop over saved evidence, ordered so the cheapest disqualifying check runs first: format validity, then extraction of every requested field from the demonstration captures, then a check that screenshots do not contradict the extracted values. A passing candidate is validated again on held-back captures.
Field-level honesty report
Results are not flattened into pass or fail. Each field records how it was established: visibly confirmed by pixels, structurally consistent but not provable from a screenshot, non-visual by design such as a URL or internal identifier, or legitimately empty with the absence audited against the available evidence.
Imprint supplies the interpretation layer, and Cheetah supplies the execution surface around it - the substrate that carries a parser to wherever the page actually is, across browsers, extensions and backend processes. Troveholm is where the two run together in a real product, loading parser definitions promoted out of Imprint through a shared artifact store, which makes it both a demonstration and a source of genuine demands on the foundations. Arboretum holds Imprint's own design reasoning; Paladin and AWACS act on the work rather than the product.