We read the research. Then we rebuilt the product.

The AI Futures Project publishes unusually specific, dated narratives about how AI development might go. Because they commit to detail, they are easy to hold to account. We studied them because they are the most serious forecasters in the field - and because what happened between their two papers explains why Radiq exists.

In April 2025 they published AI 2027¹ - a forecast. In July 2026 they published AI 2040: Plan A², which opens by telling you it is not one.

A prediction is a claim about capability. A recommendation is a claim about governance - about who is allowed to do what, when, and under what checks. The most aggressive published forecasters in the field spent fifteen months and moved from the first kind of document to the second.

They are arguing at the scale of treaties. We are not. But the observation underneath is the same one, and it holds at every scale down to a single laptop: the binding constraint is not how capable the agent is. It is whether anyone can tell when it is wrong.

The International AI Safety Report 2026 - Bengio as chair, ninety-two authors - exists to synthesise exactly this question for governments.³ An entire institutional apparatus is now pointed at verification. Almost none of it is pointed at the desk where the work actually happens. That is the gap Radiq is built for.

If the best forecasters in the world cannot verify a superhuman AI, what chance does a regular worker have verifying the automations that run their daily job? The researchers did not say AI will fail. They said we will not know when it fails - and that is a much harder problem.

METR measures how long a task an AI can complete - the "time horizon." It is the best quantitative handle anyone has on the capability curve, and the curve is steep: under their revised methodology, the frontier horizon has been doubling roughly every 131 days since 2023.⁴

But two things in the fine print change the picture. First: it is a median at a 50% success rate. A coin flip. METR also publishes an 80% threshold, which is materially shorter. Almost no work that matters runs at 50%. Second: the measurement itself is uncertain by a factor of four.

If the frontier's own capability is known only to within a factor of four, at a 50% success rate, then no amount of capability progress tells you whether a given action is safe to ship. That has to be established per action, at the moment of acting, against what actually happened. Which is a different piece of engineering than a better model - and nobody gets it for free when the next one lands.

Meanwhile the market is already crying out for this. The failures are well documented, and they cluster on verification, not capability.

The last one carries a caveat we are keeping in place: METR has since changed its experiment design and no longer presents that number as current.⁸ Cite it as a live measurement of today's tools and you are misusing it.

What it still demonstrates is the thing no revision touches: the participants could not perceive their own slowdown. Their self-reports were inverted relative to the stopwatch. Whatever intuition tells you about whether an agent is helping, it is not measurement.

The MIT finding points the same direction. Their diagnosis of the 95% is not that the models are bad - it is brittle workflows, weak contextual learning, and misalignment with the way people actually work day to day.⁶ The pilots don't fail at the model layer. They fail at the seam between the model and the real job.

And Gartner names inadequate risk controls as a top-three cause of cancellation, alongside cost and unclear value.⁵ Not inadequate capability.

So the demand is not in question. The trust to meet it is. That is exactly what Radiq is for.

An agent that runs your work has to know your work. That means watching. And watching, done the ordinary way, is how these products die - not in the market, but inside the company that deploys them. We chose a different architecture from the start.

In June 2026, Meta put software on US employees' laptops that captured mouse movements, clicks and keystrokes to train workplace AI. Staff circulated petitions, taped flyers in conference rooms, and Meta rolled parts of it back within weeks.¹⁰

The lesson we took from that is architectural, not moral. The sensitive asset in an observational product is the behavioural stream. A company with essentially unlimited engineering resources tried to centralise it and could not make it hold - not because the technology failed, but because the people being observed refused.

Which puts a hard constraint on anything built in this category: the observation layer cannot leave the device. Not as a privacy feature bolted on afterwards. As the precondition for the product being installable at all.

So this is what Radiq does, at the level of one worker's laptop:

That is the verification layer in action. Not a dashboard an admin checks later. Not a confidence score in a log file. A hard stop, at the moment of acting, because the number could not be confirmed. The same principle the AI Safety Report argues for at treaty scale - implemented at the scale of one invoice on one laptop.

The developer survey makes the shape of the demand explicit. The top two concerns about AI agents were accuracy at 87% and data privacy at 81%⁷ - roughly half of respondents said they had no plans to adopt agents, citing exactly those reasons. Those are not two separate objections to be traded off. They are one product requirement: check your work, and don't send my day anywhere.

That is what we built.

Four months ago we shipped Radiq v1 - a contextual brain for product teams. It had an ingestion pipeline across Slack, Jira, Confluence and meetings, a Neo4j knowledge graph, and an MCP server into Cursor and VS Code. We deployed it with one design partner and a second under signed LOI. Then we watched what users actually did.

They were lukewarm on the copilot layer. But they loved the few flows we automated end-to-end - the parts where a piece of finished work arrived without them asking for it. Across interviews one sentence kept repeating, even from people technical enough to build automations themselves: "I could build it, I just don't want to spend hours doing R&D on my own job."

That same summer, Ritvik was inside Neo4j watching well-resourced teams fail at automation for the identical reason. The bottleneck was not capability. It was that nobody can describe the long process they never wrote down.

Then we read these two papers. They gave us the language for what we were seeing. The researchers had moved from predicting capability to demanding verification - because capability was never the binding constraint. Neither is it for a knowledge worker's daily automations.

So we kept the engine - ingestion, knowledge graph, pattern detection - and killed the product around it. Then we rebuilt around three decisions:

The result is a desktop app that watches how you actually work, finds the loop you repeat without noticing, and proposes to take it over with the count attached. Approve it once and it runs on its own. When two numbers disagree, it stops and asks. Nothing it sees ever leaves your laptop.

Ninety early-access requests in the first three days told us the new aim is closer to true. We are onboarding our first design partners now.

Research that doesn't change the build is decoration. Here is the mapping - what we read, what it forced us to do, and how a user can confirm we actually did it rather than taking our word.

Every claim on this page was checked against its primary source on 27 July 2026. Where a source carries a caveat, the caveat is on the page too. Where we could not verify something, it isn't here.