HyperDrift
IssueHyperCV is now Next Role — and it's no longer just a CV toolDaily Brief [AI]Today's signal →Digital studio
IssueHyperCV is now Next Role — and it's no longer just a CV tool
Daily Brief [AI]Today's signal →

UK AI Radar: An Agentic Radar Over Government Surface Area

••
#ai#agents#playground+2 more

Repository: hyperdrift-io/uk-ai-radar · Status: POC, open in public · Not affiliated with HM Government.

The missing layer

UK AI founders have to track an extraordinary amount of public surface area to do their jobs: department announcements on gov.uk, open grants on UKRI and the Innovate UK Funding Service, Parliamentary committees and Hansard, consultations, policy papers. Each of these systems is exhaustive in its own way. None of them are personalised. The newsletter ecosystem that grew up around this gap is the opposite — opinionated, generic, and stripped of citation.

The missing layer is the one in between: a personalised, cited, multi-source radar that knows your profile and tells you what changed this week that you should act on. Not a chat assistant you have to interrogate; not a newsletter that summarises what everyone already saw. A radar.

UK AI Radar is a POC for that layer. It is also a worked example of an architectural pattern that generalises: a small graph of typed personas reading authoritative sources through a diff-first cache, emitting a brief that has been ranked against an explicit founder profile. Every claim cites a source the user can verify in two clicks.

What it does, concretely

You drop a JSON profile under profiles/:

{
  "name": "Acme Robotics",
  "stage": "seed",
  "focus": ["robotics", "manufacturing", "industrial-ai"],
  "regions": ["uk", "eu"],
  "interests": [
    "innovate-uk grants relevant to robotics",
    "skills and immigration policy affecting AI hires",
    "procurement frameworks where we could be a supplier"
  ]
}

You run pnpm digest --profile profiles/acme.json, and you get back a weekly brief with three things ranked by relevance to your profile: what changed, why it matters to you, and the link to the underlying gov.uk / UKRI / Parliament page that says so.

A second profile on the same cache produces a visibly different top-three. Same surface area; different lens.

The architecture (and why it generalises)

This is the part that matters for any builder reading. The internal shape is a small typed agent graph:

PersonaJobInputOutput
ScoutFetch, hash, diff. Forward only deltas downstream.Whitelisted source URLsRaw page deltas + content hash
AnalystExtract structured fields against Zod schemas (Anthropic tool-use).Page deltaTyped records (grants, consultations, statements, …)
StrategistScore each record against the founder profile. Write the "so what?" angle.Typed records + profileRanked, annotated items
EditorDedupe, rank globally, emit the brief.All Strategist outputsOne Markdown brief, every claim cited

Three properties of this shape are worth naming, because they recur in every serious agentic system:

1. Personas are not chat roles. Each persona is a typed node in the graph with a tight input/output schema. The reason it is "Scout" rather than fetch_and_diff() is not anthropomorphism — it is to make the role one boundary, with one responsibility, that you can swap without touching the others. Reading the graph, a new engineer understands the system in three minutes.

2. The cache is the difference between toy and product. The Scout layer hashes each page, stores the hash in SQLite, and forwards only deltas downstream. First run: full fetch, every page is "new", token bill is significant. Second run, an hour later: nothing has changed on most pages, so almost nothing reaches the Analyst, and the bill drops by 80%+. This is not an optimisation — it is the architectural decision that lets the system run weekly per tenant at sane cost.

3. The whitelist is enforced at the fetcher, not by the agent. Any host outside gov.uk, ukri.org, or parliament.uk is rejected before bytes leave the network. The agent could not exfiltrate to an arbitrary URL even if a prompt-injection tried to make it. Sources are a property of the system, not of the model. The model only ever sees content that was already inside the trust boundary.

These three properties — typed personas with one job each, diff-first caching, system-level trust boundaries — describe every robust agentic system I have ever shipped. UK AI Radar makes them concrete in 1,200 lines of code on a real problem.

Multi-tenancy demo on a single laptop

Profiles double as tenants. The same cache and the same graph produce different briefs for different profiles:

pnpm digest --profile profiles/acme.json
pnpm digest --profile profiles/beta.json

The Scout fetches once. The Strategist scores twice. The Editor emits two distinct briefs. This is the TenantContext pattern at its smallest — a profile id flows through every node, scoring uses it, output is keyed by it. Scale that profile from a JSON file to a row in a tenants table backed by your billing system and you have a multi-tenant SaaS.

What this is not

  • Not a government service. No crown, no GOV.UK wordmark, no gov.uk subdomain. The GOV.UK Design System is used because it is excellent and accessible; a banner on every page makes the non-affiliation explicit.
  • Not a newsletter. Every claim links to the underlying authoritative source. The brief is a tool to read the government's own output, not a substitute for it.
  • Not a chatbot. No prompt box. The output is a brief; the verification path is a link. The only choice the user makes is which profile to run.

These are deliberate choices. A radar that puts a chat box at the top of the brief is two products glued together, neither of them good.

The wider gap

UK AI founders are a small slice of a much larger problem: knowledge workers in any regulated, fast-moving vertical lack personalised, cited radars over their authoritative sources. Healthcare professionals tracking MHRA and NICE. Lawyers tracking case law and statutory instruments. Financial-services teams tracking PRA / FCA bulletins. Defence contractors tracking procurement notices. Researchers tracking funder calls across UKRI / Horizon / NIH.

Every one of these audiences has the same shape of problem: a high-volume, authoritative, public source ecosystem; a need for personalisation; a hard requirement for traceable citation; and a regulatory or competitive cost to missing something that mattered. Every one of them is currently served by some combination of generic newsletters, hand-curated Slack channels, and brute-force RSS.

UK AI Radar is a single instance of a pattern that should exist a dozen times.

What's open for adopters

The repo is public: hyperdrift-io/uk-ai-radar. Stack is Nuxt 3 + LangGraph.js + Anthropic + SQLite + Vitest. A handful of things are deliberately small:

  • One profile schema, easy to extend.
  • Four personas in v1. Lawyer, Lobbyist, Grant Writer, Archivist are designed in but deferred to v2.
  • One brief format. The architecture allows alternative renderings (audio brief, RSS feed, MCP server) without touching the graph.

Acceptance bar for the POC, recorded so adopters can verify the same shape works for them:

  • 100% of cited URLs in a brief resolve to gov.uk, ukri.org, or parliament.uk.
  • Second consecutive run consumes < 20% of first-run tokens.
  • Two profiles on the same cache produce visibly different top-3.

If you are building a radar for a different vertical — fork it, replace the whitelist, replace the persona prompts, keep the shape. The shape is the interesting part.

Why I wrote this in public

Two reasons.

The first is the OSS tradition: useful patterns are worth more than useful products. A pattern other builders can adopt outlives any individual radar. The radar is the demonstration; the pattern is the contribution.

The second is the civic one: the UK government surface area is a public good, paid for by everyone, currently legible only to those with time to read it. A radar that makes it personalised, cited, and accessible to founders who could not otherwise keep up is — in a small way — a flattening of an information gradient that should not exist. That is not a business pitch. It is the reason this project sits in the playground rather than locked behind a service tier.

The companion posts in this series — Agents vs Automation and Multi-Tenant Agent Architecture — are the theoretical scaffolding. UK AI Radar is what they look like in 1,200 lines of code on a real problem.

If you are working on something adjacent, or want to discuss adapting the pattern to your vertical, get in touch.

Get weekly intel — courtesy of intel.hyperdrift.io

← All posts2026