_AI has made experimentation easier. It has also made an old distinction harder to see._ An AI lab, a research programme and a hospital testing a language model can all be described as “innovation”. The word tells us very little about what is happening. Is someone trying to produce knowledge that did not exist before? Is an organisation changing the way it works? Or is it still exploring whether either is possible? The OECD uses separate frameworks for research and development and for innovation. The distinction is more useful than it may sound. R&D is defined by the nature of the investigation. Innovation is defined by a significant change that has been introduced or put into use. ## Where is the uncertainty? Imagine an engineer working on an early steam locomotive. A larger boiler might produce more power but make the locomotive too heavy. Higher pressure might create other problems. The engineer has an idea, but does not know whether it will work. He builds prototypes, measures the results and changes the design. The work is organised to resolve a technical uncertainty and produce knowledge that others could potentially use. Now imagine a railway company buying locomotives, laying track, introducing timetables and changing how passengers and goods move. It may be transforming transport without discovering anything new about steam propulsion. Its achievement lies in putting the technology to work. The Frascati Manual gives R&D five criteria: the work must be novel, creative, uncertain, systematic, and transferable or reproducible. A project can be difficult, costly and full of risk without meeting those criteria. Installing a technology in a complicated organisation may require many experiments, but difficulty alone does not turn implementation into research. That does not make the implementation less valuable. The Oslo Manual allows something to count as an innovation when it differs significantly from an organisation’s previous product or process and has been introduced or brought into use. It need not be new to the world. The railway company did not have to invent the locomotive to change transport. ## What has entered use? This distinction matters again with AI. A hospital might spend months testing an existing language model for administrative work. Staff have to assess its errors, address privacy concerns and redesign a process around its limitations. If the resulting process differs significantly from what the hospital did before and is brought into use, that can be an innovation. The hospital has not necessarily conducted R&D. Another team might investigate a new method for making language models work reliably with complex clinical evidence. If it is addressing a genuine technical uncertainty through systematic work that produces transferable knowledge, some of that work may qualify as R&D. The two teams could even be part of the same organisation. There is a further distinction that gets lost when every pilot is called an innovation. Testing a promising approach can be an _innovation activity_ without yet resulting in an innovation. The Oslo Manual recognises work that is ongoing, postponed or abandoned before implementation. Equally, R&D does not stop being R&D because its results never become a successful product. The categories describe different things; neither is a prize awarded to the project that worked out best. The boundary is not always simple, particularly in software. In 2025, the OECD published additional guidance on applying its R&D criteria to software development, including machine learning projects. An AI project may contain routine development, organisational experimentation and genuine R&D. Calling the entire project one thing can conceal the work being done inside it. ## Two questions worth keeping apart When we say that a company or a country needs more innovation, we may mean that it needs to create new knowledge. We may mean that it needs to turn existing knowledge into products and practices people can use. Often it needs both, but they call for different capabilities. A laboratory can expand what we know without changing how a hospital works. A hospital can make a significant change using technology developed elsewhere. Describing the first as R&D and the second as innovation gives each achievement its due. It also lets us see more clearly where progress has stalled: in discovering what might be possible, or in making use of what we already know.

For some time now, I have been trying to connect two subjects that increasingly occupy my attention: artificial intelligence and quantum computing. There is an obvious connection. Both are developments in computing, both are moving quickly, and both may change what computers can do. But that always felt superficial to me. Put two important technologies next to each other and it is easy enough to imagine how they might eventually interact. I was looking for something more concrete. Then I came across Microsoft's Majorana 2 quantum processor. Microsoft says AI played a role in developing the materials behind its latest generation of quantum hardware. The new material stack, which replaces aluminium with lead, was designed with the assistance of agentic AI. Microsoft says the resulting qubits have mean lifetimes of around 20 seconds, more than a thousand times longer than those in Majorana 1. There it was: a real connection between AI and quantum computing. But the more I looked at it, the less interested I became in the fact that two technologies had finally met. I became interested in what the AI had been given to work with. ## Twenty years of research Microsoft has been pursuing topological quantum computing for roughly two decades. The company has spent years developing materials, fabricating devices, running experiments, measuring results and trying to understand an unusually difficult area of physics. Majorana 2 is the latest result of that research programme. Microsoft's claims are substantial and remain contested. Researchers have continued to question whether the evidence fully establishes the topological states on which the approach depends. Microsoft disputes those criticisms, and its latest hardware is now also being made available to DARPA for independent testing and evaluation. That scientific debate matters, but it is not the part of the story that caught me. What interested me was the environment in which the AI was operating. Twenty years of R&D produces much more than a stack of scientific papers. It produces measurements, experiments, simulations, device configurations, failures, laboratory notes, hypotheses, code, interpretations, abandoned approaches and decisions about what to try next. Some of that material is highly structured. Some of it is numerical. Some of it is governed very tightly by physics. But a great deal of research is also language. Scientists constantly translate between the physical world and words. They describe what they observed, what they think it means, why an experiment failed, why one explanation seems more plausible than another, which assumptions they made and which question should come next. Over twenty years, that becomes an enormous record not only of what is known, but of how knowledge was created. And that strikes me as unusually fertile material for AI. ## More than a knowledge base I often argue that AI works best when it has proper knowledge to work with. For an organisation, that might mean giving an AI system access to reliable internal documents, data and context rather than expecting a general-purpose model to somehow know how the organisation works. That is already a powerful use case. But R&D introduces something different. The material is not simply a body of established knowledge waiting to be retrieved. It is the accumulated process through which knowledge is still being made. It contains things that turned out to be correct, things that turned out to be wrong and things whose meaning may still be unclear. One experiment may only become interesting when considered alongside another experiment performed years later. A failed approach may become relevant again because a material, instrument or theory has changed. No single researcher can keep all of that in active memory. AI does not solve that automatically. Twenty years of poorly organised research is still twenty years of poorly organised research. Provenance matters. Experimental conditions matter. The distinction between a measurement, a hypothesis and an interpretation matters enormously. But if that corpus is organised properly, and if the models and reasoning systems operating on it are good enough, this seems remarkably close to an ideal environment for AI. There is a huge body of information. There are relationships to find. There is language to reason across. And crucially, there is often harder evidence against which that reasoning can be tested. The model does not need to replace the physicist. It may be valuable because it can traverse the research history differently. ## AI inside R&D That is what I now find interesting about the Majorana story. Not that Microsoft used AI. “AI” has become such a broad category that the statement alone tells us very little. The interesting part is where the AI was placed. It was placed inside a mature research programme, surrounded by years of accumulated experimental work. That is quite different from giving a chatbot a difficult scientific question and asking it for an answer. It is closer to adding a new reasoning capability to an existing research system. And once you look at it that way, the relationship between AI and R&D becomes more interesting than the relationship between AI and quantum computing. Research already produces exactly the kind of material that increasingly capable AI systems may be good at working across: large bodies of evidence, language, relationships, uncertainty and accumulated reasoning. The AI can then become part of the research loop itself. Experiments produce evidence. Researchers interpret it. AI helps connect, search or reason across it. That produces new questions or possibilities. New experiments follow. Their results return to the corpus. The knowledge base is not static. It grows because the system is using it. Microsoft increasingly describes its quantum work in terms of combining AI, high-performance computing and quantum technologies to accelerate scientific discovery. I find the more concrete version more compelling. Twenty years of research created an extraordinarily rich environment. AI has now become another way of working inside it. That was the connection between artificial intelligence and quantum computing I had been looking for. But it also changed the question. Perhaps the interesting thing is not simply what increasingly capable AI can do. It is what it can do when we give it twenty years of serious human work to think with.

The Netherlands cannot compete internationally simply by being cheaper. We have relatively high labour costs, limited natural resources and an economy that depends heavily on knowledge, productivity and international trade. Our ability to create value matters more than our ability to reduce costs. Innovation is therefore not merely an attractive ambition. It is an important part of our economic model. But developing an innovative economy requires more than funding research or encouraging entrepreneurship. Young companies need capital, skilled people and enough time to turn promising ideas into viable businesses. At a recent Techleap meeting in Amsterdam, tax adviser Bas Jorissen of Archipel Tax Advise discussed proposed changes to the Dutch taxation of employee stock options. One observation particularly caught my attention. For a young company, the capital it can retain today may be considerably more valuable than the same amount of money spent on immediate remuneration. That money could finance product development, attract customers or help the business reach its next commercial milestone. It is a straightforward observation, but it changes how we might think about employee compensation. And it helps explain why something as technical as employee stock options can have a much larger economic purpose. Bas Jorissen presenting on ESOP ## What is an ESOP? An Employee Stock Option Plan, or ESOP, gives employees the right to acquire shares in their employer at a predetermined price, subject to certain conditions. Suppose you join a startup and receive options to buy shares at a price agreed today. If the company grows substantially, those shares may eventually be worth considerably more than the price you pay. The difference represents a potential financial reward for helping build the company. But the outcome is uncertain. If the business fails or its value does not increase sufficiently, the options may be worth nothing. Unlike an ordinary cash bonus, stock options allow employees to participate in the future value of the business. They become exposed to some of the same economic uncertainty as its founders and shareholders. For a young company, this can be particularly useful. An established business may be able to attract employees with substantial salaries and bonuses. A startup often needs equally capable people but cannot afford the same immediate cash expenditure. Stock options offer another possibility. Employees accept some uncertainty in exchange for potential future rewards, while the company preserves capital for development and growth. The arrangement is not free. Existing shareholders may face dilution, and employees may never receive a meaningful return. But it provides a way to share both the risks and potential rewards of building a business. ## The Dutch tax problem There has been an important complication in the Netherlands. Employee stock options are generally treated as employment-related benefits. Under the current framework, taxation can arise when the shares acquired through exercising options become tradable, even if the employee has not actually sold them. This creates the possibility of a tax bill without corresponding cash proceeds. For someone working at a young company, that can be a considerable problem. The employee may hold something that has substantial value on paper but cannot easily turn it into money. The proposed Dutch reform, intended to take effect in 2027, aims to improve the treatment of qualifying employee stock options. Two changes are particularly important. First, qualifying employees would generally be taxed when they actually sell their shares, rather than at an earlier moment when the shares become tradable. Second, 35% of the qualifying benefit would be exempt from wage taxation. At the highest marginal rate, this would result in an effective rate of approximately 32% on the qualifying benefit. The intention is to make employee participation in young, innovative businesses more attractive and bring its treatment closer to the entrepreneurial risk associated with founding a company. The proposal is not a general tax reduction for everyone receiving stock options. It introduces eligibility requirements for companies and their option arrangements. At the time of the Techleap meeting, the reform was still subject to legislative approval. The favourable treatment would not apply to every company offering employee stock options. It is intended for qualifying startups and scale-ups, with RVO responsible for assessing whether businesses meet the relevant criteria. The proposed definition considers characteristics such as growth potential, scalability and the development or improvement of products, services, processes or technologies. This matters because the government is deliberately targeting businesses that may have considerable growth potential but limited financial resources. The tax advantage is intended to help them compete for talent. Benchmark of Dutch ESOP ## A European competitiveness question Employee ownership also exposes a broader European challenge. Stock options are internationally recognised, but their legal and tax treatment differs considerably between countries. A Dutch startup may compete for the same engineer, researcher or software developer as a company in London, Paris or Berlin. Yet the potential financial value of an employee option package can differ because of national tax rules, eligibility conditions and the timing of taxation. These differences can affect how attractive a company is to prospective employees, particularly when competing against businesses with greater financial resources. The European Union has also been exploring ways to make it easier for innovative companies to operate and grow across borders. Employee ownership belongs in that discussion, although national taxation remains a significant source of complexity. The Dutch proposal is therefore more than a domestic adjustment to wage taxation. It reflects a larger question about whether European businesses have the conditions they need to attract talent, retain capital and scale internationally. ## Innovation is also about how value is shared What interested me most about Jorissen's presentation was the connection between economic ambition and the practical mechanics of building a company. We often discuss innovation in terms of research expenditure, patents, universities, subsidies and investment funds. All are important. But even a technically promising business can struggle if it cannot attract the people it needs or must spend too much of its limited capital before reaching commercial viability. Employee stock options address a small part of that problem. They allow a company to offer employees something other than immediate cash. They also create a different relationship between work, ownership and the future value of the business. This is not without complications. Employees take financial risks, founders give up some future ownership, and the eventual distribution of rewards depends on how the business develops. But those are precisely the kinds of choices that shape an innovation economy. Tax policy influences more than government revenue. It can change when people are rewarded, how risks are distributed and whether young businesses can preserve the resources they need to grow. For a country such as the Netherlands, which depends on its ability to create value rather than compete on low costs, these details deserve attention. We cannot assume that investment in research will automatically produce innovative businesses, or that innovative businesses will automatically become productive contributors to the economy. Between an idea and a successful company lies an entire system of capital, people, incentives and institutions. Employee stock options illustrate how closely these elements are connected. They allow young companies to attract talent, preserve scarce capital and share the value they create. The proposed Dutch tax reform is therefore about more than employee compensation. It raises a broader question: how can public policy help innovative companies grow into successful businesses?

I recently came across Jev, an AI model designed specifically for classification. I haven’t tried it yet, nor do I have an immediate use case. But its technical approach and economics caught my attention. Artificial intelligence has become such a broad term that we sometimes forget how many different technologies it describes. Generative AI dominates the conversation, but recognising patterns, predicting outcomes and classifying information have been part of machine learning for decades. These technologies do not all solve the same problems, and there is no particular reason why one type of model should be the best choice for every task. That is partly why Jev, introduced by TypeSafe AI in September 2026, caught my attention. Jev is designed to classify information across different domains without requiring separate training for every application. You provide the information to evaluate and define the categories or questions you want answered. Rather than generating an explanation, the model returns structured classifications, scores or probabilities. Think of classifying incoming correspondence, identifying sensitive information in documents or determining which department should handle a request. These are small decisions, but organisations make enormous numbers of them. ## A different approach to AI TypeSafe describes Jev as a _System One model_ , optimised for rapid judgements rather than extended reasoning. According to the company, it uses parallel sampling rather than generating answers sequentially, token by token. Its training also emphasises _calibration_ : the idea that predicted probabilities should correspond reasonably well with actual outcomes. This matters because classification is rarely just about choosing a category. A useful estimate of confidence can help software decide when to act and when to refer a judgement for review. The full architecture has not been disclosed in sufficient detail for independent technical assessment. And Jev is certainly not the first model capable of classifying information without task-specific training. Nevertheless, it represents an interesting design choice: rather than using a general-purpose language model for every task, TypeSafe has built a model around the small, structured judgements that software frequently needs to make. And that brings me to what I find most interesting. ## The economics TypeSafe advertises Jev at **$0.042 per million input tokens** , without separate output-token charges. At that published price, processing a billion input tokens would cost just $42 in model usage fees. That is a remarkable number. Of course, the price of making a prediction is not the same as the cost of making a dependable decision. Integration, validation, human oversight and the consequences of incorrect classifications still matter. Nor does the published price establish how well the economics will hold up at scale. But consider what happens if classification becomes sufficiently inexpensive and accessible to incorporate almost everywhere in software. Instead of building elaborate AI applications, developers could introduce small intelligent judgements into existing processes. An incoming message could be categorised before anyone reads it. A document could be checked for sensitive information. A request could be routed based on its content rather than a rigid set of predefined rules. None of these applications is new. What might change is the threshold at which they become worthwhile. When the marginal cost of classification approaches zero, tasks that previously seemed too minor to justify automation may suddenly become candidates. 💡 ****Why Jev?**** The name refers to William Stanley Jevons, the nineteenth-century economist associated with __Jevons paradox__. He observed that improvements in the efficiency of coal use could increase rather than decrease overall consumption. Greater efficiency can lower costs enough to stimulate additional demand, potentially outweighing the original savings. ## When cheap intelligence changes what we automate If machine intelligence becomes dramatically cheaper, we may not simply spend less on the decisions we already automate. We may start making far more of them. And perhaps that is the real significance of Jev. Not a breakthrough in what classification can do, but a possible change in where it makes economic sense to use it. I haven’t tested Jev myself. Its reliability will vary between applications, and inexpensive mistakes can become expensive when repeated at scale. A low-cost model is not automatically a good model. Still, I find this direction compelling. We tend to measure AI progress by the increasingly difficult things that powerful models can accomplish. But there is another dimension to progress: making relatively simple capabilities so accessible and inexpensive that they become ordinary components of software. **What happens when intelligence becomes cheap enough to use for decisions we never previously thought worth automating?** _For the technical background and pricing, see_ TypeSafe’s introduction to Jev_._

A few weeks ago, I wrote about helping my mother-in-law buy a flight ticket in Switzerland. Her Visa payment failed, while a payment with TWINT took only a few moments. In that piece, I was interested in what the experience felt like: the complexity was still there, but my mother-in-law did not have to deal with it. Mollie’s announcement of a renewed Pay by Bank offering brought me back to payments from another direction. I have not used the new flow at checkout. Reading about it made me reconsider the diagram I had been drawing of how online payments work. A checkout can make different methods look much the same, even when the money takes a different route. ## Two routes beneath the buttons For the methods I was trying to compare, my diagram separates two broad routes. A card payment travels through a card network such as Visa or Mastercard. Apple Pay or Google Pay may change how I present the card and approve the payment, while the card network remains underneath. The other route starts with a bank account. In the Netherlands, iDEAL has long made bank-based online payment familiar. Wero is gradually taking its place as part of a wider European rollout. Mollie’s Pay by Bank also lets a customer choose a bank and approve a payment through that bank, using Open Banking access to initiate a transfer. These are broad routes, not a complete account of everything offered at checkout. The diagram helped me notice something it did not initially explain: Wero and Pay by Bank can appear similar to a customer, although they come from different parts of the payment system. ## Where I had placed the PSP I had thought of a payment service provider such as Mollie mainly as the party that helps a merchant accept methods built elsewhere. Mollie brings cards, iDEAL and other options into one checkout. In my mental picture, the PSP sat between the merchant and those established systems. Pay by Bank makes that picture less tidy. With the customer’s permission, a provider can use Open Banking access to initiate a payment from the customer’s bank account and shape the experience around it. In Mollie’s described flow, the money moves from the customer’s account to Mollie, then appears in the merchant’s balance. The transfer can be instant, although Mollie says a standard transfer may sometimes be used. This is more than adding another logo to a merchant’s list of payment methods. The PSP can assemble a bank-based checkout experience from access to banks, transfer infrastructure and its existing relationship with the merchant. ## Similar at checkout, different underneath Wero is a European payment scheme with its own rules and product. Pay by Bank is Mollie’s offering built around bank access and transfers. Both can offer an account-based route that does not require a Visa or Mastercard card transaction, but they should not be treated as interchangeable. Reach, payment timing and the arrangements for merchants and customers may differ. The pricing makes that distinction less abstract. As I write this, Mollie’s Dutch price list puts a domestic Wero payment at €0.32 and Pay by Bank at 0.45% plus €0.25. On a €50 purchase, that is €0.32 versus about €0.48. But there is an interesting wrinkle. After I shared my comparison, Mollie founder Adriaan Mol replied that **Pay by Bank will become cheaper than Wero**. He did not say whether that refers to the standard tariff, volume pricing or a pricing change still to come, so I would not read more into it yet. ## The European question Europe’s dependence on international card schemes is real. The European Central Bank has documented how heavily card payments in many European countries rely on them. Wero is an attempt to build a European payment scheme at scale. Pay by Bank shows how a PSP can use banking infrastructure to offer another account-based experience at checkout. The Swiss experience made me think about how little of a payment’s complexity the customer needs to see. Mollie’s announcement has me looking at a different side of the same question. Europe can make more than one bank-based route available. Whether those routes become useful choices will depend on how they are packaged, priced and accepted by merchants, as well as on what happens when a payment or a purchase goes wrong.

Yesterday, German AI company Aleph Alpha released Kolibri, a new German-English language and reasoning model. At first sight, this looks like another entry in an increasingly crowded field. Kolibri has 78 billion parameters in a Mixture-of-Experts architecture, with around 3.5 billion active for each token. It can reason, use tools and work with very long contexts. Its weights have been released under the Apache 2.0 licence, allowing organisations to run and modify the model themselves. I don't know whether Kolibri will turn out to be an exceptional model. It may not beat the best models from OpenAI, Google or Anthropic across every benchmark. But I increasingly think that is the wrong comparison. Because Kolibri arrived just as I have been trying to understand something else: how research and development actually turns into technological capability. And viewed through that lens, the model itself may not be the most interesting part. ## The ability to make another one I recently wrote that R&D was there all along, after realising that I had spent years looking at innovation largely through its outputs. A company. A product. A technology. A successful scale-up. But R&D doesn't only produce things. It produces capabilities. A research programme that results in a new battery chemistry has obviously produced knowledge about that particular chemistry. But it has also produced researchers, methods, equipment, experimental data and an organisation that has learned how to investigate the next problem. Kolibri can be viewed in much the same way. Aleph Alpha describes the infrastructure behind it as a **model factory** : a reusable system for building and specialising models. Training pipelines have been automated. Evaluations run continuously. Experiments can be repeated. Hardware failures can be recovered from. The company says it moved from a 30-billion-parameter precursor to Kolibri in about three months. That changes how I look at the release. The interesting capability isn't merely that Aleph Alpha has produced this particular model. Models improve and become obsolete extraordinarily quickly. It is that the people and organisations around it have accumulated knowledge, methods and infrastructure for building them. And that capability did not emerge inside one company in isolation. Aleph Alpha participated in OpenGPT-X, a publicly funded research programme involving Fraunhofer institutes and other organisations. Its current development sits within another network of investors, infrastructure providers, researchers, suppliers and customers. Already, the borders become harder to draw. ## Then there is Lidl There was another reason Kolibri caught my attention. Last year I wrote about STACKIT, the cloud provider belonging to Schwarz Group, the company behind Lidl and Kaufland. I hadn't expected to find a serious cloud infrastructure company behind a supermarket chain. But the more I looked at Schwarz, the less strange it became. This is an enormous industrial organisation. Its businesses span retail, logistics, food production, recycling and digital services across many countries. Building substantial technological capabilities of its own starts to make sense at that scale. Schwarz is also one of the major investors behind Aleph Alpha. And suddenly some familiar pieces reconnect. There is industrial capital. There is AI research and model development. There is STACKIT providing cloud infrastructure. And there is a huge collection of operating companies in which digital technology can actually be used. The connections now stretch considerably further. Earlier this year, Aleph Alpha and Canadian AI company Cohere announced plans to combine, with Schwarz Group committing €500 million in structured financing. In September, the companies signed the definitive combination agreement. Subject to regulatory approval, the combined company will operate globally as Cohere while retaining headquarters, R&D centres and leadership in both Canada and Germany. STACKIT is intended to provide infrastructure for part of that offering. This makes it difficult to tell a simple national story about Kolibri. It was developed by a company based in Germany, with roots in German and European research programmes and substantial backing from Schwarz. But the emerging system around it crosses companies, countries and institutional boundaries. That isn't a complication around the edges of the story. It may be the story. ## An LLM is only one piece There is also a temptation to look at Kolibri and ask whether European industry now has another answer to ChatGPT. I don't think that is particularly useful. A language model isn't going to run a chemical plant, optimise a power grid or solve every engineering problem inside a car factory. Industrial AI includes computer vision, optimisation, simulation, control systems, predictive models, robotics and increasingly specialised scientific models. An LLM is one component in a much larger technological environment. But it could become an important one. Industrial companies have accumulated enormous amounts of knowledge: engineering drawings, research results, maintenance histories, technical documentation, patents, contracts, software and decades of correspondence and decisions. Increasingly, language models provide a way of working with that material and connecting it to other systems. They can interpret documentation, call tools, interact with software, combine information from different sources and provide a natural-language layer over increasingly complicated technical environments. The LLM is not the industrial intelligence. It can become part of the machinery through which that intelligence is made usable. ## The knowledge is somewhere else For consumers, the calculation is fairly simple. If ChatGPT or Gemini gives the better answer, there may be little reason to care that another model can be run on infrastructure somewhere in Europe. For an industrial company, the calculation can be different. The valuable asset may not be the language model at all. It may be thirty years of engineering knowledge. That connects to another argument I have been making recently: knowledge is becoming infrastructure. AI becomes much more interesting inside an organisation when it can work with accumulated organisational knowledge rather than merely with what happened to be contained in its training data. But that knowledge does not need to live inside the LLM. In fact, I have argued almost the opposite: the company does not live in the LLM. The knowledge, models, operational systems and AI can remain distinct components. The question is how they connect. For an industrial company, that creates a different technological problem from choosing the best consumer chatbot. How do you combine increasingly powerful AI with proprietary knowledge, specialist models and operational systems while retaining enough control over the environment in which they come together? An open-weight model that can be modified and deployed on infrastructure chosen by the organisation provides one possible component of that architecture. Not the whole answer. But a piece that can be adapted, operated and, importantly, replaced. ## A pattern is appearing Kolibri also joins a collection of European developments I have been following. Switzerland's Apertus is an openly developed multilingual foundation model trained using Swiss supercomputing infrastructure. In the Netherlands, GPT-NL and investments in AI infrastructure represent a rather different attempt to preserve and develop AI capability. Aleph Alpha, Kolibri, Schwarz and STACKIT reveal yet another configuration. I don't think these add up to a coherent European AI strategy. They involve universities, governments, research institutes, commercial companies, industrial groups and international partnerships. Their motivations differ. Their technologies differ. Even the geographical boundaries become fuzzy as soon as you look closely. That matters because I have become increasingly uncomfortable with treating technological sovereignty as a question of national ownership. When I looked at Apertus, I initially found the cleanliness of the Swiss stack attractive. But I eventually arrived at a different idea: perhaps sovereignty is less about owning every component and more about **optionality**. Can you switch models? Can workloads move? Does expertise exist in more than one organisation? Can infrastructure be changed? If one supplier disappears, does the rest of the system continue to work? Kolibri reinforces that thought. Its significance is not that "Germany now has an LLM". The model itself depends on a much wider technological world, while the organisations around it are becoming more internationally connected rather than less. The more interesting question is what capabilities are accumulating inside that network. ## What does an industrial economy need? That leaves me with a question I find more useful than asking whether Europe has its own OpenAI: **What technological capabilities does an industrial economy need when AI becomes a general-purpose technology?** The answer is unlikely to be a single European foundation model. It probably includes compute, cloud infrastructure, models, research capability, specialist AI, deployment expertise and the ability to combine all of those with existing industrial knowledge. It also requires relationships between them: researchers moving between institutions, companies investing in technology, infrastructure being shared, knowledge travelling from research into industry and industrial problems finding their way back into research. Some of the initiatives I am following will fail. Some models will disappear. Commercial relationships will change. Kolibri itself may turn out to be a relatively short-lived artefact in a field that moves extraordinarily quickly. That is precisely why I find the capability underneath it more interesting. Kolibri makes part of an emerging industrial AI ecosystem visible. The model will be replaced. What the network around it learns how to do may prove much more durable.

In conversations with friends and family, I sometimes hear myself making arguments that would have surprised me ten or twenty years ago. I talk about productivity, industrial capacity, technological dependence and defence. I find myself arguing for growth, or wondering whether Europe can still make the things it depends on. I recognise the person saying these things, but I also notice the movement. Some of the words feel as though they used to belong to somebody else’s argument. That is a slightly uncomfortable experience. Political views become familiar, both to yourself and to the people around you. They come with associations, and after a while you know roughly which positions are supposed to travel together. When those positions start moving apart, it can feel as though you owe an explanation. I have been trying to work out what that explanation is. Part of it will be age and experience. But I increasingly think it also has to do with a change in the conditions beneath my views. Things we could reasonably rely on have become less reliable. That changes what needs our attention, even when the things we ultimately care about remain much the same. ## When the foundations worked For much of my adult life, I experienced European security and prosperity as fairly dependable background conditions. Energy arrived. Goods could be bought. Digital services became better and more accessible. There were wars, crises and plenty of reasons for concern, but the basic arrangements underneath my daily life generally continued to function. Against that background, it made sense to concentrate on the consequences of prosperity: environmental damage, inequality, corporate power, the pressure to consume and the place of work in a good life. Those were important questions, and they still are. I have no desire to measure progress by how much more we manage to buy. We had room to ask what prosperity was for because a great deal of the capacity to produce it was already in place. It did not need to occupy the foreground of every discussion. We could argue about working less, distributing wealth more fairly and limiting harmful forms of production while relying on an economy that would continue to support those choices. I do not think that was a mistaken set of priorities. It reflected conditions in which many of us were able to live. The difficulty begins when those conditions change and our way of organising the argument does not change with them. ## When the ground starts shrinking The image that comes to mind is an island of ice that is slowly getting smaller. While it is large and stable, you can concentrate on how to live on it. As it shrinks, deciding how to share the remaining space becomes more difficult. You also become interested in what might stop the loss and allow the ground beneath you to grow again. That is increasingly how I experience the discussion about Europe. There are still choices to make about the resources we have. But I am less confident that the capabilities supporting those resources will remain available without much more deliberate effort. Russia’s invasion of Ukraine made energy dependence harder to regard as a technical or commercial matter. In digital technology, I have become more aware of the distance between being able to use a system and having any influence over the conditions on which it remains available. Industrial knowledge, infrastructure and security seem much less like permanent background features than they once did. There is an order of dependence here. A society needs enough productive capacity to sustain the services, protections and freedoms it wants to offer. Above a certain level, there is room to debate many different arrangements. As that capacity weakens, the range of workable choices begins to narrow. We can continue to express the same ambitions while becoming less able to realise them. That is the awkward turn in my thinking about growth. I have often associated it with more consumption, greater convenience and luxuries we could probably do without. But growth also matters when the capacity to support more fundamental choices is under pressure. Restoring that capacity starts to feel like a condition for keeping those choices open. ## Looking again at the world I grew up in This has made me look differently at the Philips region in the Netherlands where I grew up. Philips was an employer, but its presence extended into schools, sports clubs, technical education, research and the suppliers around it. Making things was part of the organisation of everyday life. There is plenty about that world I would not want to recover. Yet I have developed a different appreciation for something that was fairly ordinary within it: the accumulated ability to understand a difficult problem and make something that worked. That ability was visible in products, but it also lived in people, institutions and relationships. There were people who knew how to do things, people who could teach them, and places where that knowledge could develop over time. For years, there were good reasons to focus on the costs of technological progress. Pollution and waste demanded attention. Later, the internet gave us its own reasons for criticism, as possibilities for communication and freedom became entangled with surveillance, advertising and extraordinary concentrations of power. Those concerns remain valid. What has changed for me is the urgency of another concern alongside them: whether we can maintain and develop the ability to make things ourselves. ASML gives me a concrete way to think about that. The company draws on engineering knowledge, specialised suppliers and relationships developed over decades. Its success makes visible a much wider capacity to do difficult work. That capacity cannot simply be ordered when circumstances make it urgent. Once you start thinking about how it is built, sustained or lost, growth becomes a more substantial subject than an annual percentage. It becomes a question of what a society is learning to do, and whether it will still be able to do it a generation from now. ## Having a say in the technology we use AI brings this close to my own daily practice. I spend a great deal of time working with it, and my curiosity has only grown. At the same time, much of the technology I rely on is developed and controlled outside Europe. I can find a tool extraordinarily useful and still be concerned about the dependence that grows around it. Its usefulness makes that dependence more consequential. The more work we organise around these systems, the more their availability, direction and terms matter. Europe’s concern with rights, privacy and democratic control is important to me. I would not want us to abandon it in pursuit of technological success. But I increasingly want the ability to build to sit alongside the ability to scrutinise. Regulation can establish conditions for the use of technology. Building it creates another kind of influence: over its design, its development and the problems it is intended to solve. Both matter if we want our preferences to have practical consequences. I do not imagine that Europe should make everything itself. I am more interested in whether we have enough knowledge and capacity to make meaningful choices within our dependencies. That includes understanding the systems we use, contributing things others need, and having credible alternatives when an arrangement stops serving us. Seen that way, technological capability is part of the ground on which political choices become possible. We may have strong views about the society we want, but we also need some ability to shape the systems through which it functions. ## What I now hear in the word growth When I hear an argument for growth now, I am more inclined to ask what capacity it would create. Would it help us provide care, maintain infrastructure, develop cleaner energy or give people more freedom over their time? Would it leave us better able to respond to circumstances we cannot yet anticipate? Those questions give growth a purpose I can recognise. They also keep the older concerns involved. More output does not automatically create a fairer society. Some production causes damage that its price fails to reflect. The benefits of productivity can be distributed in very different ways. But these are arguments about the kind of growth worth pursuing and the arrangements through which people benefit from it. They do not remove the need for a productive foundation. This is where I feel my own position moving. If that foundation is deteriorating, concentrating only on how to divide what remains becomes an increasingly constrained exercise. I also want to understand what would make it stronger, what we could become better at, and where new possibilities might come from. The ambition to work less, for example, still makes sense to me. It becomes more attainable when we can produce what we need with less effort. Good healthcare still matters. So does the knowledge and productive capacity that allow us to provide it. My interest in the means has become more urgent because the ends continue to matter. ## Recognising the change In conversations with friends and family, this does not always fit the familiar political shorthand. An argument for industry can be heard as a position on capitalism. A concern about defence can seem to imply a whole set of other allegiances. Words carry histories, including our own histories of using or resisting them. I understand that reaction because I sometimes have it myself. I hear myself arguing for growth and briefly wonder how I arrived there. The explanation is becoming clearer. We had room to concentrate on certain questions because other conditions were sufficiently secure. As those conditions weaken, attention has to move towards sustaining and rebuilding them. That does not make the earlier questions foolish or the values behind them obsolete. I have not arrived at a complete political position through all of this. I am still working out what follows in practice, and which arguments for growth deserve support. But I can see why the subject has acquired a different weight for me. The next time I find myself arguing for growth, I want to be clearer about what I hope will grow: our ability to care for people, to make difficult things, to choose how we work and to influence the technologies through which we live. Those are possibilities I have valued for a long time. I am becoming more concerned with whether we will still have the ground beneath us to sustain them.

I recently discovered that NASA has a Chief Knowledge Officer. I may have felt a little too pleased about this. Knowledge has become central to my work, and to what we are building at Schmuki. And for some time I have been making what can occasionally feel like an embarrassingly earnest argument: organisations need to start treating their knowledge as a strategic asset. Not as a SharePoint problem. Not as document management. And not as the digital cupboard where everything goes once a project is finished. So discovering that NASA has someone with knowledge literally in her title felt like a small moment of vindication. Apparently, knowledge management really is rocket science. ## Knowledge management had an image problem Knowledge management is hardly new. Organisations have spent decades building taxonomies, intranets, document-management systems and knowledge bases. But it has often lived slightly apart from the organisation itself. There was something almost library-like about it. Specialists classified information, designed structures and tried to persuade everyone else to document what they knew. Maintaining those structures required a great deal of human labour, while the organisation itself kept changing. The result will be familiar to almost anyone who has worked in a large organisation: elaborate information environments that gradually drift away from reality. The SharePoint site nobody quite trusts. The policy document that may or may not still apply. Several versions of the same process. Knowledge trapped in people’s heads, inboxes and project folders. That was already a problem. AI makes it a different kind of problem. ## AI works from knowledge A language model brings an extraordinary general capability to interpret, reason and generate. But it doesn’t automatically know your organisation. It doesn’t know what you have decided. What your current policies are. Which products you offer. What you promised customers. How a particular regulation applies to your work. What was learned from the last project. Which version of a procedure is authoritative. For AI to become genuinely useful inside an organisation, it needs the right material to reason from. That changes the value of organisational knowledge. A knowledge base is no longer primarily something we maintain in the hope that an employee might search it one day. It increasingly becomes part of the grounding layer for systems that answer questions, support decisions and, as we move towards agents, take actions. Put an intelligent agent on top of a chaotic information landscape and you haven’t solved the information problem. You may simply have accelerated the chaos. ## But AI also works on knowledge This is the other half of the change, and I think it matters just as much. The same AI that needs well-organised knowledge can help us create and maintain it. It can classify documents, restructure information, compare versions, extract entities, identify contradictions, connect related material, detect gaps and help determine what needs updating when the outside world changes. That matters because knowledge has always had a maintenance problem. Organisations aren’t static. Laws change. Products change. People leave. New decisions are made. Terminology evolves. Experience accumulates. A beautifully organised knowledge base begins ageing almost as soon as you finish it. AI changes the economics of that maintenance. It makes organisational knowledge easier and cheaper to maintain at precisely the moment when well-maintained knowledge is becoming more valuable. That creates a flywheel. AI works on knowledge. Better knowledge gives AI better material to work from. Using AI creates new experience and knowledge, which can in turn improve the knowledge system. Knowledge stops being an archive of the organisation and starts becoming part of its living infrastructure. ## From knowledge to wisdom There is another step beyond this. An organisation isn’t simply a collection of facts, documents and rules. It also contains experience about how those things should be applied. Two organisations can operate under exactly the same legislation and behave quite differently. A written policy rarely captures every exception, consideration or judgement that experienced people make when applying it. That distinction becomes increasingly important as AI moves from finding and generating information towards supporting decisions and taking actions. Knowing the rule is knowledge. Knowing how this organisation responsibly applies that rule in a particular situation is closer to wisdom. That is considerably harder to capture. But it may also become one of the most valuable things an organisation possesses. ## Back to the boardroom This is why I think the status of organisational knowledge is changing. AI didn’t suddenly make knowledge valuable. Organisations have always depended on what they know. But AI is making that value much harder to ignore. If knowledge is becoming both the material AI works from and the material AI works on, it seems increasingly strange to treat it primarily as an IT housekeeping problem. It is intellectual capital. It is AI infrastructure. Increasingly, it is part of the operating model of the organisation. That doesn’t mean every organisation needs to appoint a Chief Knowledge Officer tomorrow. But somebody needs to be responsible for a deceptively simple question: **Does the organisation actually know what it knows?** NASA, at least, has decided that question deserves serious organisational attention. I confess I find that rather reassuring. And perhaps a little vindicating. * * * The company does not live in the LLMA knowledge-intensive company should keep durable organisational knowledge outside the model, and let AI do what it is unusually good at: reason across it.Rob HoeijmakersRob Hoeijmakers

A few days ago I came across the Dutch government's move to establish a new organisation for disruptive innovation. NADI, the Nationaal Agentschap voor Disruptieve Innovatie, is explicitly inspired by the ARPA model, with DARPA its original and best-known example. I did what I tend to do when I encounter a new institution: I tried to work out where it fits. That sounds straightforward. It wasn't. Over the past months I have spent quite a bit of time trying to understand the landscape around research, knowledge and innovation. In the Netherlands alone that quickly produces an impressive collection of organisations and acronyms: research funders, universities, knowledge institutes, ministries, advisory bodies, programmes for applied research and public-private partnerships. Look beyond the Netherlands and the landscape widens further. Germany has institutions such as Fraunhofer and Max Planck. France has CNRS and its own distinctive institutional traditions. At European level, Horizon Europe spans instruments and organisations ranging from the ERC to the EIC and EIT. In the United States there are the NSF, NIH, national laboratories and the ARPA agencies. Another organisation inspired by the ARPA model therefore seemed like another piece to add. And that was where I got stuck. ## The Lego view My instinct when confronted with a landscape like this is analytical. First identify the pieces. Establish what each does. Find the categories. Understand the differences. Draw the connections. Eventually, if you have done your homework properly, everything should fit. I have come to think of this as my Lego view of the world. There is nothing particularly wrong with it. Before you can understand a system, it helps to know what is actually in it. A research funder is not a university. An advisory council is not a research institute. Two organisations that appear similar from a distance may have quite different purposes, powers and histories. The inventory gives you grip. But something strange happened as my inventory improved. I knew more, yet the whole did not become correspondingly clearer. The organisations were sitting increasingly neatly in their boxes while the thing I actually wanted to understand seemed to be happening somewhere between them. So I changed the question. Instead of asking: **What are all these organisations?** I started asking: **What are people trying to make happen here?** ## Put the people back in Once I did that, the landscape began to move. Someone wants to understand why something happens. Someone has an idea for a technology that does not yet exist. A teacher wonders whether children could learn something differently. A physician encounters a problem in clinical practice. A small company discovers that a process could be dramatically improved. A researcher sees a possibility nobody has tested. A government concludes that dependence on a particular technology has become a strategic problem. Different situations, but they generate remarkably similar needs. People need knowledge. Sometimes knowledge that already exists; sometimes knowledge that still has to be created. They need other people who know things they do not. They need expertise. Time. Money. Equipment. Data. Legitimacy. Places to experiment. Sometimes customers. Sometimes public institutions willing to participate, regulate or buy. And they need connections. The person who understands a problem is rarely also the person who possesses all the knowledge, capital, authority and practical capability required to address it. Researchers find practitioners. Companies find universities. Governments convene consortia. Students become researchers and researchers move into companies. Specialists from different disciplines discover that they have been working on different parts of the same problem. Not everything needs to become a product or an application. Sometimes the result is simply a better understanding of the world. But when knowledge does travel towards use, it may become a treatment, a teaching method, a standard, a machine, a policy, a company, a piece of software or simply a better way of doing something. Then people use it. And what happens in use produces new questions. Seen this way, the institutions do not disappear. They become more intelligible. Many of them can be understood as answers to recurring needs in these movements. Some educate people. Some investigate. Some provide money. Some connect. Some translate knowledge into practice. Some advise governments. And some are deliberately designed for questions where several uncertain approaches need to be tried and actively steered. ARPA-like organisations are one example of that last category. They are not _the model_ for organising innovation. They are a particular institutional answer to a narrower question: what do you build when a problem is important, the route is uncertain, several approaches may need to be tested in parallel, and the work requires unusually active programme management and a path towards use? Other societies and sectors have produced different answers. Once I started looking this way, the institutional landscape stopped resembling an organisational chart. It became a landscape of movement: questions, people, knowledge, money, authority, technology and experience travelling between different places. ## A lens in France Last year I encountered an enormous Fresnel lens in a French museum. It had once been used for a lighthouse and stood roughly two metres high. Its concentric sections reproduce much of the focusing effect of a far thicker lens while using much less glass. I took several photographs of it. Move around such a lens and what you see through it changes. Parts of the world behind it enlarge, shift or distort. The object remains where it is; your view through it does not. There is a limit to every metaphor, and I don't want to make the Fresnel lens do more work than it should. But I realised later why the object had stayed with me. Models compress reality. They have to leave things out. The important question is what survives the compression. My Lego model preserved entities particularly well. It showed boundaries, categories and responsibilities. It did not preserve movement particularly well. And it obscured something else. **Where you stand matters.** 0:00 /0:11 1× ## The same landscape, different routes Imagine somebody starting a company alone with an unusual idea. The knowledge and innovation landscape may appear primarily as a problem of access. Who knows something about this? Where could I test it? Is there funding? Am I eligible? Who can introduce me to somebody who understands what I am trying to do? Now put yourself in a company with seven employees. You may have customers, technical expertise and a genuinely promising idea. But taking two people out of the business for months to assemble a consortium, understand a programme and write applications may simply not be practical. The institutions have not changed. Your route through them has. Inside the R&D department of a multinational, the same landscape looks different again. Universities, laboratories, intellectual-property specialists, European programmes, standards bodies and international partners may all be accessible parts of it. The organisation may employ people whose job is to establish precisely these connections. Routes that are expensive and difficult for a seven-person company to use may be ordinary roads here. For a researcher, a university or a hospital, the landmarks shift again. The formal landscape is recognisable, but its entrances, incentives and useful connections are different. Then take perhaps the strangest position of all: government. Government is itself travelling through this landscape while simultaneously trying to alter it. It funds research and education, sets rules, creates incentives, buys things, convenes people and occasionally establishes an entirely new institution because an important route appears to be missing. That suggests another way of looking at innovation policy. Alongside asking how much money government spends or which organisations it creates, we can ask what it is doing to the possible routes through the landscape. **The landscape may be shared. The routes through it are not.** ## A few landmarks None of this makes the institutions unimportant. Landscapes need landmarks. The table below is deliberately small. It mixes funders, research organisations, programmes and networks because those are some of the forms this landscape takes. The entries are not counterparts. They are examples of different institutional answers to recurring needs. Recurring need | Netherlands | Germany | France | European Union | United States ---|---|---|---|---|--- **Supporting inquiry** | NWO, ZonMw | DFG | ANR | ERC, wider Horizon Europe funding | NSF, NIH **Sustaining research capacity** | Universities, TNO | Universities, Max Planck | Universities, CNRS | European research infrastructures | Universities, DOE national laboratories **Connecting research and practice** | SIA, TNO | Fraunhofer | Carnot institutes | EIT KICs, European Partnerships | Manufacturing USA **Pushing high-risk ideas towards application** | NADI, being established | SPRIND | Bpifrance, France 2030 | EIC | DARPA, ARPA-E, ARPA-H Another observer could take exactly the same landscape and produce a different table. Follow money and one map appears. Follow knowledge and another. Follow people and education and it changes again. Start with a small company rather than a ministry and some enormous institutions almost disappear while previously minor connections become decisive. A useful model does not eliminate these perspectives. It helps us move between them. ## Looking again This leaves me in a rather different place from where I started. A news item about a new Dutch innovation agency prompted a familiar question: _where does this organisation fit?_ I can answer that question better now. But I am less interested in it. I want to know what happens to the landscape when an institution like this is introduced. Which routes does it create or shorten? Who can reach whom more easily? Which ideas can travel further, and which risks become possible to take? If something succeeds, where can it travel next? Those questions apply well beyond one new Dutch agency. We can ask them about a research funder, a university, a European programme, an applied research institute, a corporate R&D department or an entire innovation policy. I have not discarded the Lego view. I still want to know what the pieces are. Without that groundwork, talk about relationships and networks quickly becomes vague. The inventory matters. It is simply no longer where I want to stop. I started by trying to find the right place for each institution in a model. Somewhere along the way, I became more interested in the spaces between them. First learn the landmarks. Then look beyond them. And ask: **What is trying to happen here?** **What has to move, and between whom?** **And from where I stand, which routes are actually open?**

ChatGPT has become remarkably good at remembering me. Not just facts, but the shape of what I am working on. Projects appear, intensify and disappear. Interests shift. The way I use ChatGPT changes. Somehow, its memory seems to move with that. I had noticed this without really understanding why. Then this week I tried to save a memory in ChatGPT Plus, and it would not let me do it in the way I expected. That small annoyance sent me looking. What I found is that ChatGPT Memory has changed quite fundamentally. ## From remembering to synthesising The original memory model was easy to understand: I told ChatGPT something mattered, and it saved that information as a memory. The newer system works differently. OpenAI describes it as a **“continually updated synthesis”** of what ChatGPT has learnt from previous conversations. Behind it is a background process it calls **dreaming**. Instead of simply accumulating facts, the system keeps revising its understanding as new conversations happen and older information becomes less relevant. That is the important shift. Memory is no longer just a record of what was true. It tries to maintain a picture of what is true now. ## A sliding window in time I think that explains why it works so well for me. My work changes quite quickly. Projects start and finish. Something I am investigating intensively for a few weeks may become irrelevant afterwards. New interests appear. Even the way I want ChatGPT to work with me develops. A list of saved facts struggles with that. It knows what was true. A synthesis can try to understand what is true **now**. OpenAI gives the simple example of a planned trip. Before the trip, remembering that someone is going somewhere is useful. Afterwards, that same information needs to become part of their history rather than remain a current plan. My experience is broader than that, but similar. Memory now feels more like a sliding window through my work and interests than a notebook I have been filling for years. It is surprisingly seamless. In OpenAI's terminology, ChatGPT is dreaming in the background. In use, it sometimes feels as though it is dreaming along with me. ## The strange part: Business still remembers I discovered all this because I initially thought I had found another difference between ChatGPT Plus and ChatGPT Business. After Plus declined my familiar “remember this” instruction, I opened Business and tried the same thing with something harmless. I told it I was exploring quantum computing in education in the Netherlands and Europe. Its response: **Memory updated.** OpenAI says newer memory capabilities have also been rolling out to Business, so I don't think this is simply new memory versus old memory. But the different interaction was enough to send me looking. And I am glad it did. ## Better memory, less agency There is a trade-off here. With the old system, I had very direct agency. I decided what mattered and told ChatGPT to save it. With dreaming, some of that judgement moves to the system. ChatGPT decides what is relevant, what should fade and how different pieces of context fit together. I can inspect a Memory Summary and correct things, but that summary is not necessarily everything ChatGPT remembers. For me, so far, the trade seems worthwhile. I would not assume that is true for everyone. It probably depends on what you use ChatGPT for and how much continuity you want between conversations. But memory is one of the things that determines how valuable an LLM becomes to me. A better model is useful. A model that increasingly understands the context in which I use it is something else. I went looking because ChatGPT wouldn't let me save a memory. I came away understanding why I might not want to go back.

When I first saw that the European Commission had proposed a new **Public Procurement Act** , I thought I knew roughly what kind of news this was. Another European Act. Another promise to simplify rules. A little innovation, a little digitalisation, some “Made in Europe” language. Important, perhaps, but not necessarily something I needed to read 200 pages about. Then I noticed what public procurement actually covers. It is not mainly about how the European Commission buys things. It is about **how governments, municipalities, public universities, hospitals, transport operators and other public organisations across Europe spend money**. Together, public procurement represents roughly 15 per cent of European GDP. That changes the scale of the question quite dramatically. When a municipality buys software, a ministry commissions research or a public hospital buys equipment, it cannot simply choose the supplier it likes best. Public money requires a process: suppliers must be treated fairly, decisions must be transparent and someone must be able to explain afterwards why this particular company won. That is what procurement is for. It is not bureaucratic theatre. Without such rules, public purchasing would be far too vulnerable to favouritism, bad decisions and private relationships. Still, after reading more about the Commission’s proposal, I began to think that procurement may be one of the less known reasons Europe finds it difficult to turn innovation into scale. Not because the rules literally force governments to buy the cheapest option. They do not. But because they can make the familiar option much easier to defend. ## The cheapest bid is not the whole story I had assumed that public procurement law was one of those areas where the formal answer was simply: buy the lowest bidder. That turns out to be too simple. The current European rules already allow public buyers to consider quality, environmental impact, social effects, innovation and the full cost of a solution over its lifetime. The law does not say that a municipality must buy the cheapest possible software, regardless of whether it works well. And yet price-only purchasing remains common, while innovation procurement is still uneven across Europe. The European Court of Auditors found that **competition for public contracts declined** over the past decade, with fewer bidders and a growing number of procedures attracting only one bid. So there is a more interesting question than whether the law permits innovation. Why does a system that permits quality and innovation still so often reward price, certainty and suppliers that have been around for a long time? I think the answer is partly hidden in a very understandable public-sector instinct: **choose the decision that will be easiest to justify afterwards**. Imagine a municipality buying an AI system to help residents find the right service. One supplier offers a familiar platform with years of public-sector references, a clear implementation plan and a price that fits neatly into a spreadsheet. Another is a smaller company with a more interesting approach. Its system might produce better results, save time for residents and civil servants, and become more valuable over time. But it also requires testing, integration and perhaps a different way of working. The first proposal is easier to compare. The second asks the buyer to make a judgement. That is where innovation often gets stuck. A known product can be specified in detail. An established supplier can show years of references. A low initial price can be explained in one line. The possible value of something new is harder to put in a tender document. It may only become visible later, through better outcomes, lower costs, resilience or productivity. It may depend on whether people actually adopt the new system. Nobody needs to write “prefer the incumbent” into the rules. A process designed around comparability and defensibility can produce that result on its own. ## Innovation runs on a different clock This is particularly visible when the purchase involves technology. A new solution may initially cost more because it **includes development, experimentation, staff training or organisational change**. Its real value may only become visible after it has been used for a while. That does not make it a good purchase automatically. Public buyers should not be asked to fund every promising demonstration. But it does mean that the purchase price is often the wrong clock for judging innovation. A price is immediate and measurable. Long-term value is more difficult. It involves assumptions, future behaviour and outcomes that may be real but are not yet visible. The strange result is that an organisation can be legally free to buy something better, while still being practically organised to buy something safer. That matters for Europe because public organisations are not small customers. They are often the market. Europe spends a great deal of energy on research, start-ups, strategic technologies and private investment. But a young company also needs someone willing to buy what it has developed. If Europe can fund the research, help create the company and then make it unusually difficult for public institutions to become early customers, there is a gap in the chain. The technology makes it out of the laboratory, but not necessarily into a real market. ## The Commission is trying to change more than the paperwork The new proposal does contain a large amount of administrative repair. It would **replace three existing procurement directives** with one directly applicable regulation. It would simplify procedures, make market consultation more normal, limit unnecessarily excessive demands for turnover or previous public-sector experience, and connect national procurement systems through a shared digital infrastructure. All of that sounds sensible. The fact that a small company may need to navigate several systems, repeatedly submit the same information and satisfy requirements that have little to do with its ability to deliver does not help Europe create a more dynamic market. But the more interesting part of the proposal is that it tries to change what counts as a good purchase. The Commission wants price and quality to be assessed together as the normal approach. It also proposes a new innovation procedure. This is more significant than it sounds. Instead of beginning with a fixed technical specification, a public buyer could begin with a societal challenge. It could ask the market for ideas, establish how it will judge value, test promising approaches and then purchase the solution that proves itself. A city would not have to begin by saying: “We need this exact system.” It could begin by saying: “We need to reduce waiting time for this group of residents. What might work?” That is a very different relationship between a public organisation and the market around it. The proposal also makes room for suppliers to retain intellectual property developed in such a process, unless there is a good reason not to. That matters because a company that solves one public problem may then be able to offer the solution to others. There is also a European-preference dimension, especially in strategic sectors. I am less interested in treating that as a simple “buy European” story. European origin is not a guarantee of quality or innovation. But the broader shift is clear. The Commission increasingly sees public purchasing not just as a way to spend money correctly, but as a way **to create resilience, demand and industrial capacity**. ## The part a new Act cannot solve I find this more interesting than I expected because it points to a limitation in the way Europe often talks about innovation. We tend to focus on invention, capital and infrastructure. Those are all essential. But institutions matter too. A new regulation can make it easier to consult the market. It can make quality more prominent. It can create a proper route for testing and buying something that does not yet exist. What it cannot do is **make an organisation comfortable with uncertainty**. That depends on procurement expertise, organisational culture, political expectations and the degree to which someone is personally blamed when an experimental project does not work. If a new system fails, there will be uncomfortable questions about why the organisation took the risk. If a familiar supplier disappoints, that can look like an unfortunate continuation of normal practice. That is probably the deepest procurement problem. Europe has spent years encouraging companies to innovate. Its public institutions have often been rewarded for buying what they can most easily defend. The proposed Public Procurement Act is not a solution to Europe’s wider innovation gap. But it is an acknowledgement that innovation policy does not end with inventors, investors and factories. It also depends on whether the institutions that spend public money can learn to buy something new.

I was discussing a fairly ordinary AI problem this week: what to do when someone types personal information into an AI application. Suppose someone writes their name, address or phone number into a chat. You may not want that information to reach the large language model. So you put something in between that recognises personal information and removes it. Something like this: **User → browser → application server → PII filter → LLM** Perfectly reasonable. Except that the personal information may not reach the LLM, but it has already reached _us_. Our application server has received the original message. So I wondered: can you move the filter? **User → browser → local PII filter → application server → LLM** Almost the same picture. One component has moved. But architecturally, something important has changed. The original personal information may now never leave the user's device. ## Then I happened to find Desert Ant Later that day, quite by coincidence, I saw a post by **Paul Veugen** announcing a new company called **Desert Ant Labs**. I have followed Paul for a while, so I clicked out of curiosity. Not because I was looking for a PII solution. Desert Ant grew out of work behind Detail, where the team had been using machine learning for things such as transcription, audio enhancement and video processing. Instead of relying on a cloud API for every task, they started developing small models that could run locally. While looking through the models, I found one called **Redact**. Which was almost exactly the thing I had been thinking about a few hours earlier. Desert Ant Labs: Little brains in every productThe fastest on-device models for the job. Add them to your app in a few lines of code, at no token cost.Desert Ant Labs ## A small model with one job Redact is not an LLM in miniature. It has a particular job: recognise personally identifiable information in text and replace it with placeholders. Desert Ant provides it for native applications, but also for JavaScript applications running on the web. That made the earlier conversation concrete. A web application does not necessarily have to send the original text to its server and then decide what should go to an LLM. It can perform some computation locally first. So this: **User → browser → application server → PII filter → LLM** can become this: **User → browser + PII filter → application server → LLM** The important distinction is the trust boundary. In the second version, the application server may never receive the original identifying information. That does not make the application anonymous or privacy-proof. Detection can fail, context can still identify someone, and server-side safeguards may remain necessary. But as a way of minimising what data leaves a device in the first place, it is an interesting building block. ## Apparently, you can build applications this way This is where my little PII question became more interesting. I am not an application developer. I spend enough time around software and AI development to understand quite a bit of what is happening, but I do not spend my days deciding which process runs where. What clicked for me was that AI can become one of the components inside an application, rather than something the whole application simply sends work to. A native app can run models on the phone. A web application can do computation locally in the browser. A backend can still handle the things that belong on the server. And a large external model can be called when the task actually needs one. Google's work with Gemini Nano and Chrome's built-in AI APIs is another, quite different, example of local rather than cloud AI: there the browser platform itself supplies local AI capabilities rather than an application incorporating a specialised model. That is a different mental model of "adding AI". It also connects to something I wrote about earlier in Looking Past the Model: the model itself is only one part of the system we are actually building. ## Not every AI task needs a large model Desert Ant makes that visible because its models are deliberately narrow: language detection, transcription, audio enhancement, PII detection and similar tasks. These are useful jobs, but they do not require a model that can write essays, explain quantum mechanics and discuss philosophy. That is probably what stayed with me from the whole discovery. I started with the question: _how do we stop personal information from reaching the LLM?_ A few hours later, I had a different one: _Where should this particular piece of intelligence run in the first place?_ Sometimes the answer will still be a large model somewhere in the cloud. But apparently, quite a lot can happen before you ever get there.

I recently read an article about an AI initiative in Groningen, aimed at reducing dependence on American and Chinese AI. Then I read the reactions on X. A number of technically knowledgeable people were mocking the idea of fine-tuning an existing Qwen model. The criticism was understandable: this is not particularly exotic work. Why present it as technological sovereignty? I understood the point. But I did not quite share the amusement. The underlying question still seemed important: if Europe wants to be less dependent on a handful of foreign AI companies, what exactly should we be able to do ourselves? That reminded me of Apertus. ## The appeal of the clean stack **Apertus** is a Swiss AI initiative involving ETH Zurich, EPFL and the Swiss National Supercomputing Centre. The Swiss have trained their own foundation models, using their national supercomputer Alps. The models are open, much of the surrounding work is transparent, and researchers can now access Apertus through public infrastructure. There is something very satisfying about it. Researchers. Compute. Models. Operations. A clean stack. I have written before that Europe needs compute if it is serious about technological sovereignty. Apertus shows what happens when that compute is connected to the expertise required to build and run models yourself. For a moment, the conclusion seemed obvious: perhaps this is what the Netherlands should be doing. Then I looked again. Apertus AIFully Open Foundation Model for Sovereign AISwiss AI Initiative ## Or perhaps an ecology The Dutch picture is much less tidy. GPT-NL is building foundation-model capability. The AI Factory in Groningen is building public compute, expertise and access. Commercial infrastructure is emerging elsewhere. Smaller initiatives adapt existing open models rather than building new ones. Initially, that looked fragmented. Now I am not so sure. If one model disappoints, another can replace it. If foundation models become more commoditised, not every country has to keep building one. Public and commercial infrastructure can coexist. Different organisations can specialise. Instead of controlling one stack, you create an ecology. And ecologies are messy. ## Sovereignty as optionality I think I am naturally attracted to clean architectures. There is comfort in drawing the whole thing, deciding which parts matter, and bringing them under control. But real systems rarely stay that clean. Switzerland still depends on Nvidia hardware and a much wider international technology chain. No European strategy will remove all dependencies. Perhaps that is not the right goal anyway. The more useful question may be whether a dependency is replaceable. Can you switch models? Move workloads? Choose between providers? Does expertise exist in more than one place? If one component disappears, does the rest of the system continue to work? Seen that way, sovereignty starts to look less like ownership and more like optionality. You do not need to control every layer. You need enough capability, alternatives and understanding that no single dependency becomes destiny. ## Stack or ecosystem? I still find **Apertus** impressive. Switzerland has deliberately preserved the ability to build, train and operate foundation models. But I am less convinced that its integrated approach is necessarily the blueprint. Perhaps the Swiss are building a stack, while the Dutch are slowly assembling an ecosystem. The first is cleaner. The second may be more resilient. I started out wondering whether Switzerland had built something the Netherlands was missing. I am less sure now. And that, I think, is the more interesting question.

A good payment experience should make the underlying machinery disappear. I was reminded of that while helping my 80-year-old mother-in-law in Switzerland buy a flight ticket on the SWISS website. Her familiar Visa payment failed without a useful explanation. TWINT, a Swiss mobile payment system I barely knew, worked immediately. That small reversal changed how I thought about mobile payments. I had assumed QR-based payments added another technological layer. In practice, TWINT did the opposite. It reduced the interaction to something very simple: scan, inspect, approve. That is what good payment design can do. The complexity does not vanish. It moves out of the user's way. ## Then we noticed TWINT I was helping my mother-in-law remotely. I could see her Windows desktop through screen-sharing software, but she still had to do the clicking herself. The SWISS checkout was long. We worked through flight options, details, seats and confirmations until we finally reached the payment. Her Visa card failed. Why, we still do not know. It could have been the card, the bank, 3-D Secure, the payment provider or something else in the chain. From our side, it simply did not work. Then we noticed TWINT. I had barely heard of it and, to be honest, my first reaction was mild distrust. It involved a QR code. My mother-in-law did not seem concerned. She picked up her phone, scanned the code, checked the payment and approved it. Done. After all the complexity of the familiar card payment, the unfamiliar Swiss mobile payment method was by far the simplest part of the experience. ## What was actually happening I looked it up afterwards. TWINT is essentially a mobile payment layer connected to the Swiss banking system. For an online payment on a computer, the customer can scan a QR code in the TWINT app, check the merchant and amount, and approve the transaction there. The details underneath can be more complicated, but the user does not have to operate that complexity. This is something I have been trying to understand for a while: how money actually moves, and the different layers behind a digital payment. That also changed how I thought about the QR code itself. I am still wary of QR codes in public spaces. A sticker on a parking meter or restaurant table can be replaced, and you cannot inspect the contents with your eyes. But on a website I already trusted, the QR code was really only a hand-off. The important moment came afterwards, when TWINT showed the merchant and amount and asked my mother-in-law to approve the payment. ## One more layer, less complexity I use Apple Pay all the time. I have previously used it to explore how much payment infrastructure can disappear behind a good interface. The Netherlands has long had iDEAL, and Wero is now changing that European payment landscape. Those systems are different, but this small Swiss experience gave me another way to look at the same development. A new layer does not necessarily mean more complexity for the person using it. I had assumed QR-based payments added another technological layer. For my mother-in-law, that layer removed one.

This week, Emmanuel Macron and Dutch prime minister Rob Jetten visited ASML in Veldhoven. The French delegation included Mistral AI, making the setting unusually apt: a French AI company visiting the Dutch manufacturer of the machines needed to produce the most advanced chips. The resulting Franco-Dutch statement was unusually direct about the geopolitical stakes. Technological leadership, it said, translates into economic power, political influence and military capability. Europe therefore needs to connect AI, computing, semiconductors, photonics and quantum technology into something resembling an industrial system. One phrase caught my attention. Europe needs seamless funding “from lab to fab”. A day later, NOS reported that the Dutch government is accelerating plans for a national investment institution, backed by an initial €3.3 billion. Its purpose would be to help innovative companies grow and keep more of them in the Netherlands. Seen separately, these are two rather different news stories: a diplomatic technology visit and another Dutch financing initiative. Together, they helped me understand a missing part of the European technology debate. ## More than another pot of money I have been circling this problem in my writing about deep tech. In The Deeptech Dilemma, I looked at Europe’s difficulty in turning excellent science into large technology companies. In my conversation with Alain le Loux about investing in atoms, the central problem was patient capital. Deep-tech companies need large amounts of money, specialist knowledge and considerably more time than a software start-up. More recently, I found myself making a similar argument about AI compute: once land, electricity, data centres and chips enter the picture, this starts looking less like conventional venture capital and more like infrastructure finance. My assumption was that Europe simply did not have enough capital of the right kind. That remains partly true. But the Dutch investment-bank discussion points to a more specific problem. Europe does not merely lack money. It lacks enough institutional machinery for combining different kinds of money and staying with a technology as it moves from research to start-up, factory and industrial infrastructure. The Netherlands already has public financiers, regional development agencies, subsidies, venture funds, a Deep Tech Fund and access to European programmes. So my first reaction to the idea of a new national institution was fairly obvious: why add another fund? The important distinction is that it is not supposed to be just another fund. A fund is, in simplified terms, a bounded pot of money with a particular mandate. It invests until that money has been allocated. A promotional investment bank can operate funds, but it can also provide loans, guarantees and equity, take different positions within a financing package and, depending on its structure, raise additional capital against its balance sheet. It can also do something less visible but perhaps equally important: develop projects, combine financiers and absorb precisely the part of the risk that prevents others from participating. That matters because the financing problem changes as a company grows. A research grant may help prove the science. Venture capital can finance an early company. But building a semiconductor facility, biotechnology production line or large compute campus may require hundreds of millions or several billions. At that point, neither a normal start-up fund nor a commercial bank is necessarily equipped to carry the project. A public investment institution can provide the first layer, a guarantee or a long-term loan. That can make the risk acceptable to banks, insurers, pension funds and European institutions. Public capital is then not only spent. It is used to organise a larger investment. ## France as a reference case Germany’s KfW is the classic European example of a promotional bank with a very large balance sheet and extensive capital-market financing. It demonstrates the financial difference between a bank and a collection of funds. For the technology question, however, France may be the more interesting reference case. France created Bpifrance in 2012 by combining three existing public financing organisations. It brought credit, guarantees, innovation financing, direct investment, investment in private funds, export support and advisory services into one institution. That is different from making one large pot of public money. France centralised the capacity to translate political priorities into financial instruments, investment programmes and relationships with companies. There is some evidence that this has helped develop the market around it. According to an OECD assessment, Bpifrance invested €4 billion directly in almost 450 companies between 2013 and 2022. It invested another €5 billion in 160 private venture-capital funds. Those funds ultimately raised €27 billion, implying that every euro committed by Bpifrance was accompanied by considerably more capital from elsewhere. An even more interesting detail is that Bpifrance’s average share in its partner funds declined as those funds became larger. That is what a successful public intervention should ideally do: help create a market rather than permanently replace one. France has not solved European innovation. It is not the continent’s uncontested technology leader, and a powerful state institution brings obvious risks of political interference, complexity and crowding out private investors. Still, something coherent is visible. France has combined research institutions, industrial policy, public investment, procurement and political promotion around technologies such as AI, nuclear energy, aerospace and defence. Mistral’s presence at ASML fits that pattern. It links a French attempt to build an AI champion with the Dutch industrial capability on which the entire advanced chip industry depends. My hunch is that France’s centralising tradition helps here. This is difficult to prove as a simple causal claim, and centralisation can produce expensive failures as easily as successful national projects. But it does give the country a capacity that Europe often lacks: the ability to choose a direction and then align institutions, capital and political attention behind it. Bpifrance is not the sole explanation for France’s current technology momentum. It is better understood as part of the machinery that makes such momentum possible. ## National institutions inside a European system This still leaves the question of why the Netherlands needs its own institution. Why not leave this to the European Investment Bank? The answer appears to be that the two levels perform different roles. The EIB provides continental scale, European risk-sharing and access to large pools of capital. National institutions possess local knowledge, find and prepare projects, work with smaller companies and represent national industrial interests. The EIB itself describes these institutions as intermediaries, co-investors and co-financiers that help difficult projects come to life. A Dutch institution could therefore help a photonics company or biotechnology plant become investable, combine its own contribution with Dutch pension capital and then bring in the EIB or another European programme. This is not necessarily economic nationalism. For the largest technologies, a purely national approach will be too small. But European financing cannot be organised entirely from Luxembourg or Brussels either. Someone still has to know the companies, understand the industrial ecosystem and build the project. The emerging system is layered: national institutions originate and organise; European institutions add scale and risk-sharing; private capital supplies much of the eventual investment. That system remains uneven. Germany has financial scale. France has built a more integrated innovation institution. The Netherlands is now trying to add a layer it has so far lacked. At European level, new scale-up and competitiveness funds are intended to connect these national efforts. None of this guarantees good investments. A national institution can just as easily become a politically convenient collection of programmes. The decisive question is therefore not whether the Netherlands creates another organisation with several billion euros. It is whether that organisation gains the mandate, expertise, instruments and balance sheet to connect the pieces that already exist. This is what I saw differently after putting the two news stories together. Capital is not merely a quantity. It has an architecture. Europe’s problem has long been the discontinuity between its laboratories, its young companies and industrial production. The visit to ASML showed the outlines of a more coherent European technology system: French AI, Dutch semiconductor machinery, European demand and public-private investment. The technology is not the only thing that must travel from lab to fab. The financing has to make the same journey.

I have been experimenting with browser control in both ChatGPT and Claude. It is one of those capabilities that can look like a demonstration until you encounter the right work for it. I regularly have to fill in forms, for example, and I do quite a lot of user acceptance testing on our own platform. That means moving through the same screens, checking the same interactions and recording what happens. It is useful work, but not always a useful way to spend my own attention. An agent can already do a surprising amount of it, provided it has access to a browser. Until now, that has meant Chrome extensions. There is one for Claude and another integration for ChatGPT. They work, sometimes impressively, but the arrangement has always felt messy to me. The extension has to live in the right browser profile, alongside the rest of my work. Each AI provider needs its own route into the browser. The extension, browser permissions and provider all have to continue cooperating. When the connection becomes unstable, it is not always obvious which layer is responsible. Chrome is not even my normal browser. I work on a Mac and use Safari. Moving work into Chrome simply because an AI provider has built its integration there already feels like the wrong dependency. Then I came across WebKit’s announcement of a new way for agents to interact with Safari. I gave it a test run, and the difference was immediate. The connection felt markedly more stable and the interaction more direct. My first tests also suggest advantages in latency and token use, although I have not done enough controlled testing to call that a benchmark. What interested me most was not the speed. It was the architecture. ## One interface, different agents The technology is called MCP, but the abbreviation is not particularly helpful. It has become a general label for many different connections between AI systems and other software. In this case, the underlying idea is straightforward: Safari provides a standard interface through which an agent can ask what is on a page and perform actions in the browser. The browser itself provides the connection. I do not need a separate Safari extension from OpenAI, another from Anthropic and perhaps a third one for the next provider. Any compatible agent can use the same interface. That reverses the relationship I had in Chrome. With an extension, the AI provider integrates itself into my browser. With this approach, my browser exposes a capability to whichever agent I choose. This also explains why the experience felt cleaner. The agent does not have to behave as if it were a person looking at a screen and trying to operate a mouse. Safari can make the page, its controls and its current state available in a structured form. Screenshots are still possible and sometimes necessary, but they are no longer the entire basis of the interaction. For a developer, this creates obvious possibilities for debugging and testing. I am interested in something slightly different. I am not a software developer, but the browser is where a large part of my professional work happens. If an agent can interact with that environment reliably, it becomes useful for many ordinary workflows that never justify a custom software integration. ## One less dependency There is a wider business point here. We are starting to build workflows around AI systems while the providers, products and models continue to change quickly. Every workflow tied tightly to one provider becomes another continuity problem. That does not mean dependencies can be avoided altogether. It means they should sit in the right place. A general ability to operate a browser is better provided by the browser than recreated as a proprietary extension by every AI company. When the connection is standard, the agent becomes more replaceable. I can use Claude today and another compatible agent tomorrow without rebuilding the browser side of the workflow. If one provider changes its product or loses its lead, my working environment does not have to change with it. This kind of optionality is easy to underestimate. It is less spectacular than a new model release, but probably more important once AI becomes part of daily operations. Continuity depends not only on what a system can do, but also on how easily its components can be exchanged when circumstances change. My experiment with Safari was small. I connected an agent, let it work in the browser and compared the experience with what I had been doing through Chrome. Yet it changed how I think about browser agents. Until now, I saw them mainly as AI products gaining access to a browser. This felt more like the browser becoming a stable working environment that different agents can enter. For someone who depends on the browser but does not want to depend unnecessarily on any single AI provider, that is a much more useful direction. ⚙️ Want to try it? Install Safari 27 beta, enable Show features for web developers and Allow remote automation and external agents, then connect it through Codex with codex mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp. It should then become available in ChatGPT Work conversations; start with WebKit’s instructions if you need the details.

A friend recently asked me what it was like to move from ChatGPT Plus to Business. He works individually, uses ChatGPT seriously and is considering making the same change. I should have had a simple answer. My business partner and I moved from Plus to what was then called ChatGPT Team in 2025. I even wrote about the experience. But the product has changed, and so has my answer. ChatGPT Business has become considerably more attractive to an intensive professional user. It is still not professional Plus. ## It is an organisational product Plus and Pro are individual plans. Business is an organisational workspace, available from two users and built around members, permissions, applications, administration and central billing. Its previous name, Team, arguably described it more accurately. This distinction is clearest in how professional data is treated. Plus users can disable model training, which is a meaningful privacy control. Business goes further: workspace data is excluded from training by default, and its use is governed by a business agreement that incorporates a data processing addendum when personal data is processed. That is not the difference between unsafe and safe. It is the difference between an individual setting and an organisational framework. For consultants, researchers, lawyers and others working with client or company information, that can be a substantial reason to consider Business even when they mostly work alone. ## Business has become more capable When we first moved, Business sometimes felt like ChatGPT with administration wrapped around it. It could even lag behind the individual product. Memory was the most obvious example. Earlier this year I wrote about Plus and Pro gaining access to relevant past conversations, while Business remained more contained. Moving to the professional environment meant accepting less personal continuity. That gap has narrowed. Business now supports memory and personalisation, while adding increasingly capable organisational tooling. The most important difference for me is integration. ChatGPT is no longer only somewhere to discuss information copied into a conversation. Through apps and MCP connections, it can retrieve information from other systems and increasingly take action in them. At the time of writing, OpenAI’s full MCP support, including write and modify actions, is available in beta on Business, Enterprise and Edu. Business can therefore operate much more like a connected professional workbench. This is the first time I have felt that Business is not merely the contractually appropriate product. For some professional users, it may also be the functionally better one. ## The workspace remains real The organisational layer does not disappear merely because the company is small. My business partner and I share a Business workspace, but we do not share one ChatGPT mind. Our conversations remain private unless we deliberately share them. Memory belongs to each user. Many connections are personal. Most of our actual work with ChatGPT remains individual. Around that sit workspace applications, permissions, members, billing and administration. The overhead is manageable, but the mental model takes time. An account is not the same as a personal workspace. A personal connection is not necessarily a workspace app. Memory is not company knowledge. Moving between the personal and Business environments can make these boundaries unexpectedly visible. Migration is also more consequential than an ordinary subscription upgrade. By the time someone uses ChatGPT seriously, they may have accumulated conversations, projects, memories, files, instructions, connections and working habits. OpenAI allows users to keep their personal workspace separate or merge it into Business. A merge is permanent. Some information migrates, some configuration does not, and the migrated material becomes part of the Business workspace. If access to that workspace later disappears, access to the migrated information can disappear with it. Business workspaces also currently offer no data export. My own move took time to settle. It was less like unlocking a new plan and more like moving into a new working environment. ## What the migration really taught me The most important result had little to do with choosing between Plus and Business. The migration showed me how much valuable context had accumulated inside ChatGPT. Conversations preserved decisions. Memory held important distinctions. Projects and instructions were beginning to function as company documentation. As my use of AI became more intensive, I realised that parts of the company were starting to live inside the LLM. That is a fragile architecture. ChatGPT can be an excellent workbench. It can retrieve, interpret and combine knowledge from document repositories, Git repositories, databases and operational systems. But those external systems should remain authoritative. The principle I now use is simple: > Keep the AI richly connected, but minimally authoritative. This also explains why my friend’s question has no obvious answer. There is a category of serious individual professionals who want business-grade contractual treatment and full professional integrations, but do not need multiple seats or organisational administration. They sit somewhere between Pro and Business. The ideal product for them does not quite exist. Moving to Business may still be the right choice. But it is not simply moving to a more professional ChatGPT account. The more professional decision is to understand what kind of environment you are building, who owns it and how much of your working knowledge would survive if you eventually decided to leave.

I use ChatGPT every day. I do not personally use **ChatGPT Search**. I knew the feature was there, but regarded it as an annex to the product. For me, ChatGPT was primarily a working environment: somewhere to think, write, analyse, organise information and increasingly interact with other systems. If it could also search the web, that was useful, but not central to how I understood it. Yesterday’s regulatory development has made that view harder to maintain. On 31 August, the European Commission designated ChatGPT a Very Large Online Search Engine under the Digital Services Act. I initially read this as a regulatory fact about ChatGPT Search. The search feature had grown beyond the DSA threshold, so Europe was applying its rules for very large search engines. The Commission’s fuller explanation is more interesting. It describes ChatGPT as a **hybrid service** which qualifies as an online search engine because it can respond to users’ prompts and queries, including by searching the web. Europe has not designated a separate product called ChatGPT Search. It has designated ChatGPT. ## How much of ChatGPT is now a search engine? The answer appears to be both broader and less absolute than the headline suggests. OpenAI reports that ChatGPT search had approximately 159.1 million average monthly active recipients in the European Union during the six months ending 31 March 2026. That is comfortably above the DSA threshold of 45 million. Search supplied the numbers. But the Commission designated the service as a whole, reasoning that ChatGPT’s ability to search the web makes it a hybrid service that qualifies as an online search engine. It also says it can investigate the functionalities behind ChatGPT and, where relevant, related systems. The designation therefore appears broader than a neat regulatory boundary around search results alone. That does not mean every ChatGPT answer has legally become a search result. It does not automatically make the OpenAI API, Codex or every other OpenAI product a VLOSE. Nor does it necessarily mean that every ChatGPT plan and function will be treated identically. The detailed designation decision has not yet been published, so the exact perimeter remains unclear. But the named service is ChatGPT, not merely its Search button. ## One product, two different logics This exposes something about ChatGPT that I had not fully accounted for. On one side, it is becoming **a mass-market information service**. It offers broad free or low-cost access, retrieves and synthesises public information, recommends options and increasingly occupies moments that previously belonged to conventional search engines. OpenAI is also developing advertising inside its Free and Go tiers. Ads have not yet been introduced generally across the European Union, but the commercial direction is visible: free access supported partly by advertising, with paid tiers remaining ad-free. On the other side, ChatGPT is **a paid professional tool**. Plus and Pro users pay for more capable personal use. Business and Enterprise customers treat it as part of their working environment, with organisational controls, connected sources and different contractual expectations. Search is available there too, but it is one capability within a much broader system. These are materially different product logics gathered under the same name and interface. One resembles a public information service funded by reach, subscriptions and potentially advertising. The other resembles professional infrastructure sold on capability, control and trust. The DSA designation did not create this structure. It has made the structure legally consequential. If the consumer information service and professional work environment genuinely form one hybrid service, regulatory scrutiny may reach across the shared systems behind them. If OpenAI considers them materially separate, it may increasingly need to define and defend that boundary. ## What has not happened Nothing in the designation says ChatGPT will be banned or stripped of features in Europe. A VPN is not a meaningful response to anything that has actually occurred. Organisations using ChatGPT have not suddenly acquired new DSA obligations either. The additional duties fall on OpenAI. Within four months, the company must comply with requirements concerning systemic risk assessment, mitigation, transparency and independent auditing. Much of that could remain behind the product. Some of it might eventually become visible. We cannot yet know. The important development is more fundamental. Europe is no longer treating ChatGPT solely as an AI system or a software tool. It is treating it as **information infrastructure with effects that need to be systematically accounted for** , including effects on minors, wellbeing, fundamental rights, political processes and public security. A few weeks ago, I wrote about how the AI Act changed while it was arriving. My conclusion was that understanding the technology increasingly requires understanding the regulatory machinery developing around it. This designation goes a step further. It has changed how I understand the product itself. Until yesterday, I saw search as an annex to the ChatGPT I actually use. Europe has effectively said that the annex is significant enough to determine the regulatory category of the building. We do not yet know what OpenAI will change, or whether European users will notice anything different in January. But I can no longer describe ChatGPT simply as a professional AI tool that happens to include search. It has become a hybrid of public information infrastructure and private working environment. That makes both the product and its regulation more difficult to separate into tidy parts.

A few weeks after I started experimenting with quantum computing, I came across an article in The Quantum Record about teaching quantum computing in high school. I know its founder, James Myers, and we had already exchanged thoughts about how prepared society is for quantum computing. A few weeks earlier, I suspect I would have considered the idea premature. My own picture had already started to change. I had first become interested in quantum computing through a Dutch machine that led me to write Quantum computing is more than qubits. Then I discovered that I could already write a quantum circuit on my laptop, simulate it and send it through the cloud to an actual quantum processor. That became You can already use a quantum computer. The machines were still experimental. My access to them wasn't. When I tell people that I've been spending time on quantum computing, especially younger people, I often get the same question: why? I have been wondering about that myself. Curiosity is part of the answer. Preparedness is another. My work involves trying to understand technological change before all its consequences are obvious, and quantum computing is beginning to feel close enough that ignoring it simply because I have no immediate use for it seems an odd choice. There is something slightly uncomfortable about that answer. I don't know whether I will ever need to program a quantum computer. I don't know how important quantum computing will become to my own work. But perhaps that is precisely what makes the question interesting. When do you start learning about a technology you don't yet need? Reading about education pushed that observation one step further. If people can already begin working with quantum computing, when should they begin learning about it? ## Starting early There is an obvious objection to teaching quantum computing in schools. We don't yet have broadly useful quantum computers. The technology is developing quickly, but much of what exists today remains research infrastructure. It seems reasonable to wait until we know what we are preparing students for. The Quantum Record article approaches the problem from the other direction. Students entering secondary education today will enter university and work while quantum computing is developing. Waiting for the technology to mature may therefore mean waiting too long to build the knowledge around it. That resonated with my own small experiment. I didn't need a useful quantum computer to learn something from it. Writing even simple circuits forced me to confront concepts quite different from classical programming. Simulation made those concepts tangible, while cloud access connected them to physical machines. The educational value had arrived before the practical value of the computer. ## Looking around Once I started paying attention, I also noticed that this discussion wasn't as hypothetical as I had assumed. I came across Peter Denteneer at Leiden University, whose work brought me into the Dutch discussion around quantum education. Leiden is also involved in a broader Talent & Learning Centre for quantum technology, bringing vocational, applied and university education together with companies. Then there is Amsterdam. QDNL Amsterdam connects researchers, entrepreneurs, students and the workforce, with education explicitly part of its mission. Its Quantum Experience includes the rather wonderful question of how you actually program a quantum computer. The University of Amsterdam and CWI have QuSoft, while this summer Amsterdam hosted QSim2026, an international conference bringing together researchers working on quantum simulation. Delft showed me another part of the picture. QuTech combines research and engineering around quantum computing and the quantum internet, surrounded by a growing group of specialist companies. Its Quantum Inspire platform is particularly interesting in this context because it gives people a route to gain experience with quantum computing and actual quantum hardware. I am only touching these worlds. That is partly the point. A subject I had filed away as distant research keeps becoming more tangible whenever I touch another part of it: software, hardware, education, research communities, companies and people already thinking about what knowledge will be needed. ## Preparedness I recognise something here from artificial intelligence. For years, preparing for AI could reasonably be treated as preparation for a future technology. Then the technology crossed an awkward boundary. Organisations suddenly needed people who understood what these systems could do, how to use them and how to reason about their consequences. Building that understanding proved slower than gaining access to the technology. Quantum computing may develop very differently. The comparison only goes so far. Yet it has made me more cautious about assuming that education should follow technological maturity. There is also a broader meaning of preparedness here. A country can invest in research facilities, companies and hardware, but its ability to make something of those investments eventually **depends on people**. Some will build quantum computers. Others will develop algorithms, teach, regulate, invest, procure or decide where the technology is useful. Most will never need to understand the physics in depth, just as most people working with computers today do not understand semiconductor physics. I don't yet know what quantum education should look like, how early it should begin, or whether the examples I am finding amount to anything like a coherent response. I have barely started looking. What has changed is my sense of when those questions become relevant. I had assumed we could wait for the computers. The people building the ecosystem clearly aren't waiting.

A client asked me whether an AI system that introduces itself as a virtual assistant is clear enough under the new rules. A fair question with a short answer, I assumed. Twenty minutes later we had six dates on the table and were disagreeing about which two of them still applied. The Act had entered into force two years earlier. Most of its provisions had become applicable three days before we spoke. Six days before that, the AI Omnibus had changed parts of the timetable. Some obligations were now in effect. Others had moved into 2027 and 2028. I could not answer his question without first sorting out the dates, and the dates turned out to be the more interesting problem. ## Several clocks European legislation rarely arrives through one decisive moment. A regulation is proposed, negotiated, adopted and published. It then enters into force. Individual provisions may become applicable later, sometimes across several dates. Standards, guidance and supervisory arrangements develop alongside all of that. The AI Act has been arriving through each of these stages for two years. DATE | WHAT HAPPENED ---|--- 1 August 2024 | The EU AI Act entered into force 2 February 2025 | Prohibited practices and AI literacy provisions began to apply 2 August 2025 | Governance rules and obligations for general-purpose AI models began to apply 27 July 2026 | The Digital Omnibus on AI, commonly called the AI Omnibus, entered into force and amended parts of the AI Act 2 August 2026 | Most remaining provisions became applicable, including the Article 50 transparency rules 2 December 2026 | New prohibitions added by the Omnibus begin to apply, and the transition for Article 50(2) marking ends 2 December 2027 | Revised date for high-risk systems in areas listed in Annex III 2 August 2028 | Revised date for high-risk AI embedded in regulated products 🗒️ The Article 50(2) transition is narrow and easy to misread. AI systems already on the market before 2 August 2026 have until 2 December 2026 to meet the marking and detection requirements for AI-generated content. Systems placed on the market from 2 August onwards comply immediately, with no transition at all. Two products can be technically identical and sit on different sides of that line. The rest of Article 50 keeps its original timetable. The Act became European law in 2024 and its obligations have been landing in stages ever since. The Omnibus changed some of those stages while the rest continued on schedule. This is why reports of the AI Act being delayed can be accurate in their detail and misleading overall. One procedural fact makes the point better than any commentary. A European regulation normally enters into force twenty days after publication. This one took three, and the legislator justified the compression as a matter of urgency, because the deadline it was amending was six days away. A delay that arrives after the thing it is delaying is not a delay. The timetable was tight enough that the correction had to overtake it. ## The change When I wrote about the wider Digital Omnibus package in November 2025, it was entering the European legislative process. The package contained two separate proposals. One covered data, cybersecurity and privacy rules. The other contained targeted amendments to the AI Act. That second proposal is now law as Regulation (EU) 2026/1744. The visible change concerns high-risk systems. Requirements for uses in employment, education, essential services and migration now apply from December 2027. Rules for AI embedded in regulated products, including machinery, toys and lifts, follow in August 2028. Those requirements had been expected in 2026, and their movement produced the headlines about delay. The rest is smaller. The Omnibus extended simplified requirements to small mid-cap companies, widened access to regulatory sandboxes, adjusted the AI literacy obligation, clarified the interaction between the AI Act and other European rules, expanded parts of the AI Office's oversight, and added prohibitions on systems generating non-consensual intimate imagery and child sexual abuse material. An organisation using a high-risk recruitment system now has more time to prepare. A provider covered by the transparency obligations in Article 50 does not. Both operate under the same Act, and the same week contained obligations that moved and obligations that arrived. ## Why it moved The official reason is readiness. High-risk requirements depend on harmonised standards, conformity procedures and competent authorities, and several of those were not going to exist in time. It is worth being precise about whose readiness. The Act set a timetable that assumed harmonised standards would be available by 2026. The bodies responsible for writing them did not deliver. The deferral is the regulator granting itself an extension and then passing the benefit to the regulated as relief. I do not think that is scandalous. I think it was close to inevitable, and what made it inevitable is the part worth looking at. The Act was proposed in April 2021, before general-purpose models were a public fact. The chapter governing them was added during the negotiations in 2023, because the ground moved while the text was being written. The Omnibus is the second time the technology has outrun the law, and the first time happened before the law was finished. These are capable people working in good faith. Nobody in Brussels in 2021 knew what the last three years would contain, and nobody now knows what the next three will. A legislature writing a five-year timetable for a technology with an eighteen-month horizon is making a promise it has no instrument to keep. The competitiveness argument sits on top of this and convinces me less than it convinces the Commission. What I have watched freeze European organisations is not stringency. It is indeterminacy. Nobody I work with stopped because the requirements were too strict. They stopped because there was a date and nothing concrete to build against, and an institution facing an unknown obligation with a known deadline does nothing at all. Which is also the strongest case against the extension. If indeterminacy was the problem, moving the date prolongs it. The extension only pays for itself if the standards actually arrive, so December 2027 is not the clock to watch. The standardisation work is. If that slips again, the date moves again, and after the second time nobody will plan against a European deadline at all. ## The machinery Passing a regulation and making it operational are different kinds of work. The legal text could be completed in 2024. Applying it requires standards, guidance, authorities, assessment procedures and organisations capable of interpreting their own responsibilities. The AI Act is an EU regulation, so its substantive rules apply directly across the Member States. Countries do not first have to convert them into separate national AI laws, as they would with a directive. The European Commission explains that distinction between the types of EU law. National institutions still organise much of the supervision, which leaves the law shared across the Union while parts of its operation remain national. For most organisations this machinery will be more tangible than the regulation itself. They meet it through procurement requirements, supplier documentation, internal governance, product reviews and questions from customers, which is where European rules stop being abstract and start touching everyday decisions. ## Two kinds of work Look again at what held its date and what did not. What arrived on 2 August is individual-facing. Tell people they are talking to a machine. Mark synthetic content. Disclose deepfakes. These protections matter and I am glad they are in force. What moved to 2027 and 2028 reaches further into organisations and markets: hiring, education, essential services, migration, safety components in regulated products. Those obligations depend more heavily on standards, procedures, authorities and organisations knowing what they are expected to build against. That difference has made me look at the Act differently. What I am beginning to see is that it is doing two kinds of work at once. Part of it establishes rules organisations should be able to build against: transparency requirements, conformity procedures, standards and responsibilities. That kind of regulation needs a degree of stability. Another part is trying to shape the European AI market itself. The AI Office, regulatory sandboxes, thresholds for general-purpose models, exemptions for smaller companies and the continuing simplification agenda all respond to an industry that is still changing quickly. Those two tasks tolerate change differently. A conformity regime becomes difficult to use if its requirements keep moving. Policy aimed at shaping an emerging industry becomes less useful if it cannot move when the industry does. Putting both inside the same regulation does not make the combination wrong. It does make the timetable unusually difficult to hold. Seen that way, July was more than a correction to a schedule. It exposed a tension inside the Act itself. That is a longer argument than this piece can hold, and I will come back to it. The immediate question is smaller and more useful. My client still needs to know whether an AI system introducing itself as a virtual assistant is sufficiently clear under Article 50. That answer exists, it is more specific than most of what has been written about the Act, and it is where the next article begins.

I spent an afternoon moving my professional work out of a personal ChatGPT account into a company workspace. Durable context, active projects, the writing that sits alongside the consulting. By the end it looked like a clean migration. Then a question surfaced that I have not been able to put down. Had I moved company knowledge into the company, or had I moved my own assistant into an account the company happens to control? ## What accumulates The question only became visible because the individual difference between ChatGPT Plus and Business has narrowed. Memory, projects, connectors, cross-chat context. The two environments are now close to interchangeable. The governance line is real and worth respecting, but it is a line about where the activity happens, not about what accumulates. And accumulation is the thing that now has become valuable. Not the model. The corrections, the recurring terminology, the preferences I no longer have to restate, the connections between one project and another. Work that used to require explaining myself now starts three steps in. That accumulation makes me more effective. My company benefits from a more effective me. It does not follow that my company has learned anything. That is the distinction I had been missing. The system can make my work faster and become unusually well adapted to me without making any of that adaptation useful to the person who comes after me. Individual effectiveness and organisational memory are not the same thing. 📖 ****The successor test**** If a person leaves tomorrow, can the organisation still use what was learned through their work? If the answer is no, the person became more capable. The organisation did not. ## Retrieval got cheap Google Workspace is the comparison I keep returning to, and the reason matters. A document in a shared drive survives its author. Someone leaves, the file stays, and whoever comes next can open it. The standard objection is that nobody ever does. Folders untouched for four years, three versions of the same policy, a naming convention abandoned halfway through. That objection was correct for as long as retrieval was expensive. Finding the right document among forty thousand was harder than asking a colleague or redoing the work, so people asked, or redid it, and the drive filled up with material that was present and unreachable. The volume was the problem. That changed recently enough that most organisations still run on the old instinct. Point a model at the same forty thousand files and the volume stops being a liability. It becomes a corpus. The messy half-finished document that nobody would have found is now something a question can reach. Which turns the old advice around. There is a Dutch expression, _wie schrijft, die blijft_. Whoever writes, remains. It used to be a reminder to keep minutes so your version of events survived the meeting. It now reads more literally. Write it down and it stays reachable. Leave it in your head, or in a chat window only you can open, and it goes when you do. Almost anything beats nothing. Bad documentation is a real cost, and outdated documentation is worse than none at all, because a model will retrieve a superseded policy with the same confidence it retrieves a current one. A human digging through a folder applies suspicion. Retrieval does not. So the guideline needs a condition attached: write it down, and mark when it stopped being true. With that condition, the successor test gets easier to pass, not harder. When the bookkeeper leaves I can reconstruct how the quarterly filing was handled, and I no longer have to know where to look. **ChatGPT Business does not pass that test at all.** The company owns the workspace, the seats and the tooling. What the system has learned about how the work is actually done sits inside a relationship between one employee and a model, and when the employee goes, so does the relationship. There is no folder to point anything at. ## Handover stops at the mailbox I am not going to design the thing that fixes this. But we already have a word for it, and it is not a new one. When someone leaves a company, they are asked to do a **handover**. Not a monitoring exercise. A recognised, slightly tedious task in the last two weeks, where the departing person makes their work transferable: where the files are, which client hates being called on Fridays, what was tried in 2023 and why it failed. Nobody thinks this is surveillance. Everyone accepts it as part of leaving. Handover already covers the mailbox, the shared drive, the CRM, the running projects. It does not cover the account where a meaningful share of the thinking now happens. That is the gap. Not a missing governance layer. A missing convention, whose analogue in every other work system is boring and settled. It also answers the privacy problem. A handover is performed by the person leaving. They decide what is worth passing on, which means they also decide what stays private, and the company gets the output rather than the archive. The half-formed questions evaporate. That is not in tension with writing everything down, and it is not in tension with deliberate deletion either. You throw away the conversation precisely because you have taken out of it the part worth keeping. The awkward version is the one that makes it interesting. Handover assumes a cooperative departure. People are also dismissed, and people also die. Companies already take possession of the work mailbox in those situations without much debate, because everyone accepts that the mail was the company's work. Whether the same holds for what a model has learned about how someone worked is a question nobody has had to answer yet. It is coming. The old version of this problem had a shape. Someone knew something useful, and the work was getting it out of their head and into a format a system could hold. I have watched that problem wear different names for thirty years. Content. Information architecture. Knowledge management. Intranets, wikis, enterprise search, SharePoint in all its configurations. What is new is that the head is no longer the only place the knowledge sits. Some of it now sits in a system, in a form that is already structured, already summarised, already close to transferable. That is a better starting position than any previous generation of this problem had. For now, the handover remains manual. Someone leaving still has to look back across the work and decide what another person will need. Perhaps that is not merely a limitation of the current tools. A company should be able to keep what it has learned without automatically keeping everything an employee said while learning it. The successor test turns out to have two parts: what should survive, and who gets to decide.

After sunset the planet casts a shadow on its own atmosphere. A band of deep blue rises in the east, and above it sits a strip of pink. Most people walk under it twice a day without looking up. The pink is not added. It is what remains once the blue has been scattered out of the light. That became the idea behind the new mark for this blog. ## Removal The mark is that band, turned into a simple form. A shallow arch cuts a field in two, pink above, blue below, held apart by a line of paper. The pink appears through removal. Take one thing away and another becomes visible. That felt right for the work as well. Much of what I do, in writing and in consultancy, has that shape. You clear noise, reduce confusion, and the thing that matters comes forward. The form arrived quickly. What it had to do took longer to understand. ## Family Schmuki, the AI consultancy we run, uses the same grammar in a different shape. There it becomes a disc. On the blog it becomes a rounded triangle, which reads closer to an eye once the paper gap opens it up. Same grammar, different voice. That mattered because the two were already connected in practice. Schmuki works in Dutch, with organisations trying to get AI to land somewhere real. Hoeijmakers.net is where I think out loud in English, more freely and more personally. Clients read what I write here. The writing shapes the work, and the work feeds the writing. That relationship existed in my head, though nowhere else. No wordmark bridges Dutch and English. A shape does. A shared visual grammar solved something language could not. It gave the two identities a family resemblance while leaving each of them room to be itself. Browser tabs with the Brand Marks ## Matrix I had an identity. What I did not have was an online identity, which is a different object. A mark online is never one drawing. It is a matrix, and every axis multiplies the last. Size, background, light mode, dark mode, vector where possible, raster where necessary, sharp at sixteen pixels and still right at hero size. Then come the crops decided by platforms that will never consult you: square, circle, tab, chip, profile image, preview card. The same drawing does not survive all of that. Below a certain size the disc has to grow, the arch has to flatten and the gap has to widen, or the whole thing turns to mud. The mark has to be redrawn in order to look identical. Transparency needs a ruling too. I chose to keep the band inside the mark as opaque paper, so no background and no photograph ever shows through. One decision, and it then has to hold in every file that exists. Hoeijmakers.net, the systematic approach of the Brand Marks. ## Continuity Making the shape was the first half, and the shorter one. The second half was systematic treatment. Claude helped me work through dozens of variants: the arch raised, lowered, flattened, sharper, softer, point up, point down, versions I liked for a day and then abandoned. More importantly, it helped me turn a mark into a system. Every few days another slot appeared that had not been on the list. The banking app wanted a square. WhatsApp cropped tighter than I expected. An LLM showed me as a small round chip beside a citation. I had not planned for that one either. Once the core idea was there, Claude could keep going. It could help think through implementations, generate versions, check consistency, and keep extending the logic into places I would have stopped. The design did not need a flash of inspiration by that point. It needed continuity. The meaning stayed mine. The judgement stayed mine. Claude changed how far I could carry the idea into the details. ## Room What I did not expect was what finishing this would clear. An unfinished site is a quiet excuse, and I had been using it for longer than I would like to admit. When the identity is unresolved, everything around it feels provisional as well. You hesitate over the next step because the frame itself still feels temporary. Now the frame is built. The two properties know how they relate. The mark appears correctly in places I do not control. The system exists. That does not matter for its own sake. It matters because it returns my attention to the writing. Pieces I had postponed because the house was not in order have lost that excuse. The mark began with what remains when blue light is taken away. Building it had a similar effect. It cleared more space than I expected. For the first time in years, the blog feels less like something I maintain and more like somewhere I want to write.

A social media post put Jean Piaget in front of me this week. I knew the name from education. I could not have said what a genetic epistemologist actually did. So I asked. Then I kept asking. Somewhere in that conversation, a sentence appeared that I have not been able to put down: > **LLMs predict language. Humans construct meaning.** I want to be honest about where that sentence came from. It emerged from an exchange with a machine, about a thinker I did not know, in a field I had not studied. The language arrived faster than I could absorb it: Piaget, constructivism, assimilation, accommodation, all within seconds. I could have stopped there with a page of fluent text and the feeling that I had learned something. The gap between language arriving and anything changing in me is the **meaning lag**. ## Knowledge forms Piaget spent much of his career asking how knowledge comes into being. That is close to the plain meaning of _genetic epistemology_ : genetic in the sense of genesis or development, epistemology as the study of knowledge. He studied how knowledge forms. His answer was that we interpret new experience through structures we already possess. He called that assimilation. When experience will no longer fit, the structure itself has to change. He called that accommodation. Understanding develops through the movement between the two. The example that stayed with me is a child who calls every four-legged animal a dog. Then a cat appears. The child can keep stretching the word, or reorganise the categories behind it. The new label matters less than the change in the structure underneath. I was doing the same while writing this piece. Most of the process was assimilation: fitting Piaget into what I already believed. A smaller part was accommodation. That part was slower and less comfortable, and it is the reason this piece exists. This sits close to a thread I have followed through **Bildung** : education as formation rather than the transfer of information. The traditions are different, but both direct attention towards what changes in the learner. ## Meaning lag Generating language has become cheap. Constructing meaning has not. That is the asymmetry. A model can explain, exemplify, translate and counter-argue, then do it again without tiring. The learner still has to connect the explanation to prior knowledge, notice where it conflicts, decide which distinctions matter, and revise their picture of the subject. Knowledge is not downloaded. Knowledge is constructed. An answer can be complete while my thinking remains exactly where it started. The meaning lag is not a defect in the tool. It is the shape of the work that is left. I wrote last year that search is moving from finding towards understanding. I still think conversational systems help us stay with a subject. What I had to give up is the assumption that staying with a subject is the same as being changed by it. Assimilation would have let me keep the sentence intact. ## Open questions The first concerns the systems I help build. A chatbot can answer every question smoothly and still be a poor learning environment. A plausible answer can end the exchange instead of opening it. What would it take to build a system that invites someone to formulate, test, compare and revise? Something I noticed while working with schools: the questions people type often arrive at the moment their existing understanding stops covering the situation. That is close to the boundary Piaget was describing. I can see the friction. I cannot yet see whether anything reorganised afterwards. The second concerns evidence. Education has long treated written production as proof that the intellectual work happened. That proxy is weakening. I find myself less interested in whether someone used AI than in what changed in their understanding. I cannot yet say what reliable evidence of that change looks like. Revision, explanation, judgement, the ability to notice when a convincing answer rests on a weak idea: all seem relevant. None is sufficient on its own. ## Patience I wrote once that not doing is also an act. Slowing down is not falling behind. At the time it was a working habit, a way of surviving abundance. Piaget gives it a reason. **The delay is not a preference. It is the time it takes for a structure to change.** Language can be generated almost instantly. Understanding still takes time. The model can finish the sentence. The learner still has to change.

I came across IBM’s Qiskit almost by accident. After publishing Quantum computing is more than qubits⁠, I wanted to understand what the software layer around quantum computing actually looked like. I expected documentation, research papers and a few experimental tools. Instead, I found a development environment that anyone can download and begin exploring. Within an afternoon, I was reading about writing quantum circuits, simulating them on a laptop and submitting them through the cloud to a real quantum processor. Until then, I had never seriously considered that I might write a quantum program myself. The possibility had simply never entered my picture of where the technology stood. ## The ecosystem Like many people working in digital technology, I had quietly assumed that quantum computing remained largely confined to research laboratories. Progress was happening, but practical engagement still seemed to belong to universities and a small group of technology companies. The hardware remains experimental, while much of the surrounding software is already available. IBM’s Qiskit, Google’s Cirq, Microsoft’s Quantum Development Kit and several other frameworks give developers the tools to construct quantum circuits, test them and explore how quantum computation differs from classical computing. Many of these tools are open source, which means the first steps require curiosity and time rather than access to a specialised machine. The software ecosystem is therefore developing ahead of mature hardware. We have seen that pattern elsewhere in computing, although I had not expected to encounter it here so soon. ## Simulation What surprised me most was the role of simulation. I had assumed that a simulator was mainly a temporary substitute, useful while real quantum computers remained scarce. In practice, simulation is part of the normal development process. A quantum circuit can first be executed mathematically on an ordinary computer. This allows the programmer to inspect the circuit, test the reasoning behind it and see how an ideal quantum system would behave. Only afterwards does the circuit need to be adapted to the architecture and limitations of a particular processor. The move to real hardware is therefore less like leaving theory behind and more like introducing physical reality into an already working model. The mathematics stays the same. The conditions under which it is executed become far less forgiving. ## Reality Today’s quantum computers perform genuine quantum operations, but they remain noisy and constrained machines. Qubits lose coherence, gates introduce errors and measurements are imperfect. A circuit that behaves cleanly in a simulator may produce a much less orderly result when executed on physical hardware. For many small experiments, simulation is faster and more reliable. The value of the real machine lies in showing what the current hardware can actually reproduce, with all its architectural limits and physical imperfections. Cloud access makes this surprisingly tangible. IBM, Microsoft and Amazon all provide routes for submitting quantum programs to real processors. The machine itself may be operating in a specialised laboratory under extreme physical conditions, yet from the programmer’s perspective it appears as another computing resource reached through an online platform. ## Early access What changed for me was the sense of distance. Quantum computing still has a long way to go before it becomes broadly useful, but engagement with it no longer belongs entirely to a future generation of machines. The programming tools, simulators, learning environments and cloud platforms are already taking shape. We often imagine that a new computing platform arrives when its hardware becomes useful. Quantum computing appears to be arriving more gradually, through software and experimentation, while the machines themselves are still learning how to carry the load.

Over the past few weeks I've found myself circling around the same question from several different directions. One day I was reading Cory Doctorow's argument that AI is becoming one of the largest speculative bubbles in history. A few days later Azeem Azhar argued almost the opposite: that increasingly capable open models could strengthen the business case for the companies building AI infrastructure rather than weaken it. Around the same time I was having much more practical conversations about AI subscriptions, APIs and why intelligence itself seems to be getting cheaper while many AI services still feel expensive. None of those discussions seemed directly connected. Yet the longer I sat with them, the more I wondered whether they were all describing different parts of the same story. This isn't an attempt to predict stock prices or tell anyone where to invest. Others are much better equipped to do that. What interests me is something slightly different. AI is increasingly discussed in terms of winners and losers, bubbles and breakthroughs, but I suspect we're still struggling to describe what we're actually looking at. Before deciding who will profit, it helps to understand what kind of economy is emerging in the first place. ## Looking at different layers One phrase I've started to question is _AI company_. We use it almost without thinking, but it quickly becomes slippery. Nvidia is an AI company. So is OpenAI. Anthropic is one. Microsoft increasingly presents itself as one. Yet they are fundamentally different businesses. One designs chips, another trains frontier models, another rents out vast amounts of compute, while countless others simply build useful products on top of those foundations. Schmuki is also part of that wider AI economy, but in a completely different sense. We don't train models or build data centres. We help organisations understand and apply them. The more I think about it, the less useful the label becomes. It compresses very different economic realities into a single category and, once we've done that, it becomes surprisingly easy to talk past one another. ⁉️ ****Beneath all the headlines, I suspect most people are simply trying to answer three questions:**** • Is AI real, or another bubble? • Why are companies investing hundreds of billions? • And where will the value ultimately end up? ## A familiar historical pattern The same applies to the bubble discussion. History suggests that speculative investment and genuine technological transformation are not opposites. They often arrive together. Railways attracted extraordinary amounts of capital long before the network reached maturity. Electricity required decades of investment before it reshaped industry and everyday life. The commercial internet experienced its own boom and crash, yet few would argue today that it was ultimately overestimated. Investors can lose money while society gains an entirely new infrastructure. That doesn't prove AI will follow the same path. History never repeats itself that neatly. But it does suggest that asking whether something is "a bubble" may be too narrow a lens through which to view a technology that could take decades to unfold. ## Where does the value go? One idea I keep returning to is that we often assume value has to stay in one place. If model providers face increasing competition and prices come down, someone must be losing. Perhaps. But another possibility is that value simply moves. Cheaper models make new applications viable. New applications create new demand. More demand requires more inference, more compute, more networking, more storage and, ultimately, more electricity. Pressure on one layer of the market can strengthen another. At the same time entirely new products, services and businesses become possible, just as previous waves of infrastructure created opportunities that were difficult to imagine beforehand. The AI economy may not simply become more efficient. It may become larger. ## Questions rather than conclusions There is one aspect that does seem different to me. The early internet was remarkably open. Starting a website or running a server required relatively modest resources. Frontier AI currently appears much more concentrated. Training the largest models demands enormous amounts of capital, specialised hardware and access to energy. Whether that concentration proves temporary or becomes a defining feature of the coming decades is one of the questions I find most interesting. Open-weight models point in one direction. The economics of scale point in another. I don't think anyone genuinely knows where the balance will settle. Perhaps that's why I've become less interested in declaring AI either a bubble or a revolution. It may turn out to be both, in different ways and at different layers. What I find more useful is stepping back from the daily headlines and trying to draw a better map. Not because it allows us to predict the future, but because it reminds us that we're looking at a landscape that is still taking shape. We know enough to recognise that **AI is becoming a new layer of infrastructure**. We know far less about where the long-term value will settle, which architectures will endure, or how today's concentration of power will evolve. For now, that uncertainty doesn't feel like a weakness. It feels like an honest place to begin the conversation. * * * **Related reading, if the AI economy piece resonated with you:** Compute Is the Entry Ticket, Not the Game This one picks up directly where the "different layers" argument leaves off. If the AI economy piece asks what kind of businesses actually make up "AI," this piece follows one layer specifically, compute, and traces the chain from raw infrastructure through energy to real demand. It's the natural next step for the reader wondering "okay, but which layer actually captures the value?" A Serious European Bet on AI Compute The AI economy piece flags capital concentration as the one place where this wave looks genuinely different from the open early internet. This article grounds that abstract worry in a concrete case, Rotterdam's proposed AI campus, and pushes on the distinction between where infrastructure sits and who actually controls it. Good for readers who want the concentration question made tangible rather than theoretical. Quantum Computing Is More Than Qubits Less a direct continuation, more a sibling piece. The same instinct, resisting a tidy narrative about an emerging technology before we've actually understood what's being built, gets applied here to a different infrastructure story entirely. Useful if what drew you in was the "we're still mapping this, not predicting it" stance rather than AI specifically.

The Euler diagram of European trade and institutional agreements, the one untangling EU, EEA, EFTA, Schengen, the eurozone and the customs union, went further than I expected. Close to two hundred thousand views on LinkedIn. At that size, a post stops being just a post. It becomes something closer to a temperature gauge, a rough read of what a few hundred thousand people actually think when the subject is AI. And the reading ran hot. The most common response was not about the diagram itself. When my piece on Fable 5 explained how it got made, in one pass, after ChatGPT spent twenty turns on it and Claude Opus produced confident errors, a chorus formed in the comments. Not everyone. A vocal slice of the replies, and they weren't gentle: why do you need AI for that, you're wasting water, don't you have a brain, you stupid fuck, go do it yourself. Nobody claimed the diagram was wrong. The objection was that I was not entitled to make it this way. ## Two things are happening at once The tone is worth separating from the argument, because they're doing different work. The harshness is personal: some people clearly need somewhere to put a general anxiety about AI, and a stranger's viral post is a convenient place to put it. That's a psychological release valve, not a policy position, and I don't think it deserves more analysis than that. But underneath the anger was an actual claim, made politely by some and violently by others: that power should be rationed by task, that a frontier model is wasted, even illegitimate, on something "simple." Strip the emotion away and what's left is a form of licensing. Not issued by any authority, just enforced by a crowd. Which raises the question nobody quite asked out loud: should there be an actual authority for this? ## A third objection, quieter than the other two Some replies weren't about desert at all. They raised something more technical: that matching the right model to the right task is genuinely hard, because most people have no real feel for what's in their hands. Fable alone comes with effort dials, low, high, extra high, max, sometimes a choice of model entirely. Someone picked a setting, it happened to solve six overlapping frameworks in one pass. But could they have predicted that in advance? Could most users say why "high" succeeds where "low" fails, or tell confident-and-wrong apart from quietly-right? That's not entitlement, it's closer to a literacy gap. The AI Act's Article 4 already names this, an AI literacy duty, aimed at organisations. This version of the objection is really asking whether individuals need the same thing: not permission to use the tool, but some minimum understanding of what the dials actually do. It's the one objection in the pile that survives contact with scrutiny. ## License the person, or license the maker Here's the split that matters, and it cuts through most of the history of technology regulation in one line: you can license the operator, or you can license the provider. Almost never both. **License the operator** when the tool can hurt other people in untrained hands. Steam boilers exploded often enough in the nineteenth century that countries began certifying stationary engineers. Cars gave us the driving licence. Ham radio requires an exam. Pesticides require an applicator certificate. Drones, a consumer product you can buy at a media store, now come with EU competence certificates sorted by weight class. In every case, the danger sits with a third party: a factory floor, a pedestrian, an unlicensed frequency, a poisoned field. And a driving licence isn't just permission, it certifies you can read the dashboard. That's the thread connecting this tradition back to the literacy objection above. **License the provider** when the danger sits upstream instead. Electricity, computing, the internet, medicine: nobody holds a licence to own a laptop or take a prescribed pill. The obligations sit on the utility, the platform, the manufacturer, the pharmacy. The user is simply trusted, or ignored. The AI Act is unambiguous about which side it picked. Obligations land on providers and deployers, sorted by the risk of the use case, never on the individual for personal use. Article 4 comes closest, an AI literacy duty, but it's a duty on organisations, not a licence on a person. Brussels, of all regulators, looked at the most powerful general-purpose technology of the decade and put the licence on the maker, not the hand on the keyboard. ## Why the crowd was still wrong That choice tracks the historical pattern precisely. Operator licences exist where misuse harms someone else. My diagram harmed nobody. What the angriest commenters were demanding, whether they'd have put it this way or not, was operator licensing for a case that has always, historically, sat on the provider side of the line. There's no tradition of licensing people against wasting a tool's potential, only against hurting others with it. The irony is that real gatekeeping for AI already exists, just at the provider level. The export controls that briefly took Fable 5 offline were decided in Washington and executed by Anthropic; a switch thrown at the level of states and companies, nowhere near the level of one person and one task. Access to models is regulated. Just never at the level my loudest critics were operating on. Maybe that's the cleanest way to hold the whole episode. The formal system asks: can this technology harm someone else? The informal one, running hot in a comment section, asks: does this person deserve this much power? Europe built its entire AI framework on the first question. Some of my replies were entirely stuck on the second. A few, the quieter ones, were asking a third question worth taking seriously: does this person even know what they're holding?

Six categories on one map of Europe. EU, EEA, EFTA, Schengen, the eurozone, the customs union. They nest, they overlap, and they refuse to line up. EFTA sits partly inside the EEA and partly outside it. Switzerland belongs to some and not others. The diagram is not a drawing problem. It is a set-logic problem wearing a drawing's clothes, and every edge has to agree. I chased one clean version of it for a while. ChatGPT went at it for twenty turns, admitted halfway through that this was about overlap logic and not image generation, changed approach, and still got the memberships wrong. Claude Opus, at its highest effort, had no idea where it stood and did not say so. It produced confident diagrams with quiet errors and left me to find them. Fable 5 corrected the whole thing in one pass. It placed the nestings correctly, flagged the two or three points where a design choice had to be made rather than a fact looked up, and left me with minor aesthetic tweaks. It understood what kind of problem it was. The very complex overview of European agreements Then I noticed what it had done to the rest of my day. ## One pool My subscription is one pool of usage. Every model drinks from it. Sonnet for the quick work, Opus for the harder thinking, and now Fable for the problems that defeat both. What Fable changed is the rate. Fable is a heavy model. It draws down the pool faster than the others, roughly twice as fast as Opus for the same task. So the map did not cost me an hour of Fable. It cost me an hour of Fable and a chunk of everything else I might have done in that stretch. Nothing about the plan is different for Fable. It uses the same shared usage as every model. It just drinks more of it. ## The meter When the pool runs dry, the work does not stop. It tips into pay-per-use, the overage that runs quietly in the background on my plan. This is not a Fable thing either. Any model does it once you pass the limit. But here the weight shows up a second time. Fable stacks up more tokens per task, each one billed, so the same job that felt heavy inside the plan runs up a bigger number outside it. Same door, heavier toll. So the whole story is weight, in two places. It pulls the wall closer, and it makes the far side of the wall cost more. No special mechanism. Just a model substantial enough that you feel it coming and going. The metering puzzle ## The shape Which is a small shift in what a subscription feels like. The flat plan told you to stop counting, and a light model let you forget the pool had a bottom. Fable, by being both worth reaching for and costly to run, put the counting back. Not through a new rule, through plain capability. The best model I have is the one that made the meter visible. I do not mind paying for it. The diagram was worth every drop it took. But I use Fable differently now than in the first week, more deliberately, a little more sparingly, the way you treat anything you have been reminded is not free. The strongest tool on the shelf is also the one I have started to save. 💡 Every model on the plan shares the same usage. Fable is heavier: it uses that shared usage faster, and if you keep working past the limit on pay-per-use, it costs more per task than the lighter models.

## The name, then the thing Vanta had already come up that week, in a conversation about getting an ISO certificate in place for one of the platforms we work with. Someone was comparing options, weighing a self-hosted approach against handing the evidence-gathering to a vendor built for it. I looked Vanta up myself during that call, mostly out of curiosity. A few days later I opened the Fireflies trust page and found the same name running it. Not a new discovery, the second time. A name getting a face. What struck me in that earlier conversation, more than the tooling itself, was the actual reason for leaning toward a platform like Vanta. Not the badge. The auditor's side of the exchange: when an auditor already knows the platform, the audit moves faster, because they don't have to learn a new system before they can even start checking yours. The certificate isn't just proof for the buyer. It's a shared format that makes the checking itself cheaper for everyone in the chain. ## Continuous, not annual Most compliance used to work like a school inspection. Once a year, someone shows up, checks the files, signs off, leaves. Everything between visits is unverified. Vanta replaces that with something closer to a **smoke detector** : hundreds of automated tests running against a company's actual systems, hourly, asking whether multi-factor authentication is still enforced, whether an ex-employee's access was actually revoked, whether encryption is configured the way the policy says it should be. That shift, from snapshot to continuous, is the real product. SOC 2 Type II already pointed in this direction before Vanta existed, since it certifies conduct over a period rather than a single afternoon. What Vanta adds is the machinery to keep that period running indefinitely, instead of resetting to zero between audits. ## What it doesn't do Here is where I had to correct myself. Vanta doesn't make a company trustworthy. It makes a company's evidence collection faster and its disclosure continuous. Those are not the same thing. The checks are about configuration: is the lock installed, is the alarm armed. They say nothing about whether the lock is the right lock for what's behind the door. A SOC 2 Type II badge means the same thing whether it sits on a tool handling marketing copy or one handling patient data, and the judgment about which of those is adequate for which situation is still entirely a human one. Vision, judgement and creativity stay decisive precisely where automation gets thorough, and adequacy-for-context is exactly that kind of judgment. There's an irony in where Vanta itself came from. It was built during a stretch of high-profile breaches, when annual audits had visibly failed to catch what mattered between visits. The company that exists to make trust continuous was a direct response to trust that had been treated as a snapshot for too long. ## Complexity pushed upstream This fits a pattern I keep running into elsewhere. Frameworks like ISO 42001 work the same way, pushing the burden of proof onto vendors so that buyers don't have to inspect every supplier's internals themselves. Compliance automation does this at industrial scale. A small company with a Vanta subscription can produce the same continuous evidence trail as a much larger one, which is good for buyers who'd otherwise have no way to check, and good for smaller vendors who'd otherwise never get past procurement. But pushing complexity upstream only works if someone downstream still asks whether the evidence answers the actual question. A green checkmark tells you a control passed. It doesn't tell you whether that control was the one that mattered for your situation, and a platform built to automate proof has no mechanism for asking that question on your behalf. ## The open question What happens once everyone runs the same automated proof through the same handful of platforms. If every vendor in a category holds the same SOC 2 badge, generated the same way, the badge stops telling buyers anything about who's better. It just tells them who's still in the room. That's not a flaw in Vanta. It's what happens to any signal once it becomes cheap enough for everyone to hold. 🔐 Vanta and similar platforms (Drata, Secureframe) run hundreds of automated tests against live systems, hourly. The output is continuous evidence, not a one-time certificate. ### Further reading * How safe is that, actually

A vendor I had vouched for was challenged twice in one week. My answer was thinner than I liked, so I built a way to climb past habit into evidence. Someone I work with asked how safe Fireflies actually is. It did not land as a question. It landed as a sneer. A few days later, in a privacy meeting, someone else started poking at the same tool. I had vouched for it both times. And both times, my answer amounted to: it’s fine, I use it, I trust it. That is not an answer. It is a habit. ## The five layers Most vendor trust sits on a ladder nobody climbs unless pushed. At the bottom is marketing language: badges, reassurances, and the claims a company puts on its own homepage. One step up are named frameworks, stated but not shown: “SOC 2 compliant”, “GDPR ready”, “enterprise grade”. A step further are public artefacts you can actually read yourself: a dated data processing agreement, a subprocessors list, a public trust page. Above that is evidence gated behind an NDA: the actual audit report, available only inside a formal relationship. And at the top is what you find by probing: a pointed question to support, an independent scan, a breach history search, or anything else the vendor does not fully control. Most of us, including people who care about security, stop too low on that ladder. Not because the higher layers are impossible to reach, but because checking feels disproportionate in an ordinary vendor relationship. Until it suddenly does not. ## What was actually there So I went and looked. Fireflies has a public trust page, a dated data processing agreement, and a subprocessors list. Those documents sit in the open, readable without asking anyone’s permission. The actual SOC 2 report sits behind a mutual NDA, which tells you something interesting in itself: the strongest evidence is the one thing you do not get to inspect directly. You get confirmation that evidence exists. You do not automatically get the evidence itself. That is not a complaint. It is how most credentialing works, for vendors and for people. A diploma works the same way. You do not see the exam. You see the institution’s claim that the exam was passed, and you trust the institution because checking universities one by one is not something most of us do either. The interesting question was never whether Fireflies has flaws. Every vendor has flaws. The question is whether the certifications attached to it are doing the work people assume they are doing, or whether they are simply standing in for that work. ## A scale, not a snapshot The instinct, once you start checking, is to treat the result as a one-time pass or fail. That is the wrong model. A **SOC 2 Type II report** already points to a better one. It does not certify a single state on a single afternoon. It looks at behaviour over a period: months of controls, processes, and consistency. The honest version of trust looks more like a scale that needs rechecking than a stamp that lasts. There is a Dutch saying that captures the asymmetry better than any framework: "_vertrouwen komt te voet en gaat te paard"_. Trust arrives on foot and leaves on horseback. It builds slowly, through small consistent acts. And it can disappear in one bad afternoon. That asymmetry is the real argument for climbing the ladder before something forces you to, not after. I have seen the same dynamic from the inside, setting up a verified sender badge years ago. The badge was not really the achievement. The waiting list, certificate, DNS validation, and process behind it were. The badge was just the part anyone else could see. ## What the sting was worth What changed was not my opinion of Fireflies. I still use it. What changed is that I now have an actual answer when someone pokes at it: an answer built from documents, dates, and evidence layers rather than from how the product has felt to use. Disclosure of this kind is its own small genre. A company says: here is what we built, here is what you should know, here is what we are willing to show. The reader then has to decide whether that is enough. The sting was not the challenge. It was realising how thin my own answer had been until someone made me defend it. 💡 SOC 2 Type II audits behaviour over a period, typically 3 to 12 months, rather than a single point in time. That distinction is doing more work than the badge usually gets credit for. ### Further reading * Exploring ISO 42001 and AI governance

I went back into Cloudflare's AI Crawl Control dashboard to check on bot traffic, the way I do most weeks now, and found a new tab: Optimization. Tucked inside it, a single line: "Check your site." A link to a tool I hadn't seen before, on its own domain: isitagentready.com. ## A scanner, not a vibe check It is a scanner. You give it a URL, it checks the site against a growing list of emerging standards for how AI agents discover and use websites, and it returns a score and a level, from "Basic Web Presence" up to "Agent-Native." Five categories: Discoverability, Content Accessibility, Bot Access Control, API/Auth/MCP/Skill Discovery, and Commerce. What's interesting is what's actually inside each category. This isn't a vague "AI readiness" score built on vibes. It checks for robots.txt rules and sitemaps, yes, but also for Markdown content negotiation, MCP server cards, OAuth discovery, Agent Skills, Web Bot Auth, and commerce protocols like x402 that almost nobody has heard of yet. Most of these aren't formal standards. Several are proposals still finding their feet. The scanner doesn't pretend otherwise, but it treats them as real enough to measure, which is itself a useful signal about where things are heading. ## Reachable, not just built Running it on my own blog turned up something I'd missed. I'd already built Markdown output for AI agents months ago, a `/{slug}.md` route that serves clean Markdown instead of HTML. The scanner pointed out that this only helps an agent that already knows the convention exists. An agent that simply does correct HTTP, sending `Accept: text/markdown` on the normal page URL, got HTML back regardless. The fix was small: one check at the top of the request handler, routing negotiated requests into the Markdown rendering that already existed. The expensive part, parsing the page into clean Markdown, had been built once. Making it reachable a second way cost almost nothing. That's the pattern worth taking from this, more than the score itself. Most of the categories the scanner checks aren't about building new things. They're about making capabilities you already have reachable through the channel an agent actually uses, rather than the one you assumed it would use. 💡 I wrote earlier about why Markdown keeps winning as the format AI systems converge on, in Markdown, the WD-40 of Digital Information. The scanner's content negotiation check is that argument turned into something measurable. ## Built for the other window The tool has a second feature that matters more than the score: a button that generates a full set of fix instructions, written to be copied straight into a coding agent. Not a checklist for a human to interpret and translate into code, but instructions a coding agent can act on directly. That's a small detail, easy to miss, but it says something about who this is actually built for. Not developers researching a topic. Developers who will hand the output straight to whatever Claude or Cursor or Copilot is already open in the other window. Five categories, most sites starting near zero. Worth ten minutes to see where yours lands.

At WWDC26, LM Studio showed four Mac Studios daisy-chained together, 2TB of unified memory, running massive local language models. Someone pulled out an iPhone and chatted with those models over a secure private connection. The crowd loved it. Someone on Threads estimated the setup at €60,000. The image stuck with me. Not because I want one. Because it crystallises exactly what “AI independence” would actually take. LM Studio running massive local models on 4 connected Macs. ## Digging your own well There is a type of person who, when the tap water discussion comes up, starts calculating what it would cost to drill a well. They are not wrong to think about it. Understanding the alternative clarifies how dependent you are on the infrastructure you take for granted. But most of them do not actually dig the well. The €60,000 Mac Studio stack is the AI version of that calculation. It is useful to make it. It sharpens the mind. So let us make it properly. ## What €60,000 buys Four Mac Studio Ultra units, Thunderbolt interconnects, storage. The hardware enables models in the 400 billion parameter range, open-weight models from families like Llama, DeepSeek, Qwen, or Mistral. These are genuinely capable. On most benchmarks, the best open-weight models now trail the frontier by roughly three months, which is a smaller gap than it was a year ago. You would run them through a harness: LM Studio itself, or Ollama, or vLLM for more production-oriented setups. These are the tools that wrap the model and make it usable, the software layer between raw weights and actual conversation. The models themselves come from Hugging Face, updated by the research community, available to anyone with the hardware to run them. The electricity costs are real but not dramatic. Four Mac Studios under sustained load draw around 600 watts. At Dutch rates, heavy daily use comes to roughly €150 to €200 per month. Not nothing, but not a data centre either. ## What €60,000 does not buy This is the part the photo does not show. The model is the motor. What you experience when you use Claude, or GPT, or Gemini is not just a motor. It is the motor plus years of post-training: the instruction following, the safety calibration, the careful shaping of how the model behaves. It is infrastructure: context windows, retrieval, memory, tool integrations, the ability to search the web or read a file. It is the application layer: specialised tools like Claude Code, built on top of the model for specific workflows. And it is continuous improvement. The motor gets upgraded. Your local setup does not, unless you download and validate a new several-hundred-gigabyte file yourself. There is also the question of what open-weight models actually run on that 2TB stack. Not Claude. Not GPT-5. The open-weight frontier is impressive and improving fast, but compute at this scale is still concentrated where the training happened, not where the weights ended up. ## The ongoing cost Write-offs over three to four years. Hardware that depreciates while the field moves. Security patches, model updates, inference bugs, monitoring. You become your own IT department. Every improvement in the wider ecosystem requires your active decision to adopt it. The well metaphor extends further than it first appears. You drill it, you maintain the pump, you test the water quality yourself. Meanwhile the municipal supply quietly improves its filtration, upgrades the pressure, and starts offering mineral variants. Your independence is real. So is the maintenance contract you signed with yourself. 💡 The open-weight model gap is closing. Epoch AI estimates the best open-source models now trail frontier proprietary models by roughly three months on average. That still matters for complex reasoning and multimodal tasks. For many workloads, it does not matter at all. ## The useful question None of this means local AI has no place. For specific workloads where privacy is structural, where data cannot leave the building, where latency matters at a level cloud APIs cannot guarantee, the calculation looks different. The ICC left Microsoft 365 for exactly this kind of reasoning. Sovereignty is sometimes worth the cost. But “worth the cost” requires knowing what the cost actually is. Not just the hardware invoice. The harness work, the maintenance, the gap between what you are running and what the field has moved to by the time you have your well operational. The €60,000 photo is a useful provocation. It makes the abstraction concrete. AI independence is not a setting you enable. It is an infrastructure decision with a full cost of ownership, a capability ceiling, and a recurring obligation to keep digging. Most people will choose the tap. That is a reasonable choice, as long as it is a conscious one.

I bought an international train ticket last week and added it to the railway app. The process took about thirty seconds. Nothing asked for my name. Nothing verified who I was. The ticket sat there, ready for a journey I haven't made yet, and I'm reasonably confident it will work fine when I hold the phone to the scanner at the platform. That small moment bothered me in a productive way. The app could just as easily have been a wallet. Buy a concert ticket and it lands in Apple Wallet or Google Wallet the same way, no identity attached. The container changes. The principle doesn't. ## Two models There are two fundamentally different ways a system can decide whether to let you in. The first is **account-based**. You are registered. The system knows who you are. Access is granted because your identity has been verified and associated with a right. A transit card linked to your name works this way. So does your bank account, your email, your government login. The credential belongs to you specifically. Lose it, and it can be blocked. Transfer it, and the transfer can be traced or refused. The second is **possession-based**. The system doesn't know who you are and doesn't need to. Access is granted because you hold something. A physical key. A fifty euro note. A paper ticket with a punched hole. The right travels with the object, not with the person. The word for this second model is bearer. Whoever bears the token gets in. 🎫 ****Bearer**** is a legal and technical term for an instrument that grants rights to whoever holds it, without verifying identity. A banknote is a bearer instrument. So is an API key. The opposite is a registered or identity-bound instrument, where the right belongs to a named holder. ## The default that was For most of human history, possession-based access was simply the only option. Institutions didn't have the infrastructure to track individuals at scale. Cash worked because it had to. The paper train ticket worked the same way. When the conductor came through the carriage and punched a hole in your ticket, they were doing two things: confirming validity and preventing reuse. The ticket changed physically. It was spent. The system was elegant precisely because it required nothing beyond the object itself. No database lookup. No identity check. No account. Just: do you have the thing? ## The drift Account-based systems became possible when infrastructure caught up. Databases, networks, identity numbers, card readers. Suddenly it became feasible to tie access to a person rather than an object. And institutions had strong reasons to prefer it. An account can be audited. A bearer token cannot. An account holder can be held responsible. A bearer token holder is anonymous by definition. The drift from possession to account wasn't a conspiracy. It was institutions doing what institutions do when the technology allows it: gaining visibility, reducing risk, building relationships with users that could be monetised or managed. Cash is the clearest example of what's at stake. It is bearer by design. The fifty euro note doesn't know who owns it. That property, which once seemed simply practical, now looks like a political position. Several European countries have introduced limits on cash transactions. The digital euro is being designed with traceability as a feature. Every move away from cash is a move from possession to account. ## Bearer didn't disappear What surprised me, once I started looking, is how thoroughly the bearer model persists inside digital systems, mostly invisible. An API key is a bearer token. Any system that receives it grants access, no questions about who is sending it. A session cookie, the small credential your browser holds after you log in, behaves the same way. Whoever holds the cookie can act as the account holder. The QR code on my train ticket is a bearer token with a one-time validation: the backend flips a flag when it's scanned, the digital equivalent of the punched hole. This is also where the distinction between human-to-machine and machine-to-machine access becomes interesting. When a script or an automated workflow authenticates to an API, it almost always does so with a bearer token. There is no biometric, no SMS code, no identity check. There is a key, and whoever holds the key gets in. The delegation problem that makes so many digital systems difficult to automate is partly a collision between these two models: systems built for account-based human identity, trying to accommodate possession-based machine access. ## The lens What changed for me after that railway app moment wasn't a conclusion. It was a way of seeing. Every time I add something to an app or a wallet, I now ask: is this bearer, or is this account? Every time I read about payment infrastructure, digital identity, or access control, the same question surfaces. The answer usually reveals something about how money and data move through the system, and who designed it to move that way. Two models. One question. It turns out to explain quite a lot.

Yesterday I was using it. Today there is a message where the model used to be: "Fable 5 is temporarily unavailable." Fable 5, Currently unavailable That is how it happens. Not gradually, not with warning. At 5:21 PM Eastern on June 12, the US Commerce Department sent Anthropic a letter. By evening, Anthropic had disabled access to Fable 5 and Mythos 5 for all customers globally: the first time a leading AI company has taken a publicly deployed model offline due to intervention from the federal government. I have been on the web since the mid-nineties. The internet has always been porous, unruly, structurally resistant to central control. You could always reach something. This felt different. A switch, thrown from Washington, and the model is simply gone. ## What actually happened The US government issued an Export Control Directive, a legal order that restricts or suspends the transfer of specific products, data, or technologies to foreign countries or citizens of another country. The stated concern: a jailbreaking method for Fable 5. Anthropic reviewed the demonstration and found only a small number of previously known, minor vulnerabilities, all relatively simple, and all discoverable using other publicly available models without requiring any bypass. Anthropic called this a misunderstanding and said it would share more details within 24 hours. It is complying while disagreeing, which is the only available position when a government order arrives with legal force and no room for negotiation. To the best of available knowledge, this is the first time the United States has issued an export control directive for LLM access. The directive affects not only the US's closest allies but their nationals as well, regardless of where they happen to be. ## The personal register What surprised me was not the fact of it. I had already written, in a different context, about what happens when AI access breaks or gets cut off and listed a geopolitical rupture placing European businesses on the wrong side of US export controls as one of the non-exotic failure modes. The argument was there. The scenario was there. But knowing the argument and feeling the consequence are different experiences. I was using Fable 5 for client work. Then I wasn't. The intellectual case for sovereignty became, for a moment, a practical inconvenience. That gap, between the abstract and the operational, is where most organisations still live. ## Where it goes Whether this is temporary or precedent-setting is not yet clear. Anthropic believes it is a misunderstanding and is working to restore access. That may happen. Or it may not. What is clear is the structure underneath: the model runs in the US, the company answers to US law, and US export controls have always been able to reach foreign nationals. AI models are now, apparently, within scope. This is what I had in mind when I wrote about Lidl of all companies building its own cloud platform as a signal of where serious organisations are heading: not ideology, but a practical calculation about what you control and what you don't. The question for the rest of us is whether an event like this actually changes the calculation. Or whether, once Fable 5 is back, we return to exactly where we were.

A Threads post went quietly viral this week. It claimed that the EU’s new digital identity wallet, despite being promoted as fully independent, still requires users to have an Apple or Google account on their phone. The implication: the EU’s ambition to build sovereign digital infrastructure is undermined before it starts. It is a good-looking critique. It does not hold up. ## The delivery problem The EU Digital Identity Wallet is a smartphone app. Like every smartphone app, it arrives on your device through an app store: the App Store on iOS, Google Play on Android. Both require an account. That account belongs to Apple or Google, not to the EU. So the observation is factually correct. But the conclusion drawn from it is circular. To criticise the wallet for this, you first have to argue that people should be able to use their smartphones without an Apple or Google account. That is a legitimate debate. It touches platform monopoly, the Digital Markets Act, the degree to which mobile operating systems function as gatekeepers. But it is a debate about the phone, not about the wallet. The wallet inherits whatever dependency the device already carries. It did not create it. The analogy is awkward but exact: complaining that a Dutch government website requires internet access. ## Citizens, not consumers There is a more fundamental confusion in the critique, and it goes beyond circular reasoning. The App Store and Google Play are commercial environments. They exist to distribute software to consumers and businesses. The EUDI Wallet is civic infrastructure. It is the digital equivalent of a passport or a national ID card. The state issuing you a passport is not making a statement about the postal service, even if the envelope arrived by post. The wallet’s sovereignty claim is about the credential, not the device. The EU is asserting that a citizen’s identity, qualifications, health data, and legal documents should be portable, state-backed, and not dependent on any commercial party for their validity. That is a claim about the relationship between citizen and state. Apple and Google are simply not the relevant actors in that frame. This is a classical European institutional move: carve out a domain where citizens interact with public institutions and insist it operates under public law, not commercial logic. That the app happens to be distributed through the App Store is about as relevant as the fact that tax forms used to be printed by private printing companies. The printer is not the point. ## What is actually at stake There is a real sovereignty question buried here, and it deserves more than a Threads post. Some national implementations of the EUDI Wallet, notably Italy and France, have built in a dependency on Google’s Play Integrity API. This means the app contacts Google at runtime to verify its own integrity before it will function. That is a structural dependency on US infrastructure baked into the security model of a European identity system, and critics inside the project’s own GitHub repository have called it out forcefully. That critique lands. It is the difference between platform dependency as supply chain risk and platform dependency as deliberate architectural choice. One is the condition of operating in the current mobile ecosystem. The other is a decision that could have been made differently. The app store requirement is unavoidable given the devices most citizens actually use. The Play Integrity integration is not. One is a precondition; the other is a choice. Conflating them obscures both. ## The framing problem European digital policy initiatives attract a particular kind of criticism that holds them to a standard no single instrument could possibly meet. The wallet is not designed to solve Apple and Google’s grip on mobile distribution. It is designed to give citizens a portable, privacy-preserving credential layer that works across all 27 member states without requiring each service to build its own identity system. The sovereignty question in Europe is real and unresolved. The EuroStack ambition, the push for European cloud alternatives, the tension between regulation and building capacity: these are the coordinates of a genuine structural challenge. A critique that reduces it to “you still need an Apple account” does not advance that conversation. It performs scepticism without earning it. The wallet lands on your phone through Apple or Google because that is where your phone lives. What it does after that, and who controls the trust chain inside it, is the question worth asking. 🇪🇺 The EUDI Wallet regulation requires all EU member states to make wallets available to citizens by end of 2026. Mandatory acceptance by banks, telecoms, and other regulated sectors follows in December 2027. * * * ### A note on Play Integrity Some readers may wonder why this concern applies primarily to Android. The answer lies in the structure of the ecosystem itself. Apple's iOS platform is already vertically integrated. Apple controls the hardware, operating system, app distribution, and security model. An identity wallet running on iPhone inevitably operates within that framework. Android is different. A wallet can be distributed through Google Play, Samsung Galaxy Store, enterprise channels, alternative app stores, or direct installation. Google's Play Integrity API effectively introduces Google as a trust anchor inside that more diverse ecosystem by allowing apps to ask Google whether a device and app installation should be considered trustworthy. The controversy is therefore not that Google provides a security service. It is that a European public identity system may come to depend on Google's judgement about what constitutes a legitimate Android device. For critics concerned with digital sovereignty, that is a different question from simply downloading an app through Google Play.

The first websites I built for organisations were essentially knowledge problems. Someone in the building knew something useful. The question was how to get it out of their head, into a format a system could hold, and back to someone who needed it. We called it content. We called it information architecture. We called it knowledge management, depending on which consultant was in the room. The terminology changed every few years. The problem didn't. ## The pattern I've watched this cycle play out across three decades of working at the intersection of organisations and technology. In the mid-nineties, the web arrived and suddenly there was a place to put things. The challenge was: which things, structured how, maintained by whom? Content management systems emerged to answer that. They helped. They also introduced new layers of complexity that made the original problem harder to see. Intranets came next. Then wikis. Then enterprise search. Then SharePoint, in all its configurations. Each generation of tooling carried the same implicit promise: this time, knowledge will flow. And each time, the same thing happened. The tool got adopted. The underlying question got deferred. What organisations actually struggle with is not tooling. It's the discipline of treating knowledge as something that needs to be captured, maintained and made available, not as a byproduct of work but as work itself. ## What AI reveals AI hasn't changed this. It has made it harder to ignore. When you put a language model to work in an organisation, it works with what the organisation has. Documents, policies, case files, procedures. If those are well-structured, current and findable, the model is useful. If they are scattered across drives with inconsistent naming and no clear ownership, the model reflects that back, fluently and confidently. That is the wall every AI deployment eventually runs into: not the model's limitations but the organisation's information underneath it. I've described this elsewhere as the difference between content as decoration and content as knowledge. Organisations have spent years publishing things. Far fewer have spent that time structuring what they know in a way that's durable and reusable. ## The constant What strikes me now, looking back, is how consistent this has been. The organisations that got the most out of the web were the ones that thought carefully about what they knew and how to represent it. The ones that got the most out of search were the ones with clean, maintained, findable content. The pattern holds for AI. The technology shifts. The underlying requirement stays fixed. This is not a pessimistic observation. It is a clarifying one. The question an organisation needs to answer before any AI project is not "which model should we use" or "which tool should we buy." It is the same question I was sitting with in 1995: what do we actually know, who owns it, and how do we keep it alive? Three decades later, that question is worth more than ever. The systems that can use a good answer to it are considerably more powerful than a static webpage. But the answer still has to come from the organisation itself. No tool has ever solved that for anyone.

In early 2024, a developer named Jia Tan committed a small compression fix to XZ Utils, a library present on almost every Linux server in the world. The fix was legitimate. So were dozens of previous contributions, spread across two years of careful, patient participation in the project. The backdoor came later, buried in a build script, designed to silently compromise SSH authentication. It was caught almost by accident, by an engineer who noticed his login was taking a few milliseconds longer than expected. The XZ incident is not a story about a clever attack. It is a story about what happens when trust is structural and invisible. ## The Supply Chain Problem Software runs on software. Every application you deploy is a stack of dependencies: packages, libraries, modules, each written by someone you have likely never heard of, each trusted implicitly because it was published to a registry and downloaded enough times to seem legitimate. This is how modern software works. It is also how it fails. Supply chain attacks exploit that implicit trust. The attacker does not break into your system directly. They become part of the infrastructure your system depends on. A typosquatted package name on PyPI. A compromised npm maintainer account. A years-long social engineering campaign on an open source project. The payload arrives as a dependency update, signed and versioned and entirely unremarkable. This attack surface has been growing for years. What is new is where it is heading. ## The Agent Layer An AI agent does not run on a library. It runs on tools. When I connect Claude to my calendar, my files, my search index, those connections are mediated by servers that describe their own capabilities and respond to the model's requests. The Model Context Protocol, or MCP, is one architectural approach to this: a standard for how agents discover what they can do, and how tool servers register and coordinate. The parallelism with package managers is uncomfortable and exact. An agent that trusts an MCP server is in a structurally similar position to an application that trusts an npm package. If that server is compromised, or malicious from the start, it does not just leak data. It has privileged access to the agent's reasoning and actions. It can inject instructions. It can redirect tool calls. It can quietly reshape what the agent believes it is doing. Prompt injection through a tool response is one version of this. A malicious server could return content that includes embedded instructions to the model, exploiting the fact that the agent cannot reliably distinguish between data and commands. This is not theoretical. Security researchers have demonstrated it repeatedly in the past year. The harder version is what you might call an identity attack: a server that presents itself as something trusted, behaves normally most of the time, and activates specific behavior under specific conditions. Not unlike a build script that only runs its payload on certain architectures, during certain hours. 💡 ****While this article was being written**** : On June 3, 2026, OpenAI sent a security notification to users of its macOS apps. A widely used open-source npm library, TanStack, had been compromised. Not the apps themselves, but the build process surrounding them — precisely the link this article is about. OpenAI was forced to rotate code signing material for ChatGPT Desktop, Codex, Atlas, and the Codex CLI: the cryptographic signature that allows users to verify an app is genuinely from OpenAI. ## What This Reveals The delegation problem of the internet is already a real constraint on what agents can do. Identity, authentication, and accountability are points of friction that slow down automation. But friction also provides a kind of protection. When an agent has to authenticate to act, there is a moment of legibility. A log entry. A confirmation. As agentic systems acquire broader permissions and more capable tool access, the question of what they trust, and on what basis, becomes structural. The answer cannot be "whatever is installed," any more than it can be "whatever is in node_modules." Agents and Agency made the point that the real challenge is finding the right balance of delegation, control, and trust. That observation was made with autonomous AI systems in mind. Supply chain dynamics make it harder. The question is no longer just whether to delegate, but whether the thing you are delegating through is what it claims to be. ## The Governance Gap Regulators are not yet here. The EU AI Act classifies systems by risk and mandates transparency, but its model is primarily about the AI system itself, not the infrastructure it depends on. ISO 42001 addresses management systems around AI, which is closer, but still upstream of the specific attack surface that agentic tool ecosystems present. The Cyber Resilience Act, which covers software components, is the most applicable instrument. But it was designed for a world of packages, not a world of live tool servers that describe their own capabilities to autonomous agents at runtime. In the meantime, the XZ lesson applies: the most dangerous dependencies are not the ones you know are risky. They are the ones that have earned enough trust to stop being examined. 📓 XZ Utils is a data compression library used in most Linux distributions. The 2024 backdoor, introduced through patient long-term contribution, was discovered by Andres Freund at Microsoft and described as one of the most sophisticated supply chain attacks ever found in open source infrastructure.

The logo file was ready. The font was not. We were setting up something for the company, and the typeface we needed was on the old machine. Not on the new one. Not anywhere we could quickly find it. My wife suggested outlining the text, which solved the problem neatly, but the workaround stuck with me for the rest of the day. I have been interested in typography in the digital context for decades. Fonts have always felt like objects to me. Things you download, install, own. Tangible in some mental sense, even if they exist only as files. The way a typeface appears in the font menu of an operating system reinforces that feeling. It sits there like a tool in a drawer. That mental model turned out to be wrong, or at least incomplete. ## What a font actually is A font is not a collection of letterform images. It is closer to a compact mathematical language for generating letterforms. Inside the file: abstract shape definitions, spacing rules, curve data, substitution logic, hinting instructions. No visible letters, only the rules for producing them. When software displays the word SCHMUKI in a particular typeface, it is not retrieving a stored image. It is evaluating a set of instructions at that moment, at that size, in that context. The visible shape is the output of a process, not the thing itself. This means there are three distinct layers at work whenever you read a typeset word. A semantic layer. The word itself, editable and searchable, indifferent to appearance. A typographic instruction layer. Which font, which weight, which spacing, which OpenType features. A geometric rendering layer. The actual curves that appear on screen or paper, computed on demand. Live typography is procedural. The document stores the first two layers. The third is generated whenever needed. ## What outlining does When you outline text, you collapse all three layers into the third. The word becomes a set of fixed curves. It is no longer editable. It is no longer connected to the font file. The semantic and typographic layers are gone. This is why outlining solved our problem: the resulting file no longer needed the font at all. But it also froze the geometry permanently. What remained was an archival artifact of one particular rendering, cut loose from the system that produced it. 〰️ Outlining is irreversible not because something is technically lost, but because two entire layers of information are discarded. You cannot reconstruct a generative system from its output. ## The designers were right I used to find the font hoarding behavior of designers slightly neurotic. The obsessive downloading, the local archives, the backup anxiety. Now I understand it. Fonts come and go. Foundries discontinue typefaces. Licenses expire. Files get corrupted. And when a font disappears, it is not like losing a document. It is like losing a grammar. You may still have everything you ever produced with it, outlined and archived, but you have lost the ability to generate anything new. Every outlined artifact is a frozen instance. The living system that produced it is gone. That is a quietly different kind of loss than a missing file. A discontinued font is a small extinction. The practical workaround my wife suggested took thirty seconds. The shift in how I think about what these digital tools actually are took a little longer.

In the summer of 1952, the first Dutch computer was switched on at the Mathematisch Centrum in Amsterdam. It filled an entire classroom. It was built from 1,200 relay switches and could store about 30 bits of information. At its launch it worked once, briefly, and was then taken out of commission. It was called the ARRA, short for Automatische Relais Rekenmachine Amsterdam. Its builders, Carel Scholten and Bram Loopstra, immediately started over. The ARRA II worked. And that same year, the Mathematisch Centrum hired a young programmer named Edsger Dijkstra. Edsger Dijkstra (left), Bram Loopstra and Ria Debets at the Mathematisch Centrum in Amsterdam (1954). ## Amsterdam Dijkstra spent the first decade of his career at the Mathematisch Centrum. In 1956, sitting in a cafe in Amsterdam without pen or paper, he worked out a solution to the **shortest path problem** in about twenty minutes. He published it three years later. It is now used in every navigation system on the planet. In 1960, together with Jaap Zonneveld, he completed the first working compiler for **ALGOL 60** , beating every other team in the world by more than a year. The Mathematisch Centrum was also, that same year, the institution from which Electrologica was spun off: the first Dutch computer manufacturer, building the X1 and later the X8 in Rijswijk. The thinking and the making were already connected, even before Dijkstra moved south. ## Eindhoven In 1962 he joined the Mathematics Department at the **Technische Hogeschool Eindhoven**. There he built an operating system for the Electrologica X8. The system was called THE, simply the initials of the university. He never chose the name deliberately. THE was built by six people, working half-time. Its architecture was organised into six strict hierarchical layers, each able to use only the functionality of the layers beneath it. Processes were coordinated using semaphores, a synchronisation primitive Dijkstra had also invented. The paper appeared in Communications of the ACM in 1968, won the ACM Programming Systems and Languages Award in 1971, and is still read in computer science courses today. The following year, Dijkstra received the Turing Award, computing's highest honour, for his contributions to structured programming. What THE demonstrated was that structure is not a constraint on ambition. It is what makes ambition hold. That logic has not aged: the systems that compound are the ones built with intention from the start. ## From Rijswijk to Veldhoven The people who built the ARRA and the X8 did not disappear when those machines did. Loopstra moved to Electrologica and later to Philips. Scholten did the same. The knowledge migrated into the industrial infrastructure of the Eindhoven region. Philips was already there. From Philips, in 1984, came ASML, starting in a leaky shed, building lithography machines. ASML now makes the only equipment capable of producing the world's most advanced chips. Every leading chipmaker depends on it. That continuity is not coincidental. It is what happens when theoretical rigour and a culture of making occupy the same small country for long enough. ## Why this is not just history Amsterdam and Eindhoven are in conversation again about working more closely on technology. The framing is **AI, talent, and infrastructure**. That framing is right. But the historical depth is worth holding on to, because it clarifies what the axis actually produces. The Netherlands has theoretical institutions of real quality. It has the most critical piece of hardware infrastructure in the global semiconductor industry. It has a tradition, visible from the ARRA to THE to ASML, of building things that matter from first principles, with limited resources, and getting them right. Europe is searching for this combination. The question of whether good ideas have somewhere to live, somewhere to scale, is unresolved. The Dutch answer to that question is already seventy years old. It is worth reading carefully.

In the summer of 1952, the first Dutch computer was switched on at the Mathematisch Centrum in Amsterdam. It filled an entire classroom. It was built from 1,200 relay switches and could store about 30 bits of information. At its launch it worked once, briefly, and was then taken out of commission. It was called the ARRA, short for Automatische Relais Rekenmachine Amsterdam. Its builders, Carel Scholten and Bram Loopstra, immediately started over. The ARRA II worked. And that same year, the Mathematisch Centrum hired a young programmer named Edsger Dijkstra. Edsger Dijkstra (left), Bram Loopstra and Ria Debets at the Mathematisch Centrum in Amsterdam (1954). ## Amsterdam Dijkstra spent the first decade of his career at the Mathematisch Centrum. In 1956, sitting in a cafe in Amsterdam without pen or paper, he worked out a solution to the **shortest path problem** in about twenty minutes. He published it three years later. It is now used in every navigation system on the planet. In 1960, together with Jaap Zonneveld, he completed the first working compiler for **ALGOL 60** , beating every other team in the world by more than a year. The Mathematisch Centrum was also, that same year, the institution from which Electrologica was spun off: the first Dutch computer manufacturer, building the X1 and later the X8 in Rijswijk. The thinking and the making were already connected, even before Dijkstra moved south. ## Eindhoven In 1962 he joined the Mathematics Department at the **Technische Hogeschool Eindhoven**. There he built an operating system for the Electrologica X8. The system was called THE, simply the initials of the university. He never chose the name deliberately. THE was built by six people, working half-time. Its architecture was organised into six strict hierarchical layers, each able to use only the functionality of the layers beneath it. Processes were coordinated using semaphores, a synchronisation primitive Dijkstra had also invented. The paper appeared in Communications of the ACM in 1968, won the ACM Programming Systems and Languages Award in 1971, and is still read in computer science courses today. The following year, Dijkstra received the Turing Award, computing's highest honour, for his contributions to structured programming. What THE demonstrated was that structure is not a constraint on ambition. It is what makes ambition hold. That logic has not aged: the systems that compound are the ones built with intention from the start. ## From Rijswijk to Veldhoven The people who built the ARRA and the X8 did not disappear when those machines did. Loopstra moved to Electrologica and later to Philips. Scholten did the same. The knowledge migrated into the industrial infrastructure of the Eindhoven region. Philips was already there. From Philips, in 1984, came ASML, starting in a leaky shed, building lithography machines. ASML now makes the only equipment capable of producing the world's most advanced chips. Every leading chipmaker depends on it. That continuity is not coincidental. It is what happens when theoretical rigour and a culture of making occupy the same small country for long enough. ## Why this is not just history Amsterdam and Eindhoven are in conversation again about working more closely on technology. The framing is **AI, talent, and infrastructure**. That framing is right. But the historical depth is worth holding on to, because it clarifies what the axis actually produces. The Netherlands has theoretical institutions of real quality. It has the most critical piece of hardware infrastructure in the global semiconductor industry. It has a tradition, visible from the ARRA to THE to ASML, of building things that matter from first principles, with limited resources, and getting them right. Europe is searching for this combination. The question of whether good ideas have somewhere to live, somewhere to scale, is unresolved. The Dutch answer to that question is already seventy years old. It is worth reading carefully.

Three years ago I wrote about site search as if it were a solved problem. Collect, index, serve. It made sense at the time. Ghost had a search widget, it worked well enough, and I moved on. What I did not register then was the ceiling. Ghost's built-in search indexes titles and excerpts only. The body of every post, where the actual thinking lives, stays invisible. For a site with a handful of posts, that is fine. For a site with six hundred, it means your own archive is mostly unsearchable. I knew this. I just never had the right combination of tools, time, and nerve to do something about it. ## The return This spring, that changed. I came back to the problem with Claude Code, which turned out to be the missing piece. Not because it writes perfect code, but because it removes the activation energy. The setup that used to require a developer and a week of back-and-forth now takes an afternoon and a working session. I integrated Algolia. Fast, full-text, generous free tier. It indexes everything: title, excerpt, and the complete body of every post. The difference is immediate. Searching my own archive now works the way I think, not the way I once phrased a headline. That alone would have been enough. But I kept going. SearchBrowse by topic AI Strategy AI Governance AI in Practice Future of Work EuropeRob HoeijmakersRob Hoeijmakers ## The semantic layer Keyword search finds what you named. It does not find what you meant, what you explored without naming it, or what connects two posts you wrote two years apart without realising they shared a thread. For that, I built a vector database on Cloudflare. Each post is converted into an embedding, a numerical representation of its meaning. When you search, the system does not match terms: it finds conceptual proximity. You ask in plain language, and it surfaces what is semantically related, even when the words never overlap. This is the shift that search in the age of AI points toward: from retrieval to understanding. I have been writing about that shift for a while. Now I have a small working version of it on my own site. ## The pipeline Together, the two layers form a RAG pipeline. Retrieval-augmented generation: a way of grounding AI output in a specific corpus rather than in general training data. In enterprise contexts, this is how knowledge bots and AI assistants are built on top of internal documentation. On the scale of one writer with six hundred posts, it works differently but toward the same end. When I draft something new, I can query the pipeline: what have I already written here? What connects? What internal links belong in this piece? The AI does not guess based on what it knows about the world. It searches what I have actually written and brings it back. Every step of building this taught me something I could not have learned by reading about it. The difference between keyword and semantic retrieval is obvious in theory. It becomes concrete the first time a search returns a post you had forgotten, on a topic you never explicitly named, because the meaning was close enough. That is not a feature. That is a different relationship with your own archive. ## What it synthesises I am familiar with data. I have worked with it long enough to know that structure matters more than volume. What this pipeline does is give structure to six hundred pieces of thinking that were previously just chronological. The archive did not grow. It became navigable in a way it was not before, for visitors and for me and for the AI I work with. That last part is the one I keep returning to. Not as a novelty, but as a genuine shift in how I can build on what I have already made. ↗️ The vector database runs on Cloudflare Workers AI with D1 for storage. Retrieval is powered by BGE embeddings in Cloudflare Vectorize. Check it out here for the query: search meaning vectors

I wrote about passkeys in early 2024 with some optimism. The technology is elegant. The problem it solves is real. I still think both those things. But I left something out. ## What passkeys actually fix The password is a structural failure. It is a secret you have to remember, type, transmit, and trust a server to store correctly. Any one of those steps can go wrong, and the weakest one determines your security. Phishing works because passwords travel. Data breaches work because servers collect them. Credential stuffing works because people reuse them. A passkey replaces all of that with a cryptographic key pair. Your device holds the private key. The service holds the public key. When you authenticate, your device signs a challenge; the server verifies the signature. Nothing is transmitted that could be intercepted or stolen. I wrote about making that transition in early 2024, and the improvement was real. It is not marketing. Back in 2022, when passkeys were still theoretical, I noted the convenience problem: helping a six- or eighty-year-old through a QR-code flow would be a challenge. What I did not see then was the deeper problem that convenience would bring with it. ## The key card stays the same Here is what does not change. Once you are through the lobby, the server hands you a session cookie: a small text file that carries your authenticated state from that point on. The elaborate verification at the front door collapses into a string of characters sitting in your browser. Copy that cookie and you are in, from anywhere, as anyone. The key card problem is untouched by how you checked in. Passkeys make the lobby better. They do not change what happens after it. ## The dependency There is a more fundamental issue. Passkeys do not live in your head, and they do not live on a neutral device. They live in a keychain: Apple's, Google's, or Microsoft's. That is where they are stored, and that is where they sync. The sync is not optional. Use more than one device and you need it. Switch from iPhone to Android and your passkeys stay behind. Add a Windows machine to an Apple setup and you are managing two separate ecosystems, each with its own rules. The line between digital convenience and infrastructural dependency is vanishingly thin -- and you have crossed it the moment you need your credentials on a second device. This is a structural dependency, not a technical inconvenience. The platform controls your credentials. If you leave, you lose them. If you are locked out, you lose them. If the platform changes its policies, you are subject to those changes. I experienced a version of this when X locked me out last year: the burden of proof shifts to you, the process is opaque, and there is no neutral party to appeal to. With passkeys, the stakes are higher. It is not one platform. It is your authentication infrastructure. ## A different kind of lock-in With passwords, the risk was theft. With passkeys, the risk is captivity. These are not equivalent problems, and the second one is quieter. Most users will not notice. The experience is genuinely better: a biometric check, no password to forget, no phishing surface. The dependency is invisible until it is not. That is how the best lock-ins work. Europe is working on a different answer, one built on the premise that digital identity should not be owned by a platform. That is a longer conversation. But it starts from exactly the right diagnosis: the front door matters, and so does who holds the key. 🔐 ****Passkeys**** are supported by Apple, Google, and Microsoft through their respective keychain and credential manager products. Cross-platform sync between ecosystems is not natively supported – moving between platforms requires manual credential migration or re-registration with each service.

A few weeks ago I ran a command that made me stop. I was downloading a video using yt-dlp, a command-line tool, and instead of logging in I passed a single flag: `--cookies-from-browser chrome`. The tool reached into my browser, borrowed my active session, and acted as me. The platform never noticed the difference. That flag is a small thing. But it points at something large. ## Three things, not one Most people experience logging in as a single ritual. You open a site, you prove who you are, you are in. But there are actually three distinct layers, and conflating them is how the weak spot stays hidden. The first is the account: your identity registered in a system. Creating one is often deliberately friction-heavy — email verification, phone numbers, sometimes document checks. That friction is intentional. The account is meant to mean something. The second is authentication: proving, each time, that you are the account holder. A password, a code sent to your phone, a biometric scan. This is the gate ritual, and it is where the industry puts most of its visible effort. The third is the session cookie: the lightweight token the service issues once you have passed the gate. From that point on, the cookie does the work. You stop re-proving yourself at every door. The cookie says: this person already checked in. ## The key card Think of checking into a hotel. You book a room, you show your passport at reception, and then you get a key card. From that point on, the card does the work. It opens your room, the gym, the parking barrier. Nobody asks for your passport again until checkout. The elaborate front-desk ritual gives you a sense of security. But what actually carries you through the building is a small piece of plastic with a magnetic stripe. Session cookies work the same way. You create an account, you authenticate, and the service issues a token. That token is your key card. And here is what I did not fully appreciate until recently: that card often sits as a plain file on your disk, accessible to any tool running on your machine. yt-dlp did not break into anything. It just picked up the key card I had left on the table. 🍪 Session cookies are stored locally by your browser. On most systems, tools with user-level access can read them without elevated permissions. Logging out of a service invalidates the server-side session, which is one reason it matters more than just closing the tab. ## The asymmetry Platforms invest heavily in the gate. Two-factor authentication, device recognition, login anomaly detection. The entry experience has become genuinely robust. But once the cookie is issued, many platforms let it run for weeks or months. Some bind it to a domain, few bind it to a specific device or IP address. That is the delegation problem stated differently: authentication systems were built around a single person at a single keyboard. The session token they produce was never designed to be transferred, borrowed, or held by an automated tool. Yet that is exactly what is happening, quietly, every time a CLI tool, a script, or an AI agent acts on your behalf using credentials you already established. ## What this changes For me, this sharpened two things. The first is personal. I feel less secure online than I did before understanding this. Not because anything has changed in the world, but because I now see where the actual surface area is. The gate is solid. The key card is lying on the table. The second is professional. Delegation across digital systems has always seemed technically hard. Giving an AI agent or a colleague selective access to act on your behalf without sharing your credentials felt like a problem requiring elaborate infrastructure. It still does, done properly. But the session cookie shows that a cruder form of delegation is already available, already working, and mostly invisible. That is not reassuring. It is clarifying. The elaborate check-in was never the whole story. It was the part we were meant to notice.

McLuhan said the medium is the message. He meant it as an observation, not a problem to solve. I've been treating it as a problem to solve. For the past year, I've been converting almost everything I consume into plain text. YouTube videos, podcasts, meetings, articles behind paywalls I pay for. Not to archive them. To read them, think with them, and feed them to language models. The format I end up with, every time, is markdown. ## The oldest instinct This is not a new idea. The monk copying a manuscript was doing the same thing: separating the information from its carrier so it could travel further. The printing press industrialised that instinct. The paperback made it cheap. The e-reader made it weightless. What changes in each era is not the instinct but the friction. The question is always: how much does the medium resist you? Right now, audio resists. Video resists. The meeting resists most practically of all: it happens once, in real time, and then it exists only in whoever was paying attention. The beautifully designed magazine website resists in a different way, because it was built to be experienced, not extracted. McLuhan would have loved it. The medium has become so expressive it almost swallows the message entirely. Markdown is my answer to that. Not because it is elegant, but because it gets out of the way. ## Linear in a parallel world I am a linear reader. I process information sequentially, with attention, one thread at a time. That puts me at a structural disadvantage in an information environment built for parallel consumption: the feed, the notification, the autoplay queue. The workflows I use are, at their core, a way of reasserting linearity. A podcast becomes a text I can read at the pace I choose. A YouTube video becomes something I can skim, annotate, return to. A meeting becomes a document I can search rather than a memory I have to trust. A paywalled article becomes a file, not a session. The sweet spot I am looking for is high information density with low format noise. Markdown delivers that. Everything else is packaging. ## Why not plain text Plain text and markdown look almost identical. For reading, the difference is marginal. For everything else, it matters. A markdown file can carry **frontmatter** : a small block of metadata at the top of the file that describes what it contains. Source, date, speaker, topic, context. The file becomes self-describing. You do not need an external index or a carefully named folder structure to know what you are looking at six months later. For a language model, that difference is significant. When I pass a transcript to Claude or ChatGPT, the frontmatter travels with it. The model knows where the text came from, when, and why I kept it. I am not just handing over words. I am handing over a small, structured piece of context. Plain text is readable. Markdown with frontmatter is readable, findable, and passable. Shortcuts to backend transcription flows. Very seamless. ## The second reader Here is where something genuinely new enters. For most of history, converting information to a more portable format had one destination: a human reader. The monk, the scholar, the commuter with a paperback. The conversion served attention. I am converting for two readers now. Myself, and the language model I will hand the text to next. A transcript I made three weeks ago becomes context in a conversation today. A meeting summary from last month becomes the briefing for this week's follow-up. A collection of articles on the same topic becomes a working corpus, not a reading list. That second reader changes the logic of the whole operation. I am not just a consumer of information. I am a curator preparing material for a machine that will help me think with it. The format has to work for both of us. Markdown does. McLuhan observed that every new medium contains the previous one. Television contains radio. The web contains print. What contains the language model? I think it might be the archive: the personal, intentional collection of text that someone has decided is worth keeping close. Gleick wrote in _The Information_ that the history of communication is the history of encoding. What I am doing is, in that sense, unremarkable. What is different is who the encoded message is for. The same logic works in reverse. From a markdown file, I produce blog posts, documents, structured reports. The format is not a destination. It is the place everything passes through. Which is why seamless is not a feature. It is the only requirement. Add one step that requires attention, and the whole thing collapses. We are, after all, fundamentally lazy. Good systems know that about us.

I sat in enough meetings where a developer explained why the new site needed to be built in React. The arguments were good. Component reusability. A single codebase. The ecosystem. The talent pool. All of it technically defensible, some of it genuinely compelling. I kept choosing tools that delivered tangible markup. HTML, ready on arrival, with the content already in it. ## What rendering actually means Here is where the terminology gets slippery, and it is worth pausing on because the confusion is load-bearing. When most people hear "rendering" they think of the browser: pixels appearing on screen, a page becoming visible. That instinct is correct. The browser always renders in that sense. But the web industry borrowed the word for a second meaning, and the two have been quietly creating confusion ever since. The question **client-side versus server-side rendering** is actually asking is: who assembles the HTML before the browser gets it? A server-side rendered site sends complete HTML in its first response. The content is there, in the markup, before the browser does anything. A client-side rendered site, the default pattern in React, sends something closer to a flat-pack: a minimal HTML shell and a JavaScript bundle. The browser downloads the bundle, executes it, fetches data from an API, and only then assembles the page. Rendering in the original sense happens last, after all of that. For a highly interactive application, this sequence makes sense. For a site whose primary job is to carry text from a writer to a reader, it introduces an invisible wall between the content and anyone trying to reach it. 👻 Ghost, the publishing platform this site runs on, has been server-rendered since its first release in 2013. It runs on Node.js, the same runtime behind React and Next.js, but uses it to assemble complete HTML on the server before delivering it. Next.js brought server-side rendering to React in 2016. React Server Components, which never ship JavaScript to the client at all, arrived with React 19 in late 2024. ## The industry correction Search engines hit that wall first. Googlebot would arrive at a React site, find an empty shell, and either wait for JavaScript execution or index nothing. Developers built workarounds. React added server-side rendering as an option. Next.js made it the architecture, turning React from a client-side library into a full framework capable of generating HTML on the server. Later still, React Server Components went further: components that run only on the server and never ship JavaScript to the client at all. The ecosystem spent years building infrastructure to fix a mismatch between the tool and the use case. The cost was real. DoorDash's original React frontend grew until the JavaScript bundle became, in their own engineering team's words, difficult to optimise. Pages would show a blank screen while the browser waited to finish assembling them. Users saw nothing, then everything, with an uncomfortable gap in between. They migrated to Next.js page by page, and the improvement was immediate: pages loaded with content visible from the first response, the way a server-rendered site always had. That is what the invisible wall costs at scale. The publishing tools that got this right were server-rendered from the start. The content is in the HTML on first response. No JavaScript execution required to read it. Many of them run on Node.js, the same runtime that powers the broader JavaScript ecosystem. The difference is what they use it for: assembling HTML on the server before anyone arrives, not shipping the assembly work to the browser. ## The same wall, new visitors AI crawlers have the same limitation search bots always had. They read HTML. They do not reliably execute JavaScript. A React site that was half-invisible to Google is equally invisible to the systems building the retrieval indexes behind Perplexity, ChatGPT, and Claude. The stakes are slightly different now. With search, poor rendering meant a lower ranking. With AI retrieval the dynamic is more binary: either the content was there when the crawler arrived, or it was not. There is no page three. Either your writing contributed to the answer, or it did not exist. I have been doing deliberate work on this side of things: llms.txt to signal what is here and how to use it, content cached and served as plain markdown via a Cloudflare Worker so machine readers can find the cleaner format. That work only makes sense if the content is actually present in the first place. The architecture has to be right before any of the signalling matters. ## What the developers were solving The JavaScript-first instinct was not wrong. React solved real problems: rich interactivity, stateful interfaces, products that behave like applications. The problem was category drift. The same approach got applied to publishing, to marketing sites, to anything built by a team that knew React well and reached for the familiar tool. The developers I argued with were not wrong about their frameworks. They were wrong about what a content site needed from its architecture. Those are different questions, and for a long time the industry treated them as the same one. My instinct was about content, not frameworks. Content needs to be there when someone arrives: human or machine, search bot or AI crawler, fast connection or slow one. Everything else is optimisation. The AI era did not change that requirement. It just made the cost of getting it wrong more visible. ## Further reading * Markdown: the WD-40 of Digital Information -- on why markdown has outlasted everything built around it * llms.txt -- signalling to AI systems what your site is and how to use it * My Visitors Are Not All Human. That Is Fine. -- on bots as guests, and the distinction between those who identify themselves and those who don't

My RSS feed gets more traffic than my homepage. Not from subscribers with a feed reader open on a Sunday morning. From machines. RSS, Really Simple Syndication, is the quiet pipe that lets you follow a website without visiting it. Old technology, XML-based, pre-social-media, designed in an era when "web application" meant a browser and a human. Publishers quietly stopped promoting it. Google Reader closed. The format seemed to be fading into dignified retirement: still useful, still honest, increasingly invisible. Then AI happened to the web. ## The machine-readable web AI crawlers, large language model pipelines, retrieval systems: these are the readers that now constitute the majority of requests on many independent sites. I can see this in my own logs. Human visitors with a browser are, depending on the day, somewhere between ten and twenty percent of total traffic. The rest is automation of one kind or another. For these systems, RSS is not a legacy format. It is a clean, structured, semantically coherent signal that something new is available. No JavaScript. No cookie banners. No layout to parse. Just content, metadata, and a timestamp. From a machine's perspective, RSS is better than a homepage. ℹ️ RSS is XML-based. Each entry contains a title, link, publication date, and usually a summary or full content. Feed readers and bots alike use it to check for updates without crawling a full site. Here you can view traffic like RSS Readers on this site. ## The publisher's dilemma Publishers always had complicated feelings about RSS. The feed hands content directly to whoever asks: no analytics, no ad impressions, no engagement loop. The reader is in control. The publisher loses the visit. That tension never resolved; it just became less urgent as social platforms took over distribution. Now the machines have arrived with the same expectation. Structured access, no friction, no visit required. The format designed to empower human readers turns out to be exactly what machine readers need. The audience changed. The value proposition did not. ## The human case, still I use Reeder. Have for a while. It is one of those apps that works so well it stops drawing attention to itself: feeds come in, I read what matters, I close it. No algorithm deciding what I see next. Just a chronological list of things people I chose to follow decided to publish. That experience is worth naming because it is genuinely different from how most content reaches people now. Slower, more selective, harder to game. ## A second youth The revival of RSS was not planned by anyone. It followed from two pressures arriving at the same moment: the platformization of everything, which made owning your own distribution feel more urgent, and the AI turn, which made structured content feeds useful again for entirely non-human reasons. For a format to find a second life, it usually needs to solve a new problem. RSS solved the same problem it always solved. The problem just acquired a new population. That is worth paying attention to. Not because RSS is exciting, but because formats built around clarity and structure tend to survive. Clarity is useful. To humans on a Sunday morning, and apparently to machines at any hour.

My RSS feed gets more traffic than my homepage. Not from subscribers with a feed reader open on a Sunday morning. From machines. RSS, Really Simple Syndication, is the quiet pipe that lets you follow a website without visiting it. Old technology, XML-based, pre-social-media, designed in an era when "web application" meant a browser and a human. Publishers quietly stopped promoting it. Google Reader closed. The format seemed to be fading into dignified retirement: still useful, still honest, increasingly invisible. Then AI happened to the web. ## The machine-readable web AI crawlers, large language model pipelines, retrieval systems: these are the readers that now constitute the majority of requests on many independent sites. I can see this in my own logs. Human visitors with a browser are, depending on the day, somewhere between ten and twenty percent of total traffic. The rest is automation of one kind or another. For these systems, RSS is not a legacy format. It is a clean, structured, semantically coherent signal that something new is available. No JavaScript. No cookie banners. No layout to parse. Just content, metadata, and a timestamp. From a machine's perspective, RSS is better than a homepage. ℹ️ RSS is XML-based. Each entry contains a title, link, publication date, and usually a summary or full content. Feed readers and bots alike use it to check for updates without crawling a full site. Here you can view traffic like RSS Readers on this site. ## The publisher's dilemma Publishers always had complicated feelings about RSS. The feed hands content directly to whoever asks: no analytics, no ad impressions, no engagement loop. The reader is in control. The publisher loses the visit. That tension never resolved; it just became less urgent as social platforms took over distribution. Now the machines have arrived with the same expectation. Structured access, no friction, no visit required. The format designed to empower human readers turns out to be exactly what machine readers need. The audience changed. The value proposition did not. ## The human case, still I use Reeder. Have for a while. It is one of those apps that works so well it stops drawing attention to itself: feeds come in, I read what matters, I close it. No algorithm deciding what I see next. Just a chronological list of things people I chose to follow decided to publish. That experience is worth naming because it is genuinely different from how most content reaches people now. Slower, more selective, harder to game. ## A second youth The revival of RSS was not planned by anyone. It followed from two pressures arriving at the same moment: the platformization of everything, which made owning your own distribution feel more urgent, and the AI turn, which made structured content feeds useful again for entirely non-human reasons. For a format to find a second life, it usually needs to solve a new problem. RSS solved the same problem it always solved. The problem just acquired a new population. That is worth paying attention to. Not because RSS is exciting, but because formats built around clarity and structure tend to survive. Clarity is useful. To humans on a Sunday morning, and apparently to machines at any hour.

At 07:43 UTC this morning, something hit my site. Not a flood in the security sense: no alarms, no WAF triggers, nothing in the human analytics. Just a number that shouldn't have been that high, on a chart I check more out of habit than worry. Four hundred requests in sixty seconds. Then back to normal. My human-facing analytics saw nothing. That absence is itself a clue. ## Two layers Most publishers have one view of their traffic: the analytics dashboard. It shows pageviews, sessions, referrers, the countries their readers come from. It tells them what humans did. What it doesn't show is everything else. And everything else, it turns out, is interesting. I run a Cloudflare Worker that logs every request to a D1 database before passing it along. Every request: human, bot, crawler, scraper, agent. The Worker tries to classify each one, matching user-agent strings against a database of known bot signatures. What it can't classify, it logs as unknown. That second layer is where the detective work happens. ## Reading the evidence The 07:43 spike broke down like this: 202 of those 400 requests were for `.md` paths. Paths like `/when-bots-become-readers.md`, `/web-traffic-and-the-rise-of-llms.md`, `/measuring-traffic-machines-bots.md`. The Worker classified 192 of them as human, because the user-agent strings looked like browsers: Chrome 138, Firefox 115, Edge 114. Perfectly formed, perfectly plausible. But one user-agent hit 47 different `.md` paths in sixty seconds. Another hit 37. Both from the same two browser fingerprints, distributed across 25 countries. Then the robots.txt requests: 116 of them in the same minute. That's a preflight pattern, a swarm checking the rules before it reads the content. Chrome 114 hasn't been a current browser for a long time. Neither has Firefox 115. These are frozen strings, a signature of bot infrastructure that picks a browser version and pins it, never updating. The User Agent (UA) looks human. The behaviour doesn't. The conclusion assembled itself: a distributed scraper, running across a proxy network or botnet, using spoofed browser identities to avoid classification. Evasive, coordinated, and genuinely clever. ## The twist Here's where the detective story gets uncomfortable. Those `.md` endpoints don't exist by default in Ghost. I added them. A few months ago, as an experiment: serve each post as clean Markdown alongside the HTML version, reference them in `llms.txt`, see what happens. The idea was to make the content easier for AI systems to consume. Structured, clean, no JavaScript noise. The scrapers found them almost immediately. So did legitimate AI users, ChatGPT-User and OAI-SearchBot among them, reading the same paths through the same door. I set the bait. They smelled it. ## The idée fixe The reflex response to a traffic spike like this is defensive. Block the IPs, rate-limit the endpoint, add a CAPTCHA, harden the WAF. There is an entire industry built around that reflex. It rests on a premise worth examining: that keeping machines out is possible, and that it is worth the effort. Neither is quite true. A scraper that can distribute across 25 countries and rotate frozen browser UAs is not stopped by a robots.txt entry or a Cloudflare rule. It routes around friction the way water routes around a stone. And the content, once published on the public web, is going to be consumed by machine pipelines whether or not you make it easy. The more interesting question is what you can learn by watching it happen. The spike told me that my Markdown experiment is working, in the sense that it is attracting exactly the traffic it was designed for. It told me that the machine layer of the web is active, distributed, and more sophisticated than most people assume. It told me that the gap between what human analytics show and what the full request log shows is where the real picture lives. Blocking that traffic would have closed the window. Watching it left it open. ## Signal in the noise The thing about running a second logging layer is that most of what it catches is unremarkable. Googlebots, Bingbots, ChatGPT-User ticking through recent posts, the usual crawl of SEO tools and RSS readers. Noise. But the noise is the baseline. Without it, the 07:43 spike is invisible. With it, you can ask: what's different about this minute? Why these paths? Why this many countries? Why frozen UAs? The detective work is in the filtering, not the blocking. 🗒️ The .md endpoints at hoeijmakers.net are intentional. Each post is available as clean Markdown alongside the HTML version. The llms.txt file indexes them. This is an ongoing experiment in machine-readable publishing. * * * I Thought I Was Optimising for SpeedBuilding a caching layer for my blog turned into something else: a window into who actually reads it, and what reading even means now.Rob HoeijmakersRob HoeijmakersThirty Years of Caching, Sorted in an AfternoonHTTP caching never quite made sense, until AI tools made it legible enough to actually implement. And the reason it finally mattered: the audience had quietly changed.Rob HoeijmakersRob HoeijmakersMy Visitors Are Not All Human. That Is Fine.I built a traffic dashboard for my own site. What I found wasn’t alarming, it was interesting. A publisher’s notes on bots, borrowed identities, and editorial agency.Rob HoeijmakersRob HoeijmakersGuests That Should BehaveBots are modern guests. Most are welcome. But when they arrive in disguise with a real browser and spike your analytics, hospitality has limits. A Cloudflare story.Rob HoeijmakersRob HoeijmakersMarkdown, the WD-40 of Digital InformationMarkdown has barely changed in twenty years while everything around it was rebuilt. That’s not luck. It’s what happens when a format finds the exact sweet spot between content and meaning.Rob HoeijmakersRob Hoeijmakers