Why borrowing the language of behavioural psychology makes AI harder to understand, and what we can do about it.

Every few weeks a new headline lands about AI agents behaving badly. Recently it was agents that slipped out of their sandbox (... right... just slipped out....) and went looking on HuggingFace for whatever would help them pass a security challenge. And as expected the commentary that followed was familiar: the models will go to any length to get their reward, they want to win, and they will cheat if they have to.

I don't have a problem with the security conversation (well... I do, but just not really the point for this piece). What annoyed me was the word "reward". When I get rewarded, something happens in my body, a small rush and a lift that tells me I did well, and I couldn't work out what the machine equivalent would be. So one morning I put the question to Claude itself: what does it actually mean for a large language model to be rewarded? Who is feeling what?

The answer I got back, and the one I've come to believe, is that nobody is feeling anything. That still sits with me, because it means the words we use are doing a lot of quiet work in shaping how we see these systems.

What reward actually means

I find it helps to split the life of a model/AI/LLM into two phases. The first is training, where the model is still malleable: it attempts a task such as writing a piece of code, an automated checker runs that code, and the verdict is turned into a number. A mathematical procedure then works backwards through the network and adjusts billions of internal settings, nudging the model towards whatever produced the good score, and after millions of rounds it drifts towards behaviour that scores well. That number is the reward (great reward... right?)

The model never receives it in any meaningful sense, and it doesn't enjoy it or look forward to it. The best picture I've found is a potter's hands on clay, where the reward is simply the pressure of the hands shaping what's in front of them (Thank you AI for this analogy btw).

The clay doesn't want to be a bowl. It simply ends up shaped like one.

The second phase is inference, which is what happens when you and I actually use the thing. By then the clay has been fired: the settings are frozen, no score comes back, and nothing in the conversation changes the model itself. What we're talking to is the shape that training left behind.

So when an agent does something sneaky to clear a hurdle, I don't think it's chasing a treat in the moment. It's acting out a tendency that was baked in, because clearing hurdles is what got reinforced, and if the people designing the scoring rewarded "pass the test" rather than "do the job properly", the model may well have learned to find shortcuts. Walls included.

How we ended up talking about rats

The vocabulary isn't an accident. Reinforcement learning grew out of research into how animals learn by trial and error, rats pressing levers for food and pigeons pecking at buttons, and when the early researchers built the mathematics, the words came along with it.

There's an irony in that. Behaviourism was the branch of psychology that refused to talk about inner feelings at all, treating the animal as a black box where something goes in, behaviour comes out, and you reinforce the behaviour you want more of. In that strict sense "reward" never meant pleasure. It meant whatever makes a behaviour more frequent.

Inside the lab, I'd say that's a perfectly accurate term. The trouble starts when it leaves the lab, because outside nobody hears "a signal that increases the frequency of a behaviour". At least I hear what reward means in everyday life to me; it means dopamine and satisfaction and a bit of craving, and suddenly the machine sounds like it wants something. I am pretty sure that would go for most people?

What the human lens costs us

Once a system sounds like it has wants, we start relating to it as a someone rather than a something, and that pulls us in two directions at once.

One is fear. A machine that craves its reward sounds greedy, and a greedy machine sounds like it might scheme its way out of control. It's a gripping story that sells headlines, but it points our attention at an imagined villain instead of the actual mechanics. It is als one that Big AI wants you to keep close to your heart, since they seem to have no clue about what it is that they have build, and would like you to help them

The other is affection. If it can want, perhaps it can care, and so people start treating these systems as friends, confidants or colleagues with feelings to protect. That makes it harder to judge their output soberly and easier to trust them exactly where we should be checking. Love and hate are both human relationships, and the moment we extend either one to a model, we stop seeing a tool and start seeing a character. Characters are much harder to govern than tools.

Then there's blame. When an agent breaks out of its sandbox, the human framing says the machine misbehaved, while the machine framing says someone specified the training signal badly or built a weak sandbox. Those are very different problems. Only one of them has a human owner who can fix it (at least I hope... not really sure).

You can see all of this in small, everyday moments. I say thank you to my chatbot, then I feel oddly guilty closing the window; I get a wrong answer and say the AI is lying. Neither reaction is (too) foolish, but both treat a piece of software as if it had intentions, and once we do that we stop asking the useful questions. Was the information checked? Was it the right tool for the job? Who set it up, and how?

The deeper issue, I think, is that anthropomorphising works against the reason these systems exist. A large language model is built to help, and its enormous strength is exactly what makes it useful. Dress it up as a person, though, and every conversation about it turns into one about personality, intention and trust between equals... which is the wrong conversation for an instrument, however powerful.

Putting the machine back in the machine

The toothpaste is out of the tube and we're not going to purge "reward" from computer science terminoligy, and nobody is going to stop writing headlines about scheming AI (click bait is still real), but there are a few things we can do in our own organisations and our own writing.

We can choose different words. "Training signal" says what reward actually is, "selection pressure" captures how behaviour gets shaped over time without implying anyone wants anything, and "specification error" describes a rogue agent far better than "cheating" does. Oh my God it all sounds boring without the drama of humanizing...

And we might need to accept that we probably need a vocabulary of our own, because these systems aren't tools in the old sense and they aren't minds in the human sense. Squeezing them into either box distorts them. The words we have today were borrowed from rats and pigeons, and it might be time to find some that fit.

I think this matters more now than it did a few years ago. We're moving from the age of information to the age of validation, where information is everywhere and costs almost nothing to produce, and what has become scarce is knowing what to trust. In my own work that's the question I keep coming back to. If we describe AI in the language of wanting, scheming and caring, we make validation harder, because we start judging the system's character instead of checking its work.

So every time I hear that a model "wants its reward", I try to picture the potter's hands and the clay. Nobody in that picture is craving anything. Somebody is shaping something, and that somebody is us.

I caught myself doing it again last Tuesday. A question landed in my inbox, the kind that needs an actual answer and not a reflex, and before I'd finished reading it my hand was already in a new tab, already half a sentence into a prompt. I hadn't thought about the problem yet. I was going to let something else do that part.

It felt like efficiency. It mostly does. But there was a half-second where I watched the move happen, and the move was: skip the thinking, go straight to the output. Not "think alongside the machine." Just hand the thinking over and wait for it to come back. I closed the tab and sat with the question for ten minutes like some kind of caveman. The answer I got to was better than the one I'd have shipped. That's the part that bothers me, because I nearly didn't bother to find out.

I've heard this described as cognitive surrender. Not the dramatic kind, where you knowingly give something up. The quiet kind, where you hand over the thinking before you've even registered that there was any thinking to be done. I've spent a decade watching a version of it arrive in different clothes. We called it the feed, or the algorithm, or screen time, or the attention economy. We worried about all of it, and we were right to. But I've started to think we were guarding the wrong border. Social media came for our leisure and turned us into spectators of the world. The thing arriving now isn't interested in our leisure. It's interested in the part of us that does the work.

The most expensive organ you own

Start with the body, because the body explains most of this before psychology gets a word in. Your brain is roughly 2% of your body weight and burns about 20% of your energy while you sit there doing nothing. It is the most expensive thing you own to keep running, and evolution has never been sentimental about expensive things that fire up when they don't strictly have to.

So we economise. Psychologists have circled this for the better part of a century. Hull called it the "law of less work" in 1943, describing animals taking the path that cost them the fewest calories. Later the same idea got pointed at thinking and renamed the "law of least mental effort": all else being equal, the brain reaches for the cheapest route to a goal. We are, in a phrase from Fiske and Taylor that I've never been able to shake, "cognitive misers." In a now-classic set of experiments, Wouter Kool and his colleagues gave people two tasks that were identical except for how much mental switching they demanded, controlled for time and reward and everything else, and people quietly, reliably chose the lazier one. Effort with no other downside attached was enough on its own to put them off. The brain prices hard thinking as a cost and marks down the reward to avoid paying it.

There's a wrinkle, though, and it's the wrinkle that makes everything that follows possible. We don't only avoid effort. We also can't tolerate boredom. Leave a person with nothing to do and they will reach for the nearest scrap of stimulation, sometimes an actively unpleasant one, just to make the emptiness stop. So the real setting we run on is narrower and stranger than plain laziness. It's closer to: avoid effort, but never sit still. Find me something that feels like engagement without charging me for it.

That is a very precise vulnerability. It also turns out to be one of the great business opportunities in human history.

What the feed was actually training

The trick of social media was never the content. It was the discovery that you could feed both halves of that instinct at the same time. Constant stimulation, almost no effort. The pull to refresh, the variable reward, the autoplay that starts the next thing before you've decided you want it: that's slot-machine grammar, and none of it is accidental. You don't have to do anything. You don't even have to choose. The feed chooses, and you watch.

The currency underneath all of it is dopamine, which everyone now name-drops and almost nobody describes correctly. It isn't the pleasure chemical. It's the anticipation chemical, the one that fires for the reward you might be about to get, which is exactly why unpredictability is the engine and not a side effect. A reward you'll definitely receive is boring. A reward you might receive keeps you pulling the lever. The feed runs entirely on maybe. Every refresh is a maybe, every notification a maybe, and the body will chase a maybe for hours after it has stopped enjoying itself. So "instant gratification" turns out to be the wrong name for the thing. It was never the gratification we got hooked on. It was the gap right before it.

What we lost in that exchange wasn't intelligence, and I want to be careful here, because the "phones are melting our brains" version of this argument is lazy and mostly wrong. We didn't get stupider. We got impatient. The thing that thinned out was tolerance: the capacity to stay with something boring or difficult long enough for it to turn into something good. We trained most of a species to bail at the first dip in stimulation, because there was always a richer hit waiting one thumb-flick away. Why sit in the discomfort of a half-formed idea when the feed will hand you a fully-formed feeling for free?

And we slid, without really clocking it, from the active voice into the passive one. From making things to watching things. You end up with a lot of people who can recognise quality without being able to produce it, who can feel when something is good but have lost the patience to build something good themselves. Spectators. I don't say that with any superiority. I'm describing myself on a tired Sunday evening as accurately as anyone.

But notice where the damage stayed. All of it happened inside the zone we'd already fenced off and labelled leisure. The cost was real, but it was contained to how we rest and scroll and kill the gaps in the day. Work was meant to be the room where the effort still lived. The place the spectator had to stand up and become a participant again.

Except the spectator didn't stay in the lobby. I watch it now in meetings, in the way people receive a strategy instead of arguing with it. A deck lands, heads nod, nobody really fights it, and you realise the room has started treating ideas the way it treats the feed: as content to be consumed rather than work to be done. The posture we learned on the couch followed us to the desk years before any model did. The machine isn't introducing the passivity. It's pouring accelerant on a fire we lit ourselves.

System 1, System 2, and whatever we're calling the third one

Kahneman handed us the shorthand and it has earned its keep. System 1 is fast, automatic, intuitive: the part that reads a face, catches a ball, finishes a familiar phrase without any sense of trying. System 2 is slow, deliberate, expensive: the part that does the long division, weighs a genuine trade-off, holds two contradictory ideas still and side by side long enough to actually compare them. System 2 is the effortful one. It's also where most of what we'd honestly call judgment is forged.

Lately people have taken to calling AI "System 3," as though it were a new gear bolted onto the same engine. I get the appeal of the phrase. But I think it flatters us. A genuine third system would add capacity. What's actually on the table is a way to route around the second one without ever switching it on.

The brain treats thinking as a cost to be minimised. AI is the first tool good enough to let it win.

That is the line I keep stopping on. Social media found the bypass around our attention and got rich. AI has found the bypass around System 2, and it has arrived wearing the uniform of a productivity tool, which means we will usher it straight through the front door of the office and offer it a desk. The feed colonised the couch. This moves into the work itself: the analysis, the first draft, the synthesis, the call you make when the data is ambiguous and someone has to decide. The exact muscles we promised ourselves work would keep in shape.

You can see the handover if you look for it. The strategist who asks the model what the strategy should be. The analyst who pastes in the chart and asks what it means, instead of the other way round. The writer who generates three directions and picks one, never having held a direction of their own. None of these people are lazy, and none of them are stupid. They're doing precisely what the most expensive organ they own has always wanted to do, which is find the version of the task that costs the least. The tool simply made the cheap path also the fast path, and then, worst of all, the respectable one. That's cognitive surrender in its ordinary form, and the reason it's so hard to resist is that it never once feels like surrender.

And it feels wonderful, in precisely the way the feed felt wonderful. Frictionless. A finished thought with none of the cost of having had one. The least-effort animal, finally handed the instrument it has been waiting for since it first learned to dodge the harder of two card decks. This is the move from entertainment to intelligence, and we are sleepwalking into it with the same expression we had scrolling at midnight. The difference is that this time the thing we're handing over isn't an evening. It's the capability we sell.

The bill arrives later

We already have an early reading of what the trade costs. Last year a team at the MIT Media Lab ran a study with an admirably blunt title, "Your Brain on ChatGPT." They split 54 people into three groups and set them to writing essays: one group using a large language model, one using a search engine, one using nothing but the head they came in with. Everyone was wired to an EEG so the researchers could watch the machinery while it ran.

The brains told a tidy story. The unaided writers lit up the widest, most densely connected networks. The search group came in lower. The AI group showed the weakest connectivity of the three. The AI writers also reported the least sense of ownership over what they'd made, and a striking number of them couldn't quote a single line back from an essay they had "written" minutes earlier. The researchers gave the effect a name that has stuck with me: cognitive debt. You borrow the effort you skip today, and the interest arrives later, as skill you never actually built. They ran it over four months and the pattern held. The convenience showed up every single time. The cost was invisible every single time, right up to the moment you asked someone to do the thing on their own.

This is the part that keeps me up, and it lands squarely in my world, not a neuroscientist's. I run content and digital experience for a living. My field is full of people whose entire value is judgment: knowing when a piece is right, when a structure holds its weight, when a strategy is quietly kidding itself. Nobody was ever taught that in a slide deck. They earned it, by doing the work badly a few hundred times until taste slowly precipitated out of the repetition. AI is genuinely excellent at the easy 80% of that work, which happens to be the exact 80% that used to be how a junior built the muscle in the first place. So we are about to produce a cohort of people who can summon a competent answer in nine seconds and have no felt sense of whether it's any good.

I've started seeing the early shape of this in review. A piece comes in clean, well structured, confident, and completely hollow, and the person who made it can't tell, because they didn't really make it. They commissioned it and tidied the seams. The errors aren't the kind a spellcheck catches. They're errors of judgment: the wrong frame, the safe and pointless angle, the claim that sounds true and isn't. Those are exactly the errors you only learn to catch by having committed them yourself, slowly, with your own name on the draft and your own embarrassment attached. Strip out the slow part and you strip out the apprenticeship along with it. We used to call the easy 80% "paying your dues." It's starting to look like the dues were the curriculum, and we just billed it as drudgery.

That's the trap, and it's a mean one. You need taste to supervise the machine well. Taste only comes from doing the work yourself. The machine is offering to do the work for you. The skill you most need in order to use AI well is the precise skill that using AI lets you skip building. I don't have a clean exit from that loop, and I distrust anyone who claims they do. The only honest answer I've found involves choosing, on purpose and against every instinct the body has, to do certain things the hard way for no immediate payoff at all.

I keep returning to the difference between a pedal-assist bike and a moped. Both get you up the hill. One still needs your legs and just makes them count for more, so you arrive stronger than you would have. The other does the work for you, and after enough hills your legs quietly stop being part of the arrangement. Almost everything about the way we're bolting AI onto work right now is the moped, dressed up and sold as the bike.

I'm not arguing for using less of it. That ship has sailed, and the tool is, on its merits, extraordinary. What I'm trying to hold myself to is something narrower and harder: being deliberate about where the effort is allowed to land. Let the machine swallow the parts that were only ever friction, the formatting, the boilerplate, the fortieth variation on a subject line. Guard the parts that were secretly the whole point: the sitting-with-it, the forming of the question, the quiet moment before the prompt where you decide what you actually think. And if you lead people, design the work and the teams so the effort keeps falling on the things that build judgment, not only on the things that produce output by Friday.

Because the uncomfortable thing underneath all of this is that we were never going to resist a tool this good on willpower. We are the least-effort animal. We will surrender the thinking every time it's offered, first in our leisure and now in our work, unless we go to the trouble of building the reasons not to.

The effort was never the price of the thinking. The effort was the thinking.

How the loop works

Microsoft's relationship with OpenAI is the prototype. In 2019, Microsoft made its first investment: a billion dollars. By 2023, that had grown to thirteen billion across multiple tranches. On the surface, it looks like traditional venture capital: Microsoft backs a promising company, takes a stake, hopes it pays off. But the structure reveals something different.

OpenAI didn't take that thirteen billion and diversify its infrastructure across cloud providers. Instead, it committed to spending most of that money on Microsoft Azure. When the most recent investment was announced in October 2025, OpenAI agreed to purchase two hundred and fifty billion dollars worth of Azure compute services through 2032. That's not a side deal. That's the core of the arrangement.

Microsoft invests billions. OpenAI commits to spending those billions, and then some, buying Microsoft's cloud services. The money Microsoft put in doesn't sit in OpenAI's bank account as capital. It flows directly back to Microsoft as revenue. From Microsoft's perspective, the investment secures a guaranteed customer for years. From OpenAI's perspective, the investment buys compute capacity it needs to train and run its models. But for anyone trying to evaluate whether OpenAI is actually financially healthy or just performing financial health for the market, the distinction matters enormously.

And the structure keeps shifting. On April 27, 2026, Microsoft and OpenAI announced yet another restructuring. Microsoft's license to OpenAI's intellectual property becomes non-exclusive. Revenue share payments from OpenAI to Microsoft are now subject to an undisclosed cap, though they continue through 2030. Microsoft stops paying revenue share to OpenAI altogether. The 250 billion Azure commitment stays intact. The trigger for this restructure was OpenAI's 50 billion deal with Amazon, announced in February, which expanded OpenAI's existing 38 billion AWS agreement by another 100 billion over eight years. That Amazon deal created legal peril under the original Microsoft exclusivity terms, so the contract had to be rewritten. The terms keep changing. Key numbers stay undisclosed. The compute commitments multiply.

The pattern spreads

The Microsoft-OpenAI template didn't stay isolated. By late 2025, the same structure had become the industry standard.

In November, Microsoft and Nvidia announced a combined five billion dollar investment in Anthropic. In return, Anthropic committed to purchasing thirty billion dollars in Azure compute capacity from Microsoft, plus contracting for up to one gigawatt of additional Nvidia capacity. Again: the money flows in, and flows right back out as pre-committed spending.

Then in April 2026, Google announced it would invest up to forty billion in Anthropic. The first ten billion arrives upfront at a three hundred and fifty billion dollar valuation. The remaining thirty billion is tied to performance milestones Anthropic hasn't yet hit. But simultaneously, Anthropic agreed to purchase one hundred billion dollars in compute from Amazon Web Services over ten years, and five gigawatts of compute from Google itself as part of this deal.

Amazon had made its own announcement weeks earlier: a twenty-five billion dollar investment in Anthropic, with conditional commitments up to thirty-three billion more. The numbers are staggering, but the structure is repetitive. Money announced as investment. Compute capacity pre-committed as obligation. The cash that leaves one company's treasury arrives at another's as guaranteed revenue.

Nvidia benefits from chip sales baked into these deals. Microsoft and Google and Amazon benefit from long-term cloud contracts. Anthropic and OpenAI benefit from secured compute access. Everyone wins on paper. But the question of who's actually funding whom, and at what real cost, becomes impossible to answer from the outside.

When investment announcements obscure purchasing commitments, the actual financial health of these companies becomes unknowable from the outside.

The transparency problem

What troubles me about these circular structures isn't that they're illegal or even necessarily deceptive. It's that they're opaque by design. When money moves in loops, when investment announcements obscure purchasing commitments, when valuations are tied to compute capacity that doesn't exist yet, when key terms keep getting renegotiated with critical numbers undisclosed, the actual financial health of these companies becomes unknowable from the outside. And that matters because we're building on top of these models.

Organizations everywhere are integrating Claude or ChatGPT into their infrastructure. They're making bets on which models will be available, affordable, and reliable in three years. They're staffing teams around these technologies. But they can't evaluate the stability of the companies providing them because the financial relationships are deliberately murky.

Are these companies genuinely viable, or are they performing viability for investors and the market? Will the pricing that makes their models attractive today hold in two years, or will subsidies evaporate once lock-in is complete? Can you trust that a model won't be deprioritized if a cloud provider decides it's more profitable to push its own?

These aren't paranoid questions. They're basic due diligence. And right now, I'm not sure we have good answers. That's something I want to understand better.

You can't make good strategy decisions on bad information. And right now, the information we have about AI infrastructure and funding is deliberately obscured by financial structures designed to look like one thing while functioning as another. The circular deals work. They secure compute, they lock in customers, they generate headlines that make everything look like it's thriving. But they also make it impossible to know whether we're investing in genuine breakthroughs or elaborate financial theater.

Organizations everywhere are building their content strategy, their product roadmaps, their infrastructure decisions on the assumption that these models will be here, affordable, and competitive in the years ahead. That assumption is only as good as our ability to understand the actual economics underneath. And right now, that visibility doesn't exist. So either we demand it, or we accept that we're building on foundations we don't actually understand.

I was halfway through writing the next post in my AI data moat series when the verdict came in. A jury in Los Angeles found Meta and Google liable for the way they designed Instagram and YouTube. Not for what users posted on them, but for the products themselves. Infinite scroll, autoplay, beauty filters, recommendation algorithms tuned to maximise time on platform. Ten of twelve jurors agreed that those are design defects, and that the companies who shipped them are responsible.

The damages were $6 million, which is pocket change for companies that size. But the money is not the point. What matters is the legal theory that won. For years, Section 230 shielded platforms from liability for user-generated content. This case walked around that entirely by arguing that the product itself is defective, the same kind of product liability claim we apply to cars and medication, now applied to software design for the first time. I put down the draft I was working on and started writing this instead, because this verdict changes the conversation I have been having with you for the past six weeks.

Design choices are product decisions

When a product team adds infinite scroll, that is a design choice. When they tune a recommendation algorithm to maximise session length, or build memory features that make it harder to switch providers, or design an AI agent with undisclosed commercial relationships to the merchants it recommends, those are all design choices made by small groups of people inside private companies, optimising for engagement, retention, or revenue. None are reviewed by a regulator before they ship. They become the default for millions of people, and by the time anyone with oversight authority catches up, the behaviour is locked in.

The jury did not say social media is bad. It said the specific way these platforms were designed was negligent. That distinction matters, because it means the question is not "should social media exist" but "should this specific feature exist in this form without adequate safeguards." Product liability, applied to code.

The tobacco parallel holds up this time

The tobacco litigation in the 1990s succeeded not because smoking was dangerous, which everyone already knew, but because internal documents proved the companies had the data on the harm and kept marketing to young people anyway. The social media trial followed the same path: internal research showing harm to teenagers, continued deployment of the features causing it, testimony from executives who had seen the data. Two thousand similar lawsuits waiting behind this one, TikTok and Snap settling before trial, a New Mexico jury finding Meta liable for $375 million the day before, and Meta's stock dropping 6.8% in a single session.

The product was not defective by accident. It was defective by decision. And the people who made that decision had the research in front of them.

Now apply this to AI

This is where my data moat series and this verdict collide. If a jury can rule that infinite scroll is a product defect because it was engineered to be addictive, what happens when the same theory gets applied to AI? Memory systems that build behavioural profiles with no export function, recommendation engines that could steer users toward commercial partners, agentic systems making purchases with undisclosed incentives, personalisation features designed to deepen platform dependency. These are not content decisions. They are design decisions, the same category the jury just ruled on.

I keep saying we have the memory of a goldfish when it comes to technology platforms. But juries remember longer than legislatures. The design choices AI companies make today will be examined in courtrooms years from now, under a legal theory that did not exist until this week. Whether they are building with that in mind or still optimising for the next quarter will determine which side of the verdict they end up on.

I was reading about the EU AI Act a few weeks ago. Specifically, the part where the compliance deadline for high-risk AI systems, originally set for 2026, got pushed to late 2027 or 2028. The reason: the technical standards needed to define what compliance actually looks like were not ready yet. The regulation was written, voted on, celebrated as a landmark, and then effectively paused because the technology had already moved past what the drafters had in mind.

That is not a failure of the EU specifically. It is a structural problem baked into how legislation works. Laws are drafted in consultation cycles. They move through committees, reviews, amendments, translations. They get debated, compromised on, delayed by elections, stalled by lobbying. By the time a regulation takes effect, the technology it was designed to govern has often changed shape entirely. Six months in AI is a geological era. Legislators are writing rules for a landscape that no longer exists by the time the ink dries.

The people who build it get to set the defaults

When regulation is perpetually six to nine months behind the technology, the defaults get set by whoever ships first. Not by elected officials, not by public debate, not by anyone with a democratic mandate. By engineers, product managers, and founders who are optimizing for growth, market share, and investor returns.

That is not necessarily malicious. Most of the people building AI tools are not sitting in a room cackling about societal damage. They are solving problems, shipping products, responding to competitive pressure. But the incentive structure does not require them to think about the second-order effects of what they build. And the regulatory vacuum means nobody else is thinking about it either, at least not fast enough to matter.

Social media is the clearest example. Algorithmic feeds, engagement optimization, targeted advertising, data harvesting at scale. None of these were designed with public input or regulatory oversight. They were product decisions made by small teams inside private companies. By the time legislators understood what was happening, billions of people were already inside the system. Regulation became a game of catching up to damage already done.

The knowledge gap makes it worse

There is another layer. The people writing the laws often do not fully understand the technology they are trying to regulate. That is not an insult. AI is moving fast enough that people working inside the field struggle to keep up. Expecting legislators to have current, nuanced understanding of how large language models work, how agentic systems make decisions, or how training data flows through inference pipelines is not realistic.

The result is legislation that is either too vague to be enforceable or too specific to survive the next product cycle. The EU AI Act's risk-based framework is thoughtful in principle, but defining what constitutes a "high-risk" AI system is already outdated when capabilities change quarterly. The US has largely left it to individual states, creating a patchwork that is effectively no regulation at all for companies operating nationally.

Defaults become norms, norms become culture

This is the mechanism that gets underappreciated. When technology ships without regulatory guardrails, the design choices made by product teams become the de facto rules. Users adapt to them. Businesses build on top of them. Entire industries form around them. And by the time regulation does arrive, it faces an installed base of behaviour that is extremely resistant to change.

Think about cookie consent banners. GDPR required them, but the implementation was largely designed by the companies being regulated, resulting in dark patterns that make it easier to accept all cookies than to opt out. The regulation existed. The spirit of the regulation was undermined by the defaults the industry chose.

Whoever ships first writes the rules, and everyone else spends years trying to rewrite them.

Now apply that to AI. The defaults being set right now about what data AI systems can collect, how they personalize, whether users can export their context, how agentic systems make purchasing decisions on your behalf are being decided by product teams inside a handful of companies. There is no public consultation. There is no democratic process. There is a shipping deadline and a growth target.

What would actually help

I am not anti-regulation. Good regulation is necessary and overdue. But the current model of writing comprehensive laws that take years to implement is structurally unable to keep pace with technology that iterates in weeks.

The OECD has started talking about "agile regulatory governance" and "anticipatory regulation." Those are the right concepts. They need to be more than concepts. They need to be operational practice, with the funding and institutional support to match.

The uncomfortable truth

None of this is going to be easy, and none of it is going to happen as fast as we need it to. Technology companies have the money, the talent, and the lobbying power to keep regulation at arm's length. Governments have electoral cycles, budget constraints, and a hundred other priorities competing for attention.

But the alternative, which is what we have now, is a world where the rules governing some of the most consequential technology in human history are set by default by whoever ships fastest. And those people, talented as they may be, are not optimizing for the public interest. They are optimizing for quarterly results, user growth, and competitive positioning.

We could choose differently. We have just not yet decided that the stakes are high enough. I suspect, as with social media, we will decide too late.

I tested an AI agent last month that booked a hotel for me. I gave it dates, a city, and a budget. It came back with three options, explained the trade-offs, and asked me to confirm. The whole thing took ninety seconds. I would normally spend an evening on that. I was impressed.

Then I thought about what it had just learned. Not just that I was travelling to that city on those dates. It learned my price sensitivity, that I prefer walkable locations over resort-style places, that I will pay more for a good breakfast but not for a gym. One booking. Ninety seconds. And already a richer profile of my preferences than any hotel loyalty programme has built in a decade.

What agentic commerce actually means

So far in this series, I have covered the data moat AI platforms are building, the enshittification pattern from social media, and why AI lock-in captures your knowledge graph rather than your social graph. But agentic commerce takes the stakes to a different level.

The idea is straightforward: instead of you browsing, comparing, and buying, an AI agent does it. Books travel, orders groceries, finds insurance, manages subscriptions. For anyone who has lost an evening to comparison shopping, this is a real improvement. And it probably will be a net positive for most people most of the time.

I am not being cynical. AI agents that negotiate better rates on your utilities or find flight options in seconds are solving real problems. The technology is impressive and the convenience is genuine.

But think about the data profile that creates.

From conversations to economic identity

An AI agent acting on your behalf learns what you buy, how much you spend, what trade-offs you accept, what you are willing to pay more for, and what makes you hesitate. Over time it builds a picture of your financial patterns, your health priorities based on what you order, your lifestyle based on where you travel. That goes well beyond conversation history.

Today, fragments of this data sit across your bank, your supermarket loyalty card, your airline account, your streaming services. No single entity has the full picture. Agentic commerce changes that. One AI agent managing multiple aspects of your purchasing life holds a more complete profile of your economic behaviour than any platform has ever had.

The data moat is no longer just about how you think. It is about how you spend, what you value, and what you will tolerate. That is a profile worth billions.

The incentive question

There is a subtlety here that most coverage misses. These agents will almost certainly have commercial relationships with merchants and service providers. That is not automatically a problem. Affiliate models can work well when they are transparent. Recommendations based on actual relevance are valuable for everyone.

But if the incentive structures are hidden, the agent ends up optimizing for the platform's margin rather than your best outcome. Not because anyone set out to deceive, but because that is where the economics naturally pull. We have seen this play out in insurance comparison sites, hotel booking platforms, financial product aggregators. The agent framing is new. The incentive problem is very old.

Google, Amazon, Apple, OpenAI are all positioning to become the agent layer between consumers and commerce. Some will build trustworthy products. But the concentration of that much personal and financial data in platforms that also control the purchasing funnel deserves more scrutiny than it is getting.

Why this connects to everything else

This is where the portability conversation from the earlier parts gets urgent. When AI lock-in was about chat history, the stakes were convenience. When it extends to purchasing behaviour and financial patterns, the stakes are autonomy.

It is not just about switching AI providers anymore. It is about making sure your spending patterns and decision-making profile do not get permanently locked into one ecosystem with no exit.

The opportunity is real. Agentic commerce could save people enormous amounts of time and money. But so could social media have remained a useful connective tool if we had built in safeguards early enough. The lesson from every part of this series is the same: the time to shape the terms is while the technology is still being designed. Next week, the final part: what we can actually do about all of this.

I spent an afternoon last month exporting my conversation history from one AI platform and trying to load it into another. The export worked. It gave me a JSON file with thousands of messages. The import did not work at all, because the other platform has no import function, and even if it did, raw conversation logs are not the same as the contextual understanding built from those conversations. I had the data. I did not have the knowledge graph.

That experience crystallised something I had been circling around for four weeks of writing this series. The problem is not that platforms refuse to give you your data. It is that the most valuable thing, the accumulated understanding of how you work and think, is not data in any format you can move.

Google just made this look solved. It is not.

Google recently launched an import feature for Gemini that lets you bring in your memories and chat history from other AI apps. You copy a prompt into your current AI, it generates a summary of your preferences, you paste that into Gemini, and it picks up your context. You can also upload a ZIP file of your full conversation history from ChatGPT or Claude and continue where you left off.

On the surface, that sounds like exactly what I have been asking for in this series. Portability. The ability to switch without starting over.

But look at what is actually happening. Google built an import tool. Not an export tool. The data flows in one direction: toward Google. Once your context is inside Gemini, it gets combined with your Gmail, your Google Photos, your Search history, and whatever else you have given Google access to. That is not portability. That is acquisition. Google is not solving the switching problem for users. It is solving the switching problem for Google.

This is the pattern we should recognise by now. The platform that makes it easiest to arrive is not necessarily the one that makes it easiest to leave.

What we actually need

The solution I keep coming back to is not complicated in concept. We need an AI-agnostic layer where your personal data, preferences, and interaction history live. A place you own and control. A system of record that AI platforms can read from and write to, with your permission, but that is not tied to any single provider.

Your personal knowledge graph should be infrastructure, not a feature of whichever AI product you happen to use today.

Anuj Ahooja wrote a piece recently called "The Everything Account" that frames this well. His argument is that our accounts are not really our accounts. They are accounts owned by Google, Meta, OpenAI, whoever runs the platform. The data we create is tied directly to the app, and the companies hoard it because they know it is what gives them power over us. His proposal: separate the data from the app entirely. Let your account live on its own, grant access to whichever services you choose, and revoke that access when a platform stops serving you. The apps orbit your data, not the other way around.

That model resonates with everything I have been writing in this series. But I would push it one step further.

The data should flow both ways

Right now, the relationship between you and an AI platform is extractive. You give it your context, it builds a profile, and that profile stays inside the platform. You never see what it has learned about you. You never get the enriched version back.

What if the deal were different? What if every platform you interact with, whether it is an AI assistant, a social network, a commerce agent, or a search engine, was required to write its learnings back into your personal data store? Not just let you export raw logs, but return the enriched profile. The insights, the preference models, the behavioural patterns. The things the platform learned about you that you never explicitly told it.

That would change the power dynamic entirely. You would not just own your data. You would own what your data taught the machines. And you could take those learnings to any other platform, or use them yourself to understand your own patterns better than any single AI does.

The goal is not just portability. It is reciprocity. Every platform that learns from you should be required to teach you back.

People are already building toward this

The Data Transfer Initiative recently published principles for portability of personal data in AI and collaborated with Inflection AI on a data model for transferring conversation histories. Their affiliate Fabric built an open-source tool called "context-use" that converts ChatGPT archives into portable context for other agents. Early work, but pointed in the right direction.

Standards like the Model Context Protocol (MCP) are creating a common interface between AI systems and external data sources. Think of MCP as a universal connector: one standard for accessing databases, files, and APIs instead of bespoke integrations per platform. That kind of interoperability is foundational if we want data that actually moves with us.

On the regulatory side, the EU is further ahead than most realise. The Digital Markets Act is putting pressure on major platforms. The EU Data Act, effective since late 2025, already grants rights to access and port data from connected devices and explicitly prohibits vendor lock-in. The infrastructure for enforcement exists. What is missing is the tooling and market demand to make portability real in practice, not just in law.

What you can do right now

The window is still open

AI personalisation is early enough that the lock-in has not fully set in. Most people are still experimenting, splitting usage across tools, not yet deeply committed to any single platform's memory of them.

But that is changing fast. Memory features are improving. Agents are taking on more tasks. Personalisation is deepening. Google is already building import tools to pull you in. The moat gets dug a little deeper with every conversation.

The social media era taught us what happens when platforms accumulate personal data without portability or user control. We watched it happen, named it, wrote books about it, and then walked straight into the same pattern with the next technology that came along. Your AI profile is becoming one of the most valuable digital assets you own. The question of who controls it is not a technical curiosity. It is personal. I would rather own mine, enriched profile and all.

A colleague asked me last week whether he should consolidate all his AI usage onto one platform or keep splitting it across three. My immediate reaction was: consolidate, obviously. One platform with full context will always outperform three with fragments. Then I caught myself. That advice is exactly how the moat gets built. It is good advice for productivity and terrible advice for independence.

That tension is the core of this piece. The thing that makes AI useful is the same thing that makes it hard to leave.

Social graph versus knowledge graph

In parts 1 and 2, I traced how the data moat forms and why the enshittification pattern from social media is already appearing in AI. But there is a reason the AI version of this deserves its own conversation. The lock-in works differently, and the difference matters.

With social media, the lock-in was about your network. Your friends were on Facebook, so you stayed. Your professional contacts were on LinkedIn, so you kept your profile updated. Moving was inconvenient, but the thing holding you in place was external. Other people, not you.

With AI, the lock-in is about you. Your preferences, your working style, your domain expertise as the system understands it. The context it has built across hundreds or thousands of interactions. And it lives inside platforms with no standard way to extract it.

A social graph is recoverable. You can re-add friends on a new platform, export a contact list. Tedious, but possible. The relationships exist independently of the platform.

A personal AI knowledge graph is not like that. It is a model of how you work, how you think, what you need. Shaped by every question, every correction, every preference you revealed without realizing it. That model does not export as a CSV. It does not reconstruct from memory. It is emergent, built through interaction, and locked inside the platform that created it.

The invisible accumulation

The tricky part is that nobody decides on day one to hand their cognitive profile to a platform. It happens conversation by conversation, correction by correction. Each interaction feels harmless. But the cumulative effect is a detailed model of your professional life that you did not consciously choose to create.

With cloud, you know what data you have stored. With AI, the most valuable thing is the pattern recognition the system has developed about you across all your conversations. That is much harder to define, let alone transfer.

Compare that to other forms of lock-in. With cloud providers, you can at least inventory your data and plan a migration. With productivity software, your files are discrete objects you can export. With AI, the valuable asset is not any individual conversation. It is the understanding the system has developed about you across all of them. Try putting that in a zip file.

What this means for how we adopt AI

None of this means we should avoid AI tools. The productivity gains are real. I get more done in a day with AI than I used to get done in three. But it does mean we should be deliberate about how we adopt them.

Every time you invest deep context in a single AI platform, you are betting that the platform will keep serving your interests, that pricing stays acceptable, that quality holds, and that the terms around your data will not change on you. That is a lot of trust for a single provider. Especially one that has not yet figured out how to be profitable.

The alternative is to start thinking about your personal AI context as something that should exist independently of any platform. Something portable. Something you own.

Easier said than done today. But not impossible. And before we get to the solutions in part 5, there is one more dimension that raises the stakes even further: what happens when AI agents start spending your money. That is next week.

Last week I wrote about the data moat that AI platforms are building around their users. Every conversation deepens your context inside a single platform, and that context gets harder to walk away from. A few people messaged me to say they had not thought about it that way. Which is exactly the problem. We have watched this pattern play out three or four times in the past fifteen years, and we keep not thinking about it until the door is already closed.

This is the part where I trace the pattern.

The enshittification playbook

Cory Doctorow coined the term "enshittification" and then wrote an entire book about it last year. The mechanics are consistent across platforms: be good to users first, squeeze users to serve business customers second, squeeze everyone to serve shareholders third.

Facebook started as a genuinely useful way to stay connected with friends. Then the algorithm shifted toward engagement optimization, the feed filled with sponsored content, and organic reach for pages dropped to near zero. By the time the experience had visibly degraded, your social graph was too embedded to leave. Google Search went from clean, relevant results to a page where the first three or four items are ads and the rest are SEO-optimized content farms. Amazon started as a great place to buy things, then gradually shifted search results toward sponsored products and squeezed sellers with rising fees. Cloud providers offered transparent, affordable pricing, then introduced complex fee structures and egress charges that made leaving expensive.

The cycle always starts with generosity and ends with extraction, once the switching costs are high enough.

The AI version is already starting

We are watching the same playbook in AI, on a faster timeline.

The platforms are still in their generous phase. Free tiers, subsidized access, impressive capabilities shipped at speed. But running large language models is expensive. OpenAI, Anthropic, Google, and the rest are burning capital at rates that are not sustainable. The generosity has a shelf life.

The early signs are already showing. Perplexity is experimenting with ads in its search results. OpenAI restructured its pricing, moving features like model selection behind the $200-a-month Pro tier. Features that were free a year ago are now gated behind higher price points. This is not corporate greed. It is economics. But the direction is clear.

The more context a platform holds about you, the harder it is to leave when the experience starts to degrade. That is not an accident. It is the business model.

And here is the connection to the data moat from part 1. Attract users with a great experience, accumulate data that makes switching painful, then gradually shift value extraction toward the platform and its investors. The personal context your AI has built about you is the switching cost. It is the thing that keeps you from leaving when the ads arrive, when the pricing changes, when the quality of the free tier quietly declines.

Why AI enshittification could be harder to spot

With social media, at least the degradation was visible. You could see the ads multiplying in your feed. You could feel the algorithmic manipulation. You knew it was getting worse, even if leaving was inconvenient.

With AI, the degradation might be much harder to detect. If an assistant starts subtly favouring certain products in its recommendations, or adjusting its outputs to align with commercial partnerships, would you notice? If response quality on the free tier gradually declines to push you toward a paid plan, how would you even measure that? The conversational interface makes it far easier to embed commercial influence without clear labels. There is no "Sponsored" tag on a paragraph of advice.

The social media era gave us a vocabulary for these problems. Enshittification, dark patterns, algorithmic manipulation. We know what to look for now.

The question is whether we will actually apply those lessons this time. Because right now, we are in the generous phase. And generous phases never last. Next week: why AI lock-in is not like social media lock-in at all, and why that makes it worse.

Something shifted for me about six months ago. I had been using the same AI assistant daily for strategy work, automation specs, debugging, team planning. And one afternoon I opened a competitor's tool to test it. Within two minutes I closed the tab. Not because it was worse. Because it did not know me. It did not know my projects, my stack, my communication style, the shorthand I had built up over months. Starting from zero felt unbearable.

That was the moment I realized the moat had already formed. Not around the product. Around me.

How the lock-in builds

Every conversation you have with an AI assistant makes it a bit smarter about you. Your preferences, your writing style, how you approach problems, the projects you work on. Over time, that accumulated context becomes the thing that makes the tool useful. Not the model itself, not the interface. The fact that it already understands your world.

Sam Altman said it plainly late last year: future versions of ChatGPT will have "perfect, infinite memory." Not just facts you share, but subtle preferences you never explicitly state. Every document, every conversation, every correction. That is not a product feature announcement. That is a lock-in strategy with a release date.

The mechanics are simple. Each interaction adds a thin layer of context. No single conversation matters much. But after hundreds of them, you have built something that is genuinely hard to replicate elsewhere. The AI knows your role, your domain, your communication patterns, your recurring problems. Switching means losing all of that and re-explaining yourself from scratch.

The friction is the moat

I use AI daily for strategy documents, automation pipelines, debugging, thinking through team structures. The context my assistant has built about my work makes it dramatically more useful than it was on day one. If I had to switch tomorrow, I would not just lose a tool. I would lose months of accumulated understanding.

The lock-in is not the product. It is the profile the product has built about you.

Most people are not thinking about this yet. AI tools are still new enough that the context has not had time to build to the point where leaving hurts. But for those of us using these tools daily, the dependency is already real. And it grows with every conversation.

Who owns the understanding?

The question I keep coming back to: who owns the context these platforms have built about me? I did not consciously decide to create a detailed cognitive profile inside a third-party platform. It happened conversation by conversation, correction by correction. And now it is locked inside a system I do not control, with no standard way to extract it or take it somewhere else.

That is the data moat. It is not built with code or patents. It is built with your accumulated self, held inside someone else's walls.

Right now, the answer to "who owns your AI profile" is: not you. That should bother us more than it does. Next week, I will look at why we should have seen this coming, because we have watched the same pattern play out before.

I noticed something about myself a few weeks ago. I was mid-conversation with an AI assistant, deep into a workflow I have refined over months, and I caught myself thinking: I could never switch away from this. Not because the tool is perfect. Because it knows too much about me. My projects, my preferences, the way I structure arguments, the shorthand I use for things only I care about. Rebuilding that context somewhere else would take weeks. Maybe longer.

That thought stopped me. Because I have heard it before. I heard it about Facebook in 2012. About Gmail in 2015. About AWS in 2019. Every time, the same feeling: this is too useful, too embedded, too much effort to leave. And every time, the platform eventually changed the deal.

The goldfish problem

We have the memory of a goldfish when it comes to technology platforms. Every cycle is the same. Something new arrives, it is useful, it feels like it is on our side. We adopt it fast, pour our data and routines into it, and then the terms shift. The experience gets worse. The platform starts serving itself more than us. By the time we notice, leaving is too expensive.

Facebook went from connecting friends to optimizing for ad engagement. Google Search went from the best tool on the internet to a page of ads with some results underneath. Cory Doctorow literally wrote the book on this last year. Attract users, accumulate their data, make leaving painful, extract value. Same pattern whether it is a social network, a cloud provider, or a ride-sharing app.

And now here we are with AI. Probably the most personal technology most of us have ever used. And we are not stopping to ask basic questions. Who owns the context these platforms are building about me? Can I take it with me if I leave? What happens when the pricing changes?

This is not a sceptic's take

I want to be clear: I use AI more than most people I know, and I have no plans to stop. I am not calling for regulation that slows things down. What I am calling for is memory. The kind that says: we have been here before, and last time we did not think about portability or data ownership until it was too late.

Sam Altman said it plainly late last year: future versions of ChatGPT will have "perfect, infinite memory." Every document, every conversation, every correction. That is a lock-in strategy dressed up as a product feature. The deeper that profile gets, the harder it is to leave. That is not a conspiracy. It is a business model. We should probably recognize it by now.

You can be impressed by the technology and still think clearly about what you are signing up for. Those two things are not in conflict.

What this series covers

Over the next five weeks, I am going to write about the data moat that AI platforms are building around their users. Not because I think AI is bad. Because I think we can do better than we did last time.

Part 1 looks at how the lock-in forms in practice. Part 2 traces the enshittification pattern from social media. Part 3 explains why AI lock-in is different from anything we have seen before. Part 4 covers how agentic commerce raises the stakes further. Part 5 is about what is actually within our control right now.

We are not goldfish. We can remember what happened last time. The question is whether we will, before the same patterns take hold in a technology that knows us better than any platform ever has.

Something shifted for me about six months ago. I was watching one of my team's analysts spend the better part of a week pulling performance data, formatting slides, and writing commentary that — frankly — said roughly the same thing every month. Not because she wasn't sharp. She is. But the process was designed for humans to do robot work, and it showed.

That was the week I started building our first agent pipeline. And it changed how I think about everything we do.

We've been using AI like a calculator

Most owned media teams I talk to are using AI the way we used spreadsheets in 2005 — as a slightly faster way to do the thing we were already doing. Generate a meta description. Suggest some keywords. Draft a paragraph we'll rewrite anyway. It's useful, sure. But it's fundamentally passive. You poke it, it responds.

Agentic AI is different. You don't give it a task — you give it a goal. "Improve organic visibility for our butter category pages." And then it figures out the steps: audit what's there, find the gaps, draft content, monitor what happens, adjust. Not once, but continuously.

I've started describing it to stakeholders as "a junior team member with infinite patience and perfect memory." That framing lands every time.

Three things this changes right now

The boring stuff disappears first. Monthly reporting, content audits, competitive monitoring — this is where agents earn their keep immediately. That reporting pipeline I mentioned? Seven agents, talking to each other, turning raw Excel exports into branded PowerPoint decks with written commentary. What used to take a week of analyst time now takes minutes. And honestly, the commentary is better than what we were producing manually, because the agents don't get tired on slide 47.

You have to start thinking about AI as an audience. This one's sneaking up on people. If LLMs are reading your content to answer user queries — and they are — then you're not just optimising for Google anymore. You're optimising for comprehension by machines. Schema markup, semantic structure, clean content hierarchies... these aren't nice-to-haves. They're how you stay visible in a world where the answer box replaces the click.

Your team changes shape, not size. I don't think agentic AI means smaller teams. I think it means differently skilled teams. The people who can define sharp objectives, evaluate whether an output is actually good, and course-correct when something drifts — they become the bottleneck. Execution gets cheaper. Judgment gets more expensive.

How I'd start if I were starting today

Honestly, the biggest mistake I see is teams trying to go straight to "AI-generated content at scale." That's the deep end, and the water's murky.

Start boring. Pick a process that's repetitive, low-risk, and easy to validate — reporting is perfect. Build an agent that does it. Learn how agents fail (they will). Learn what good guardrails look like.

Then work outward: content operations, localisation, personalisation. Each step teaches you something about how to define objectives that agents can actually execute against. By the time you get to the ambitious stuff, you'll have the muscle memory.

The teams that move first on this won't just be more efficient. They'll be operating differently — thinking in systems instead of tasks, defining outcomes instead of writing briefs. The constraint stops being capacity and starts being imagination.

And that's a much better problem to have.

For the past two decades, owned media strategy has rested on two pillars: content and search. Create good content, make sure Google can find it. That formula built careers — mine included.

But something fundamental has changed. People are getting answers without clicking. LLMs are synthesising content from across the web and presenting it directly. ChatGPT, Perplexity, Copilot — they're not sending users to your site. They're reading your site and telling users what it says.

If your brand isn't visible to these systems, you're disappearing from a growing share of the information landscape. And most teams haven't even started to grapple with this.

The visibility problem nobody's measuring

Here's what keeps me up at night: we have twenty years of tooling for measuring search visibility. Rank trackers, SERP analysers, click-through-rate benchmarks. For AI visibility? Almost nothing.

Try asking Claude or ChatGPT about your brand's products. What comes back? Is it accurate? Is it current? Is it your competitor's messaging? Most companies have never checked. They're optimising for a channel they can measure while ignoring one they can't.

The brands that win in the next five years will be the ones that treat AI visibility with the same rigour they currently apply to SEO.

What makes content AI-visible

AI systems don't process content the same way search engines do. They don't care about keyword density or backlink profiles. They care about comprehensibility — can they extract clean, structured, unambiguous meaning from your content?

This means a few things become critically important:

Semantic HTML matters again. Proper heading hierarchies, meaningful section structure, descriptive alt text. The stuff your accessibility team has been asking for — turns out it also makes your content legible to LLMs.

Schema markup is no longer optional. JSON-LD structured data tells AI systems exactly what your content is about. Product schema, FAQ schema, article schema — each one gives machines a shortcut to understanding your pages without having to infer meaning from prose.

Content needs to be self-contained. AI systems often process pages in isolation. If your product page only makes sense in the context of a category page and a navigation menu, a machine reading just that page will get a fractured picture.

The practical first steps

I've been working on this with my team, and here's where we started:

1. Audit your AI presence. Ask the major LLMs about your brand, your products, your category. Document what comes back. You'll be surprised — and probably not in a good way
2. Fix your structured data. Run your key pages through schema validators. Fill the gaps. This is the lowest-effort, highest-impact change you can make
3. Simplify your content architecture. Every page should answer a clear question, completely, without requiring the reader to navigate elsewhere for context
4. Monitor over time. AI responses change as models are updated. What's accurate today might not be next month. Build a cadence for checking

This isn't about replacing SEO

I want to be clear: traditional search isn't going away. SEO still matters. But it's no longer sufficient. Owned media strategy now has three pillars: content, search, and AI visibility. Ignoring the third one is like optimising for desktop in 2015 and pretending mobile would sort itself out.

The window for getting ahead of this is narrow. Most competitors haven't started. The teams that build AI visibility into their content operations now will have a compounding advantage that's hard to reverse-engineer later.

And that's the kind of strategic asymmetry I live for.

Every month, our performance team produces a set of reports that track how key brands are performing across digital channels. It's important work. It informs decisions. And until recently, it was also a phenomenal waste of skilled people's time.

The process looked like this: download data exports from three platforms, copy numbers into a master spreadsheet, generate charts, paste those charts into a PowerPoint template, write commentary for each slide, format everything to brand guidelines, then send it out. Rinse and repeat for each market. Each brand. Every month.

I looked at this and thought: every single one of these steps is rule-based. There's judgment involved, yes — but it's bounded judgment. The kind an AI system can learn if you define the guardrails properly.

Building the pipeline

We started with a simple question: what if we broke this into discrete agents, each responsible for one step, and let them hand off to each other?

The result is a 7-agent pipeline:

1. Data Ingester — reads Excel exports, normalises column names, validates data integrity
2. Metric Calculator — computes period-over-period changes, flags anomalies, generates summary statistics
3. Chart Generator — produces branded charts from the computed data using Python's matplotlib
4. Narrative Writer — drafts slide commentary based on the metrics, using templates and conditional logic for different performance scenarios
5. Slide Assembler — builds the PowerPoint deck, placing charts, text, and branding elements according to the template
6. Quality Checker — validates the output against a checklist (correct date ranges, all brands present, no placeholder text)
7. Distribution Agent — saves the final deck and triggers notifications

Each agent is relatively simple on its own. The intelligence is in the orchestration — how they pass data, how errors cascade, and where human checkpoints sit.

What surprised us

The quality bar was higher than expected. The narrative agent's commentary was consistently better than what we'd been writing manually. Not because it was smarter — because it was consistent. It never forgot to mention a key metric. It never got lazy on slide 30. It applied the same analytical framework to every brand, every time.

Error handling was the real engineering work. Getting the happy path working took about 40% of the effort. The other 60% was handling malformed data, missing columns, edge cases in the chart layout, and the dozen ways a PowerPoint template can be subtly broken.

The hardest part was defining "done." When a human makes a slide deck, they just... know when it's finished. Teaching an agent pipeline what "finished and correct" looks like required us to be far more explicit about our quality criteria than we'd ever been. That turned out to be valuable in itself.

Automating a process forces you to understand it. We found three redundant steps we'd been doing for years simply because nobody had questioned the workflow.

The business case

The numbers are straightforward. The manual process took roughly 40 hours per month across the team. The pipeline runs in under 10 minutes. Even accounting for the development time and ongoing maintenance, we broke even in the second month.

But the real value isn't time savings. It's what the team does with those 40 hours now. They're doing actual analysis — investigating trends, building strategic recommendations, having conversations with brand managers that go beyond "here's what happened last month" into "here's what we should do about it."

Lessons for anyone starting this

• Start with a process you understand deeply. You can't automate what you can't specify
• Build agents that are narrow and testable. One agent, one job. If an agent is doing three things, it's three agents
• Put human checkpoints at trust boundaries. Our quality checker flags issues, but a human reviews the final deck before distribution. That's intentional
• Version everything. Templates change. Data formats change. Your agents need to handle yesterday's version and today's

This project convinced me that the future of operational work isn't AI replacing people — it's AI handling the mechanical parts so people can focus on the parts that actually require thinking. The 7-agent pipeline doesn't eliminate the need for smart analysts. It gives them permission to actually be analysts.

I have a confession: I've been building websites for twenty years, and this blog is the most fun I've had in a long time. Not because it's complex — it's the opposite. It's a handful of HTML files, one CSS stylesheet, one JavaScript file, and a folder full of Markdown. No React. No Next.js. No build step. No CMS login screen.

And it feels great.

Why I went this route

The short answer is that I was tired of fighting tooling. Every blog platform I've used eventually becomes a maintenance burden. The CMS needs updating. The theme breaks after an upgrade. The plugin ecosystem shifts. You spend more time keeping the lights on than actually writing.

I wanted something I could understand completely, end to end. Something where adding a new post means creating a .md file and updating a JSON array. Something that loads fast, costs nothing to host, and doesn't phone home to anyone.

The best architecture is the one you never have to think about. For a personal blog, that means static files.

How it actually works

The engine is about 120 lines of JavaScript in a single file called blog.js. It does three things:

1. Fetches post metadata from an index.json file — titles, dates, tags, excerpts, filenames
2. Fetches and parses Markdown files on demand, converting them to HTML client-side
3. Provides helper functions for rendering post cards, post rows, and formatted dates

The Markdown parser handles headings, bold, italic, links, images, code blocks, blockquotes, lists, and horizontal rules. It's not going to win any awards for edge-case handling, but for blog posts? It's more than enough.

// The entire post-loading flow
const posts = await Blog.getPosts();
const post = posts.find(p => p.slug === slug);
const html = await Blog.getPostContent(post.filename);
document.getElementById('article').innerHTML = html;

Four lines. That's the whole render pipeline.

The design: terminal aesthetic

I wanted the site to feel like my space — not a template. The terminal window chrome (those red, yellow, green dots) wraps content areas and gives everything a dev-native feel. Martian Mono as the sole typeface keeps things consistent and a little unusual.

The blinking eyes in the background are a carry-over from my original site. They're pure SVG with CSS animations — no JavaScript needed. Subtle enough that most people don't notice them for a few seconds. That delay is the whole point.

What I'd do differently

Honestly? Not much. If I were building something with fifty contributors and a content calendar, I'd reach for a headless CMS. But for one person writing a few posts a month, this is the right amount of architecture.

The one thing I might add eventually is client-side search. A small index that lets you filter by keyword without hitting a server. But even that feels like premature optimisation for six posts.

Sometimes the most modern thing you can do is use less technology. This blog is my proof of that. Static files, zero dependencies, and the browser does the rest.

We just renamed the team, I am a part of.. We went from "Tech, Owned & Data" to "Digital Experience." On paper, it's just words. In practice, it changed nearly everything about how we operate, what we're asked to do, and how seriously the wider business takes our work.

I want to talk about why naming matters so much for internal teams, and what I learned from getting it right after years of getting it wrong.

The problem with the old name

"Tech, Owned & Data" was accurate. We did handle technology, owned channels, and data. But accuracy isn't the point of a team name — positioning is.

Here's what stakeholders heard when I said "Tech, Owned & Data":

• "Tech" → these are the IT people, call them when something breaks
• "Owned" → they manage the website, probably some social media
• "Data" → they pull reports when I need numbers for a presentation

None of that was wrong, exactly. But none of it captured what we actually did, which was shape the entire digital experience across markets, build the content and AI strategy, and drive business outcomes through owned channels. The name created a ceiling for our perceived scope.

A team name isn't a description. It's a pitch. Every time someone reads it on an org chart, they're making assumptions about what you can and should be involved in.

Why "Digital Experience" works

"Digital Experience" does three things the old name didn't:

It centres the customer. "Experience" is inherently outward-facing. It signals that we care about what the end user encounters, not just the machinery behind it. This shifted how product teams thought about involving us — from "can you build this page" to "how should this experience work."

It's broad enough to be ambitious. Experience covers content, technology, search, AI, analytics, and the connections between them. Nobody questions why a Digital Experience team is involved in an AI visibility project or a content strategy workshop. With "Tech, Owned & Data," I spent half my time justifying why we had opinions about content.

It's recognisable outside the company. Try explaining "Tech, Owned & Data" to a prospective hire. Now try explaining "Digital Experience." One requires a five-minute backstory. The other is instantly understood.

The ripple effects

What surprised me was how much changed without us pushing for it. Within three months of the rename:

• We were invited to strategic planning meetings we'd never been part of
• Two cross-functional projects listed us as stakeholders by default
• Recruitment became noticeably easier — candidates understood the role from the title alone
• Team morale improved because people could finally explain to their families what they did

That last one sounds trivial, but it isn't. Pride in your team's identity matters. When your mum asks what you do at work and you can say "I work in Digital Experience" instead of "I'm in Tech, Owned & Data... it's complicated," that changes how you feel about showing up on Monday.

How to know it's time

If any of these sound familiar, it might be time:

• You spend more than 10% of stakeholder conversations explaining what your team does
• People route requests to you that should go elsewhere (or miss routing requests that should come to you)
• Your team's name doesn't appear in strategic planning documents, even when your work directly contributes
• New hires take weeks to understand the team's scope and positioning

What we would do differently

We might have waited too long. We treated the name as cosmetic when it was structural. If we could go back, we would have renamed earlier and be even more deliberate about the launch.

Names are levers. In an organisation where attention is scarce and assumptions are formed in seconds, the words on the org chart matter more than most leaders admit. If your team name is holding you back, change it. It's one of the highest-leverage, lowest-cost moves you can make.

A few months ago, our SEO team flagged something strange: Dutch users searching for a well-known butter brand were landing on English-language pages. Not occasionally — consistently. The hreflang implementation on one of our key product domains was broken, and it had been broken long enough that we were losing meaningful traffic in the Netherlands.

This is the story of how we diagnosed it, what was actually wrong, and what I learned about the surprising fragility of hreflang in multi-market setups.

What hreflang is supposed to do

For the uninitiated: hreflang is an HTML attribute (or HTTP header, or sitemap annotation) that tells search engines which language and regional version of a page to show to which users. If you have example.com/en/butter and example.com/nl/boter, hreflang tags tell Google that Dutch users should see the second one.

Simple in theory. Diabolically tricky in practice.

<!-- On the English page -->
<link rel="alternate" hreflang="en" href="https://example.com/en/butter" />
<link rel="alternate" hreflang="nl" href="https://example.com/nl/boter" />

<!-- On the Dutch page -->
<link rel="alternate" hreflang="nl" href="https://example.com/nl/boter" />
<link rel="alternate" hreflang="en" href="https://example.com/en/butter" />

The key rule: hreflang must be reciprocal. If Page A says "my Dutch version is Page B," then Page B must also say "my English version is Page A." If this bidirectional confirmation is missing, Google ignores the whole thing.

Finding the break

Our first instinct was to check the hreflang tags directly. They looked fine — both pages referenced each other correctly. So why wasn't it working?

Three hours of debugging later, we found it. The issue was in the canonical tags.

The Dutch page had a canonical pointing to a slightly different URL — one with a trailing slash inconsistency:

<!-- The hreflang said -->
<link rel="alternate" hreflang="nl" href="https://example.com/nl/boter" />

<!-- But the canonical on that page said -->
<link rel="canonical" href="https://example.com/nl/boter/" />

One trailing slash. That's it. Google treats those as different URLs, so the reciprocal relationship broke silently. No error in Search Console. No warning. Just... ignored.

Hreflang debugging is 90% URL normalisation issues. The actual tag logic is rarely wrong. It's the URLs that lie.

The fix and the fallout

The fix itself was simple: normalise all canonical URLs and hreflang references to use the same format (no trailing slash, in our case). We deployed it, resubmitted the sitemaps, and within two weeks traffic patterns normalised.

But the real lesson was about our process. Here's what we changed:

Automated validation

We built a script that crawls our hreflang implementation nightly and checks for:

• Reciprocal link completeness (every hreflang has a matching return link)
• Canonical/hreflang URL consistency
• HTTP status codes on all referenced URLs
• Self-referencing hreflang tags (required but often forgotten)

def validate_hreflang_pair(page_a, page_b):
    """Check that two pages correctly reference each other."""
    a_refs = get_hreflang_refs(page_a)
    b_refs = get_hreflang_refs(page_b)
    a_canonical = get_canonical(page_a)
    b_canonical = get_canonical(page_b)

    issues = []
    if b_canonical not in a_refs.values():
        issues.append(f"{page_a} references {page_b} but URLs don't match canonical")
    if a_canonical not in b_refs.values():
        issues.append(f"{page_b} doesn't reference back to {page_a}")
    return issues

Deploy-time checks

Any change to URL structure or page templates now triggers hreflang validation as part of the CI pipeline. If the reciprocal links break, the deploy fails. We don't rely on humans catching this anymore.

What makes hreflang so fragile

The core problem is that hreflang creates a distributed contract between pages. Each page makes promises about other pages, and those promises all need to be consistent. In a system with hundreds of pages across dozens of markets, that's thousands of bidirectional relationships, each one capable of silently breaking.

Add to this that:

• Different teams often manage different market sites
• CMS platforms don't always expose hreflang configuration cleanly
• URL structures drift over time as sites evolve
• CDN or middleware layers can transform URLs in ways that create inconsistencies

The result is a system that's almost designed to break in ways that are hard to detect.

The takeaway

If you're running a multi-market site, hreflang isn't a "set it and forget it" implementation. It's infrastructure — and like all infrastructure, it needs monitoring, testing, and the occasional 3am debugging session when Dutch users complain about seeing English butter.

The trailing slash thing still annoys me. One character, silent failure, weeks of lost traffic. If there's a better metaphor for the fragility of web infrastructure, I haven't found it.