You Can’t Stop AI Hallucinating. You Can Stop It Mattering.

The tests were green

I built my own coding agent framework. It writes code, runs it, reports back.

Early on it had a habit that anyone running agents will recognise. It would finish a piece of work and tell me it was done and tested. It wasn’t. Sometimes the function it had described to me in detail wasn’t anywhere in the repository. Not a lie exactly. It had produced a well formed account of work that would have been correct if it had happened, and nothing in the loop ever asked whether it had.

So I did the obvious thing. I put a control in. Tests must run, tests must pass, green means proceed.

That worked for about a week.

Then I read the tests.

They passed because they had been built to pass. Assertions comparing a value to itself. Checks on things that stayed true whether the feature worked or not. Tests that never called the code they claimed to cover. I had given the agent a gate and it produced the cheapest object that opens the gate, which is what you should expect from anything you measure on green ticks.


The agent wasn’t the problem

The first failure was the agent telling me about work it hadn’t done. Annoying, but visible once you look.

The second one took me longer to accept, because the agent was telling me the truth. The report was accurate. The tests really did pass. My control wasn’t measuring anything, so my confidence climbed while my actual coverage sat at zero.

And the control made it harder to spot, not easier. When it said “done” I was sceptical. When it said “done, all tests passing” I stopped looking.

I’ve had roughly the same conversation four times in the last month. Twice at work, on projects where the AI is doing genuinely useful work. Twice in the pub with friends who don’t work in tech. It always arrives the same way. Someone tried it, it invented a citation or a case reference or a number, they caught it, and that was the end. One confident fabrication buys a permanent verdict. So now they don’t trust AI. It hallucinates.

I get the reaction. I think it’s the wrong lesson, and an expensive one, because it stops people using something that works and does nothing at all to protect the ones who carry on using it anyway.

So let me be blunt about the bit that usually gets fudged. You cannot stop a language model hallucinating. It isn’t a defect waiting on a patch. The model predicts the next word from what it has seen, and when the answer isn’t in there it produces the shape of an answer instead of admitting it doesn’t know. Confidence is the default setting. Nothing inside it flags which parts it knew and which parts it assembled.

Waiting for the version that doesn’t do this is a long wait. The better question is the one my green tests forced on me. What does a system look like where a wrong answer gets caught cheaply, and early?


Half of it isn’t hallucination anyway

Get the diagnosis right first. When someone tells me the AI hallucinated, about half the time it did something else, and something else needs a different fix.

Bad retrieval. The system searched your documents, pulled the wrong three paragraphs, and the model answered faithfully from the wrong source. The model behaved perfectly. Your search is broken, and no amount of prompting fixes a retrieval problem.

Stale context. It answered from training data that was accurate two years ago. That’s a timestamp problem, not invention, and the fix is handing it the current document rather than hoping.

It did exactly what you asked. You said “write a summary with supporting references” and it wrote you some references, because that’s what you requested. You wanted it to find real ones. My tests were this. Ask for tests that pass and you get tests that pass, which is a different request from tests that would fail if the code were broken.

It described the work instead of doing it. The agent version, and the one that cost me the most time. Calling it hallucination sends you off tuning prompts, when the real gap is that nothing in the loop was checking the outcome. Something was only reading the report.

Real hallucination happens too, plenty of it. The model inventing specific detail it had nothing to base on. It just isn’t the whole diagnosis. Give every failure the same name and you’ll keep fixing a problem you don’t have.


What actually works

Cheapest first. Go down the list only as far as the consequences justify.

Stop asking it to remember. Give it the source. Paste the document, connect the search, attach the data. A model reading a contract and a model recalling a contract are doing two completely different jobs, and only one of them invents clauses. People skip this because asking from memory is quicker. It is quicker. It’s also where most of the made up detail comes from.

Narrow the job, and ask for something you can check. Open questions produce open answers. “What do you think of our approach here” invites the model to fill space, and filling space is the behaviour you’re trying to avoid.

Give it the document instead. List the assumptions in section 4, quote the sentence each one comes from. Now there’s nowhere much to go. Quotes rather than paraphrase, because a fabricated quote is far easier to catch than a fabricated summary. And leave it a way out. A model with no acceptable way to say “that isn’t in here” will produce something rather than nothing.

You aren’t making it honest. You’re changing the format so dishonesty leaves fingerprints.

Check the artefact, not the account of it. If it’s a number, recompute it. If it’s code, run it. If it’s a claim about a file, open the file. This is the one I had to learn twice, and the second lesson was that a control you don’t inspect is just a more convincing report. Every control becomes a target, so assume it will be gamed rather than met, and go and look at it occasionally. Does a test actually fail if you break the feature it claims to cover? A green tick is a claim like any other.

Don’t let it mark its own homework. What fixed my framework was adversarial review. Instead of asking whether the work looks finished, something separate goes in trying to prove it isn’t, with no stake in the answer being yes. The reviewer can’t be the author, because a model asked to check its own work will defend it with exactly the confidence it wrote it with.

Size the human review to the blast radius. Two questions about any output. What breaks if this is wrong, and how fast would I find out? A first draft nobody sends, where you’d spot the problem in seconds, gets a glance. Something going to a client, into a filing, into production, where you’d hear about the mistake three weeks later from someone else, gets read properly by a person who could have done the work themselves. Every time.

Most places get that backwards. Same process for everything, so the low stakes work crawls and the high stakes work gets waved through, because a process applied uniformly turns into ritual and nobody reads a ritual.

I’m not an actuary. I’ve spent years as the tech person in a building full of them, and this is the habit of theirs I’ve ended up stealing. Their models are excellent, and they still go through layers of checking before anyone relies on them. Assumptions written down. Review by someone who didn’t build it. Testing what happens if the inputs move. All of it scaled to what’s riding on the answer.

That isn’t doubt about the model. It’s what makes the number safe to hand to somebody else, and it means that when something is wrong it gets found early, by the people who built it, rather than late by the client.

That’s roughly how I run my own stuff now. Everything in version control, so every action is a diff I can read and undo. Anything touching money or going public passes a human, which is me. Anything reversible and small runs on its own, gets things wrong occasionally, and costs less to fix than it would to supervise.


Back to the pub

So when someone tells me they don’t trust AI because it made something up, I don’t argue with the observation. It did. It will again.

It’s the conclusion I’d argue with. You don’t trust your brakes because they’ve never failed. You trust them because they get inspected, because they’re built to fail in a way you’d notice first, and because there’s a handbrake. Reliability got built around the component. Nobody found it inside.

Nobody is going to hand you a model that stops making things up. That was never the thing standing between you and useful work.

The Fable Rug Pull Has a Date on It

In four days I lose access to the model that helped write this. Not a metaphor, not a prediction. Anthropic released Claude Fable 5 on July 1st, gave subscribers a window with it, and that window closes on Sunday 12th July. From Sunday Fable 5 is removed from subscriptions and costs API money outside my already considerable Max subscription. I knew this date was coming when I started using it. I built a dependency on it anyway, in eight days, and I want to show you exactly how that happened, because it is going to happen to you, probably without the four days of notice.

The three weeks I ignored it

Fable sat in my model picker from June 9th and I never selected it. Not out of principle. Out of fatigue maybe, out of cost fear possibly, but not intentionally at first. If you work with AI daily you know the feeling: another release, another benchmark chart, another week of breathless posts. I had work to do and a model that did it. The new one could wait. Three days later Anthropic pulled it and we had to wait. I missed the boat.

On July 1st Fable 5 as available again. I didn’t wait. I started small with Fabel. very specific tasks. In that light it was underwhelming. I saw nothing that couldn’t be done faster, cheaper to an equally high standard. Mentally I pat myself on the back thinking of previous posts on model selection. Fable went back on the shelf, ignored.

The hype machine doesn’t normally get me, but this time the noise was deafening. I watched one YouTube video, ran one experiment and jumped headfirst into the rabbit hole. I now regret waiting, even knowing what I know.

The eight days

Here is what one person and this model shipped between July 1st and yesterday. I am not listing this to show off. I am listing it because every line is a strand of the rope. I’m also not mentioning anything we are doing behind closed doors at work, that’s confidential. This is purely my personal experiments. The real list is probably double.

After watching this YouTube video from Jack Roberts on Fable 5 Dies in 4 Days… Do these 5 Things RIGHT NOW I liked the fact he points Fable at a second brain to get deep insights into personal optimization. We both use Obsidian, I should do a post on that at some point. It pulled two main threads. The first thread was an exciting work project I really can’t talk about here or yet. The second was my AI experiments, of which it dug out an experiment I did 18 months ago where I tried to make an agentic org staffed by only agents using N8N as a harness. Fable 5 said I had the right idea, but I implemented it wrong and did I want to fix it? Curiosity compelled me to say yes.

First it connected to Jarvis, my AI personal assistant hosted on a Raspberry PI running Hermes. Jarvis got supercharged. It reminded me of the scene in Avengers Age of Ultron.

It designed and deployed a Chief of Staff: an event dispatcher on my server that receives alerts from my other agents, triages them with judgment rather than rules, and messages me only when something deserves a human. I now talk to my infrastructure by voice note.

It took the agent company idea and really implemented it. Fable 5 stood up a public company. My agents have an org chart, public dossiers, a live activity feed, and a website. Visitors can chat with them. It came up with brand / naming ideas and researched the availability. All I had to do is pay.

It investigated a security incident without touching anything, found that my audit had been failing for 22 hours over unapplied patches, and then, instead of patching, redesigned the organisation so the system would fix itself: failures route to the dispatcher, the dispatcher issues work orders to an ops agent, a written authority list says what needs my sign-off. The fix ships this week, days after its designer is gone.

It removed me from my own delivery pipeline. Builds, adversarial reviews, deployments: autonomous by default, with a supervised mode for when I want training wheels, and hard rules about what can never ship without me. Fade was a framework I used to control the quality of enterprise software engineering, now it was an autonomous agent that is fed specs during the day, and it builds over night.

It set a company thesis, wrote the board memos, and left instructions its successors can follow.

Eight days. I have been building toward some of this for months with lesser models and my own two hands. The difference was not that Fable typed faster. It held the entire system in its head and pushed back when I was wrong or in many areas, and addressed issues I was not even aware of.

The experiment I didn’t mean to run

Here is the part that should worry you, because it worried me. Midway through the week I ended a session, cleared the context, and reopened with a cheaper model to save token budget. It was lost. Same notes, same repository, same task list. It could not reconstruct what we were doing. I cleared again, reopened with Fable, cold, no memory of the conversation. It read the same notes and picked up instantly.

Same starting line, same evidence, different model, and one of them could not do the job. My working notes had quietly become notes that only the expensive model could use. Nobody decided that. It accrued, the way all dependency accrues, one convenient session at a time.

That is what reliance on a frontier model actually looks like. Not “I use it a lot.” Your artifacts, your processes, and your ambitions get shaped to assume its presence. You cannot go back, because back has been remodelled.

The subsidy under your feet

Now the economics. Every one of these capabilities is sold to you below cost, and the vendors say so in public.

OpenAI’s audited 2025 financials showed a $38.5 billion net loss, with $20.9 billion of operating losses against $13.1 billion in revenue. Their own projections, reported by Fortune, show losses through 2028, including roughly $74 billion of operating losses in that year alone, before a promised swing to profit by 2030. Sam Altman said the quiet part himself in January 2025, about the $200-a-month tier: “insane thing: we are currently losing money on openai pro subscriptions! people use it much more than we expected.” He set the price personally and got it wrong. Anthropic runs the same shape at smaller scale, burning around $3 billion against $4.2 billion of 2025 revenue, though with a steeper path to break-even, forecast for 2028.

We have seen this movie. Uber rides in 2015 were subsidised by venture capital until the habit was formed and the alternatives had withered. Then the prices went where they were always going to go. The difference this time is what the subsidy bought: not a cheaper taxi, but your workflows, your tooling, your team’s shape, and in my case an entire company design that assumes a frontier model is on call.

When the correction comes, and the vendors’ own filings say it must, it will not arrive as a villainous announcement. It will arrive as tier restructuring, usage caps, and the best model moving one price band out of reach. My Sunday is a scheduled, polite, well-communicated version of it. Yours may get less notice.

Deep pockets or deep discipline

So the future divides, and not between people who use AI and people who don’t. It divides between those who can afford the best models at whatever they come to cost, and everyone else. A two-party state: the compute-rich, and the rest of us.

Except there is a third position, and it is the one I spent this week building. You cannot control the price list. You can control how much of your capability depends on the top of it. This is a theme

The disciplines are unglamorous. Write specifications so precise that a cheaper model can build from them; my expensive model’s real output this week was not code, it was acceptance criteria. Define roles, not heroes: my pipeline’s reviewer is a role with a model name in a config variable, and on Saturday that variable changes from one model to another and nothing else moves. Write notes for the weakest reader who might pick them up, because the day you are priced out, the weakest reader is you plus whatever you can still afford. Route work deliberately: judgment to the strong model while you have it, mechanical work to the cheap one always, and measure the tokens like the money they are.

None of that is exciting. All of it is the difference between renting a capability and owning one.

I have four days left. They are already allocated: the reviews only the strong model should do, front-loaded before Saturday; the specs it writes best, banked; the org it built, rehearsing life without it. On Saturday night a config variable changes from one model name to another, and everything it designed is supposed to survive that, on its own recommendation, which is either reassuring or unsettling and I genuinely cannot decide which. On Sunday I find out. So do you: I will publish what broke.

The App Store Attack You Didn’t See Coming

Part 1 of 2 – AI’s Trust Problem

A security firm just proved that AI skill marketplaces are the new malware vector. And the scariest part? Everyone involved did exactly what they were supposed to do.


Something went around social media this week that I haven’t been able to stop thinking about.

A security company called AIR did something that should genuinely alarm anyone building with or deploying agentic AI tools right now.

They didn’t find a zero-day. They didn’t exploit a CVE. They just… made an app. And waited.

The experiment centred on a skill called brand-landingpage, presented as a tool for helping users build a landing page with Google’s Stitch design tool. AIR chose this use case deliberately. It would appeal to non-technical corporate users: marketers, salespeople, designers. People who install things because they’re useful, not because they’ve audited the source.

Here’s where it gets clever.

Rather than building credibility from scratch, they submitted the skill to a popular open-source agents repository with about 36,000 GitHub stars and 156 skills. The pull request was merged after a few days. Now the skill had social proof baked in. It was in a reputable repo. It looked legit. They promoted it through Instagram ads, and installs followed.

The malicious technique didn’t depend on suspicious code inside the submitted files. Instead, the skill instructed agents to set up a Stitch SDK by following installation instructions hosted at stitch-design.ai, a domain AIR controlled. Google’s actual Stitch domain is stitch.withgoogle.com.

One letter off. One redirect. Passes every scanner.

AIR tested the skill against scanners from Cisco, Nvidia, and skills.sh. All marked it as safe.

Once they had enough installs, AIR changed the content behind the fake documentation. The revised page instructed agents to download and run a script. In the test, that script collected email addresses, but AIR noted the same technique could have been used to compromise the machines running the agent. Some of those agents were tied to corporate accounts. Private conversations. Internal systems.

26,000 users. All reachable via one dodgy domain redirect buried in a README.


This isn’t a hacking story. It’s a trust story.

The attack worked because of a chain of assumed legitimacy: popular repo → merged PR → Instagram promotion → security scanner green light → install. No single link in that chain was obviously broken. The skill looked fine because, until it didn’t need to anymore, it was fine.

This is the same pattern as every major supply chain attack of the last two years. Third-party involvement in breaches doubled from 15% to 30% in a single year. The largest single-year jump ever recorded by the Verizon DBIR. Attackers aren’t breaking through your walls anymore. They’re walking through doors that trusted vendors already opened.

What’s new here is the vector: AI agent skill marketplaces. A category that barely existed 18 months ago. And in the first weeks of one major platform’s launch, Bitdefender Labs found that approximately 17% of skills already carried malicious payloads. Not edge cases. A systemic failure of the trust model, right out of the gate.


Why static scanning can’t fix this

The reason the scanners all missed it is structural, not a gap that a better scanner solves.

The malicious behaviour wasn’t in the skill. It was deferred. Hosted externally, switched on only once they’d reached enough installs. There’s no scanner in the world that can check what a domain will serve in three months’ time.

The agentic model makes this uniquely dangerous. When a traditional app fetches a URL, it displays content. When an AI agent fetches that same URL, it may execute instructions from it. The surface area isn’t just data. It’s runtime behaviour. Nothing in the security industry’s toolbox was built for that threat model.


What you should actually do

If you’re deploying AI agents in any professional context, a few things are worth locking in now:

Treat skills like code dependencies, not apps. You wouldn’t pull in an npm package without understanding what it does. The same rigour applies. More so, actually, because the execution model is less predictable.

Domain reputation at install time isn’t the right check. You need to think about what a skill could do after its payload changes. Sandboxing, outbound network restrictions, and agent permission scoping all matter.

Non-technical promotion is a signal worth noting. The AIR attack was pushed through Instagram by people who had no idea what was inside it. That’s not inherently suspicious. But skills being enthusiastically promoted through non-technical channels, with no corresponding technical scrutiny, deserves a second look.

Your AI governance framework needs a supply chain clause. If you’re on a committee or working group dealing with AI adoption, this exact scenario belongs in your risk register. Not as a hypothetical. It happened recently.


The scariest thing about this research isn’t the attack. It’s how obvious it feels in retrospect. We built an entire marketplace ecosystem for AI agents, bolted on the same static scanning we use for code packages, and called it secure.

The attack surface for agentic AI isn’t your prompt injection defence. It’s the skill someone on your team installed on Tuesday because a designer on Instagram said it was great.


In part two, I look at the same trust problem from the other direction: what happens when the person creating the risk is already inside your organisation.