How we built A3.

Wrapidity: proof that machines could learn to extract

We weren't imagining things: it had been done, at least for reading. Wrapidity, an Oxford University spin-out, had commercialised five years of ERC-funded research (the DIADEM project) into what computer science calls automated wrapper generation: software that replaces hand-coded scrapers outright. Instead of brittle extraction code keyed to a page's markup, it used "page geography" and visual cues, reading a rendered page the way a human eye does: matching input boxes to nearby labels, navigating complex forms, and parsing results into structured data on its own. Meltwater acquired it in 2017.

Wrapidity proved a machine could learn to read a website autonomously. Our question was one step harder: could a machine learn to transact, and could it emit an artifact our platform could replay deterministically at scale?

"Init": teach the page to explain itself

Our first move: stop treating a page as markup and start treating it as semantics. A2 injected an analyser into the live page that walked the document and rebuilt it as a semantic tree, classifying each element by meaning, discarding what it couldn't classify, and collapsing the wrapper elements that make real-world pages ten layers deep.

# SPEC.md — "Grouping algorithm for A2" (verbatim structure)
1. Preparation        # page → semantic tree, classify elements,
                      # discard unclassified, remove wrapper nodes
2. Pivot points       # semantic query: "get all prices"
3. Attachment         # ascend to common parent, query within scope,
                      # prefer the closest common parent
4. Pruning            # drop unrelated elements by proximity

Pivot points and proximity: structure from geometry

A2's core insight, the same one Wrapidity ran on, was that a results page has a shape. Find the repeated anchor (every price on the page) and call each one a pivot point. Then, for each pivot, climb the tree towards the root, at every level asking a semantic query inside that subtree: is there a room name here? A rate name? A cancellation policy? The closest common parent that answers wins; anything that shows up in implausibly large groups gets discarded. No selectors written by anyone. The page's own geometry does the grouping.

A2's output was an Autopilot script

Here is the detail that makes A2 the true ancestor of A3 rather than a curiosity: what it emitted was not a dataset but a script in our engine's own format. Machine-discovered data points became query-and-climb pipelines with measured distances; the result was a script the existing Automation Cloud could replay deterministically, at full speed, with no analyser in the loop.

// for each discovered data point: climb ×distance, select, extract
pipeline.push(fetchData('/price', [
    { type: 'dom/text-content' },
    { type: 'value/parse-price', exponent: 0 }
]));
dataPoints.forEach(dp => {
    pipeline.push(fetchData(pathFor(dp.type), [
        { count: dp.distance, type: 'dom/parent' },
        { type: 'dom/query-one', selector: dp.selector },
        { type: 'dom/text-content' }
    ]));
});

The general-purpose reader exists now

What our pattern rules had been reaching toward ("this string is a room name; that one is a cancellation policy; those two prices belong together") became a commodity. A frontier language model reads a page, a screenshot, an intercepted API response, and classifies all of it, in any language, for any vertical, with no per-domain engineering. And unlike A2's analyser, it doesn't just recognise structure. It writes code. The author A2 was waiting for had arrived.

Keep the model out of the run loop

The obvious 2024 move was to put a model inside the loop: screenshot, think, click, repeat. Astonishing demos; hopeless economics for production work. Per-step inference is slow, priced per token, and non-deterministic exactly where a booking must not be. Years of running Autopilot scripts in production had made our requirements non-negotiable: runs must be cheap, fast, auditable, repeatable.

So A3's founding decision is a refusal: the model never drives production traffic. The model is the author. It learns a site once (expensively, thoughtfully, with a real browser in hand) and writes an artifact. The artifact runs a million times, for nothing, deterministically. Intelligence at the edges of the lifecycle; clockwork in the middle.

Stages: one recognisable state, one module

Autopilot's contexts return, reborn as code. A stage owns exactly one recognisable state of a website: a landing page, a results grid, a confirmation modal. Its match() answers "is this me?" with no side effects; its run() acts. Stages live in folders per site; a workflow binds the objective to typed input and output schemas. The contract is the same one A1 proved: small, matchable, replayable units, except now they're ordinary TypeScript driving a standard browser-automation framework, and their author is an agent.

export default defineStage({
    title: 'Extract Rooms and Rates',
    success: true,
    match: async (ctx) => {
        if (!new URL(ctx.page.url()).pathname.includes('/hotel/')) return false;
        return await ctx.page.locator('[data-rates-grid]').first().isVisible();
    },
    run: async (ctx) => {
        // prefer the intercepted availability JSON; fall back to the page
        const hit = ctx.networkResources.find(r =>
            r.request.url.includes('getProductAvailability'));
        ctx.outputs.results = hit ? normalizeRooms(hit) : await scrapeGrid(ctx);
    },
});

Learning sessions: teach a site, don't program it

Adding a site is no longer an encoding project; it's a conversation. An operator opens an interactive session, a full development environment in the browser, purpose-built for teaching. On the left, the project's files and the workflow's stages with their live match status. In the middle, a thread with the Learning Agent: you state the objective, and the agent navigates the real site, inspects the page and its network traffic, writes stage files, runs them, and iterates until the workflow's outputs validate against the schema, narrating each step as tool calls you can expand and audit. On the right, the live browser it's working in, plus the structured inputs and outputs. You can interrupt, correct, take over the browser, or replay any run step-by-step. The human's job has changed from author to reviewer: watch the diff, spot-check the run, publish.

Deterministic replay, with one narrow escape hatch

Production jobs run published versions on the worker fleet with no model in the loop, exactly as A1 taught us. But scraped text is messy: "Free cancellation until 48h before arrival" is not a schema field. So the runtime offers stages a single, disciplined opening: ctx.classify(), an AI-backed transform with an aggressive twist. The first time it sees a text shape, a model writes the parsing function; the numbers, dates and category words in the text are turned into parameters and the resulting function is cached. Every later occurrence of that shape is parsed by cached code: no model calls, no nondeterminism introduced.

The jobs floor: every run, and what broke it

The org dashboard's Jobs view is the A3 counterpart of the old operations room, with one structural upgrade. Every job shows its target (site, workflow, and the exact published version it ran), its owner (a person, an API caller, or the dataset that spawned it), and its full execution log. But when a job fails, the platform doesn't just say failed; it says whose fault: a script failure (the code no longer matches the website) or an environment failure (network trouble, a bot wall, an unreachable site). Environment failures retry quietly. Script failures accumulate into per-site health, and that distinction is what turns a monitoring page into the trigger for self-repair.

The treadmill, automated: the loop finally closes

This is the feature the previous eight years were building towards. Script failures feed a per-(workflow, site) sentinel. When thresholds trip (an absolute count, or a failure rate over a recent window), the platform first probes the site (no point blaming the code for an outage), then starts a Repair Agent: locked to the broken workflow's files, told to make the smallest possible change, capped in steps and in dollars.

Then the part that matters: we don't trust the agent's claims. The platform independently re-runs the workflow against the failing inputs plus known-good samples, and only a verified fix is published, through the normal publish pipeline, stamped as an automated fix. Publishing resets the health counters by definition. The 2 a.m. incident from Era 01 now usually resolves itself before anyone's pager fires.

sentinel: {
    enabled: true,
    failureThreshold: 3,      // absolute script failures per (workflow, site)
    failureRatePercent: 10,   // … or relative, over a recency window
    autoPublish: true,        // false → verified fix waits for human review
    maxAttemptsPerDay: 2,
    cooldownHours: 6,
    maxCostPerFix: 5,         // hard $ cap on the repair agent's model spend
    verifyEnvironment: true,  // probe the site before blaming the code
}

Datasets: the mill keeps running

Most real-world scraping isn't one page; it's a whole catalog, kept fresh forever. This is Smart Feed's lineage, rebuilt as a platform feature. Declare a dataset (which listing workflow to sweep, which sites, which detail workflow to run per item) and the platform owns everything we used to hand-orchestrate: fanning out detail jobs, de-duplicating items per site, detecting changes, keeping an append-only history of every revision, marking delisted items, budgeting retries, stopping early when pages stop yielding anything new, and firing on a schedule. The dashboard's Datasets view shows each catalog's size, freshness, and run history, with every scraped item queryable alongside its full change history.

Two planes, because agents write the code they run

An agent that writes code means a platform that runs machine-written programs as a matter of routine, so our infrastructure assumes hostility. A trusted control plane holds state, scheduling and secrets. An untrusted workload plane holds the workers: each one claims a job with a narrowly-scoped credential and spawns a runtime that can see exactly one session, one project, and nothing else: no databases, no platform secrets. Browsers come from a separate pool of managed, disposable browser hosts. The worker fleet autoscales with demand, keeping a warm pool so paid workloads never wait for capacity.

The platform publishes itself for agents

The Machine That Reads the Web ends with an inversion: sites exposing themselves to agents instead of fighting them. We built A3 on that side of history. Every surface (run jobs, edit project files, query datasets, org operations) is exposed over MCP, the open protocol that lets AI assistants call tools, and the Copilot chat on our dashboard uses the exact same tools as any external agent connecting over the wire. Claude, Cursor, a customer's own bot: identical capabilities, the user's own permissions, confirmation gates where actions have consequences.