Agentic Workflows That Need Live Web Data

Most demonstrations of agentic workflows use context the organisation already owns: its own tickets, its own repository, its own warehouse. Those are useful and they are also the easy case, because the data is already structured, already permissioned, and already fresh by construction.

The harder and more valuable case is a workflow whose trigger lives outside the company. A tender that closes in seven days. A vendor's sunset date that moved. A property that came to auction on Thursday. A funding filing that named three people. A sanctions list that changed overnight. Nothing in your warehouse knows about any of them, and by the time it does, the window has usually closed.

That is the class this piece is about. Five workflows follow, each mapped to a feed that already runs, each with two real rows lifted from the current snapshot, and each with the same structural requirement: the agent has to be able to say where the value came from and when it was read, because it is about to do something on the strength of it.

The loop is small and the value is obvious. A notice appears on a public register; an agent reads the buyer, the value, the closing date, the classification and the delivery area; it scores the notice against a supplier's own capability and capacity rules; it either drafts the bid/no-bid note or does nothing. The work it removes is the daily reading of a national firehose that is 99.9% irrelevant to any one firm.

The reason it needs live data rather than an index is entirely in the deadline column. A notice that closed last week is not a worse lead than an open one; it is not a lead at all. The two rows below come from the Cornwall & Devon electrical tenders feed, which re-runs daily and sorts by days to deadline for exactly this reason.

Note what the second row does with an unknown. National Grid's notice does not state a value, so the value is published as withheld rather than as a zero or a guess. An agent scoring on contract size has to be able to tell “small” from “not stated”, and a dataset that flattens the second into the first will quietly teach it to discard the largest jobs on the page.

This is the workflow engineering teams ask for first once they have an agent with repository access. A vendor announces an end-of-life date; the agent checks whether anything in the dependency graph is affected; if it is, it opens an issue or a draft pull request with the date, the source and the affected files attached.

It is a good fit for an agent because the tedium is real and the judgement is small. It is a bad fit for a static index because deprecation dates are exactly the kind of fact that moves: dates slip, severities get reclassified, and a vendor changelog entry from March is superseded by a catalogue entry in August. The rows below come from API Deprecation Watch, which runs daily across 460-plus products.

The row-type column is the part that makes the workflow safe to automate. A catalogue row is a maintained end-of-life record; a changelog row is a single vendor post that happened to state a date. Both are useful, and only one of them should be allowed to open a pull request without a human reading it first.

Auction catalogues are published, then amended, then withdrawn, and the useful window between a lot appearing and the room closing is measured in days. An agent that reads the lot, pulls the local comparable, computes the gap and drafts an underwriting note is doing in seconds what an analyst does in an afternoon.

Two lots from the UK Distressed Property feed show why the status field has to be live. One is available and priced roughly at its comparable; the other sold at a very large discount to it. A monthly export would show you both as listings and tell you nothing about which room has already closed.

This feed is also the one where we are most explicit about confidence: every one of its 39 published lots carries SIGNAL rather than CONFIRMED, because each lot has a single origin — the auction house's own listing. That is written on the page rather than smoothed away, and an agent underwriting on a single-origin value should be required to say so in its note.

A Form D filing with the US Securities and Exchange Commission names an issuer, names its executive officers and directors, states the total offering and states how much has been sold. It is due within 15 days of the first sale, and a great many companies file one long before they publish anything about themselves.

The agentic version is a research-and-draft loop: read the filing, check whether anything has been written about the issuer, and if not, assemble a brief with the named people and the raise shape. What it must not do is send anything on its own, which is the subject of the last section.

Two rows from the Stealth Startup Radar show why the two amount fields are not one field. Terram Lab had sold roughly £14m of a $25m offering when it filed, which is a round still open; 3852.ai had sold its entire $435,000 offering, which is a different situation and a different message. Collapsing those into “raised” loses the only piece of timing information the filing contains.

Screening a counterparty against a sanctions list is a compliance obligation, not a growth idea, and it is the workflow where a stale index is least forgivable. The relevant object is not the list; it is the change to the list, because a designation made this morning is precisely the one your last screening run could not have caught.

The Sanctions Diffs feed is built from the authorities' own delta files, so each row is an action rather than an entry: designated, amended or delisted, with the date the authority published it. The two rows below were both published on 7 August 2026 and point in opposite directions, which is the ordinary daily reality of these lists.

The aliases and identifiers matter more than the primary name here. Matching on a display name alone produces both false negatives, because entities trade under several names, and false positives, because names collide. A row that carries its aliases, its programme and its official identifier lets an agent produce a match an actual compliance officer can check.

All five workflows consume the same shape. The block below is a trimmed result built from the two real tender rows above, as an agent would receive them through a tool call rather than by reading a page.

Three fields do the load-bearing work, and none of them is the value. `source_url` is where the agent gets its citation. `confidence` is a field rather than a tone, so the model can see the difference between two independent origins and one before it decides. And a null is a null: National Grid's value is unknown, so it arrives as null rather than as a number that would read as fact.

Every workflow above ends in an action with a cost: a bid decision, a pull request, an underwriting note, an outreach message, an onboarding block. The single most useful design rule we have found is to split the loop at that point, and to let the agent do everything up to it.

In practice that means the agent gathers, filters, scores and drafts — all of which are reversible — and then stops, presenting the draft together with the rows it relied on and the source URL for each. A person approves, edits or rejects. The economics still work, because the expensive part was never the click; it was the reading.

The provenance fields are what make the stop useful rather than annoying. A reviewer looking at “bid on this, closes in seven days” with the notice number beside it can approve in a few seconds. A reviewer looking at the same recommendation with no source has to redo the research, at which point the agent has saved nobody anything.

Two further rules earn their place. Let the agent refuse: a missing value should produce “I do not have this” rather than a plausible number, which is only possible if the data distinguishes empty from zero. And put the age of every value in front of the model, because an agent that can see a value was read three weeks ago can ask for a re-check, while one that cannot will simply assert it.

The connection itself is configuration rather than a build. The scraper.io MCP server is a remote Streamable HTTP server with ten typed tools — list_monitors, get_monitor, create_monitor, update_monitor, pause_monitor, resume_monitor, list_alerts, get_evaluation, list_channels and check_now — which covers reading a set, asking what changed, and being woken when something matches instead of polling.

Scoping follows the same split as the workflow. Read-only agents get read-only keys; creating or changing a monitor needs an explicit write scope; every call is isolated to one workspace. That maps neatly onto ask-before-it-acts, because the authority to act is withheld at the key rather than only in the prompt.

If you want to start from the data rather than the plumbing, the sets above are all on the live feeds page, and the commercial shape is on the pricing page: a one-off job starts at £150 and is quoted per job, and a feed is the same set kept running on its own cadence.