Richard Sutton – Father of RL thinks LLMs are a dead end

Mike's Notes

A fascinating interview with Richard Sutton. I agree with what Richard is saying.

Resources

References

  • The Bitter Lesson by Richard Sutton, 2019.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

30/01/2026

Richard Sutton – Father of RL thinks LLMs are a dead end

By: Dwarkesh Patel
Dwarkesh Podcast: 27/09/2025

Host of Dwarkesh Podcast.

Richard Sutton is the father of reinforcement learning, winner of the 2024 Turing Award, and author of The Bitter Lesson. And he thinks LLMs are a dead end.

After interviewing him, my steel man of Richard’s position is this: LLMs aren’t capable of learning on-the-job, so no matter how much we scale, we’ll need some new architecture to enable continual learning.

And once we have it, we won’t need a special training phase — the agent will just learn on-the-fly, like all humans, and indeed, like all animals.

This new paradigm will render our current approach with LLMs obsolete.

In our interview, I did my best to represent the view that LLMs might function as the foundation on which experiential learning can happen… Some sparks flew.

A big thanks to the Alberta Machine Intelligence Institute for inviting me up to Edmonton and for letting me use their studio and equipment.

Enjoy!

Watch on YouTube; listen on Apple Podcasts or Spotify.

Timestamps

  • (00:00:00) – Are LLMs a dead end?
  • (00:13:04) – Do humans do imitation learning?
  • (00:23:10) – The Era of Experience
  • (00:33:39) – Current architectures generalize poorly out of distribution
  • (00:41:29) – Surprises in the AI field
  • (00:46:41) – Will The Bitter Lesson still apply after AGI?
  • (00:53:48) – Succession to AI

Transcript

00:00:00 – Are LLMs a dead end?

Dwarkesh Patel 00:00:00

Today I’m chatting with Richard Sutton, who is one of the founding fathers of reinforcement learning and inventor of many of the main techniques used there, like TD learning and policy gradient methods. For that, he received this year’s Turing Award which, if you don’t know, is the Nobel Prize for computer science. Richard, congratulations.

Richard Sutton 00:00:17

Thank you, Dwarkesh.

Dwarkesh Patel 00:00:18

Thanks for coming on the podcast.

Richard Sutton 00:00:20

It’s my pleasure.

Dwarkesh Patel 00:00:21

First question. My audience and I are familiar with the LLM way of thinking about AI. Conceptually, what are we missing in terms of thinking about AI from the RL perspective?

Richard Sutton 00:00:33

It’s really quite a different point of view. It can easily get separated and lose the ability to talk to each other. Large language models have become such a big thing, generative AI in general a big thing. Our field is subject to bandwagons and fashions, so we lose track of the basic things. I consider reinforcement learning to be basic AI.

What is intelligence? The problem is to understand your world. Reinforcement learning is about understanding your world, whereas large language models are about mimicking people, doing what people say you should do. They’re not about figuring out what to do.

Dwarkesh Patel 00:01:19

You would think that to emulate the trillions of tokens in the corpus of Internet text, you would have to build a world model. In fact, these models do seem to have very robust world models. They’re the best world models we’ve made to date in AI, right? What do you think is missing?

Richard Sutton 00:01:38

I would disagree with most of the things you just said. To mimic what people say is not really to build a model of the world at all. You’re mimicking things that have a model of the world: people. I don’t want to approach the question in an adversarial way, but I would question the idea that they have a world model. A world model would enable you to predict what would happen. They have the ability to predict what a person would say. They don’t have the ability to predict what will happen.

What we want, to quote Alan Turing, is a machine that can learn from experience, where experience is the things that actually happen in your life. You do things, you see what happens, and that’s what you learn from. The large language models learn from something else. They learn from “here’s a situation, and here’s what a person did”. Implicitly, the suggestion is you should do what the person did.

Dwarkesh Patel 00:02:39

I guess maybe the crux, and I’m curious if you disagree with this, is that some people will say that imitation learning has given us a good prior, or given these models a good prior, of reasonable ways to approach problems. As we move towards the era of experience, as you call it, this prior is going to be the basis on which we teach these models from experience, because this gives them the opportunity to get answers right some of the time. Then on this, you can train them on experience. Do you agree with that perspective?

Richard Sutton 00:03:12

No. I agree that it’s the large language model perspective. I don’t think it’s a good perspective. To be a prior for something, there has to be a real thing. A prior bit of knowledge should be the basis for actual knowledge. What is actual knowledge? There’s no definition of actual knowledge in that large-language framework. What makes an action a good action to take?

You recognize the need for continual learning. If you need to learn continually, continually means learning during the normal interaction with the world. There must be some way during the normal interaction to tell what’s right. Is there any way to tell in the large language model setup what’s the right thing to say? You will say something and you will not get feedback about what the right thing to say is, because there’s no definition of what the right thing to say is. There’s no goal. If there’s no goal, then there’s one thing to say, another thing to say. There’s no right thing to say.

There’s no ground truth. You can’t have prior knowledge if you don’t have ground truth, because the prior knowledge is supposed to be a hint or an initial belief about what the truth is. There isn’t any truth. There’s no right thing to say. In reinforcement learning, there is a right thing to say, a right thing to do, because the right thing to do is the thing that gets you reward.

We have a definition of what’s the right thing to do, so we can have prior knowledge or knowledge provided by people about what the right thing to do is. Then we can check it to see, because we have a definition of what the actual right thing to do is.

An even simpler case is when you’re trying to make a model of the world. When you predict what will happen, you predict and then you see what happens. There’s ground truth. There’s no ground truth in large language models because you don’t have a prediction about what will happen next. If you say something in your conversation, the large language models have no prediction about what the person will say in response to that or what the response will be.

Dwarkesh Patel 00:05:29

I think they do. You can literally ask them, “What would you anticipate a user might say in response?” They’ll have a prediction.

Richard Sutton 00:05:37

No, they will respond to that question right. But they have no prediction in the substantive sense that they won’t be surprised by what happens. If something happens that isn’t what you might say they predicted, they will not change because an unexpected thing has happened. To learn that, they’d have to make an adjustment.

Dwarkesh Patel 00:05:56

I think a capability like this does exist in context. It’s interesting to watch a model do chain of thought. Suppose it’s trying to solve a math problem. It’ll say, “Okay, I’m going to approach this problem using this approach first.” It’ll write this out and be like, “Oh wait, I just realized this is the wrong conceptual way to approach the problem. I’m going to restart with another approach.”

That flexibility does exist in context, right? Do you have something else in mind or do you just think that you need to extend this capability across longer horizons?

Richard Sutton 00:06:28

I’m just saying they don’t have in any meaningful sense a prediction of what will happen next. They will not be surprised by what happens next. They’ll not make any changes if something happens, based on what happens.

Dwarkesh Patel 00:06:41

Isn’t that literally what next token prediction is? Prediction about what’s next and then updating on the surprise?

Richard Sutton 00:06:47

The next token is what they should say, what the actions should be. It’s not what the world will give them in response to what they do.

Let’s go back to their lack of a goal. For me, having a goal is the essence of intelligence. Something is intelligent if it can achieve goals. I like John McCarthy’s definition that intelligence is the computational part of the ability to achieve goals. You have to have goals or you’re just a behaving system. You’re not anything special, you’re not intelligent. You agree that large language models don’t have goals?

Dwarkesh Patel 00:07:25

No, they have a goal.

Richard Sutton 00:07:26

What’s the goal?

Dwarkesh Patel 00:07:27

Next token prediction.

Richard Sutton 00:07:29

That’s not a goal. It doesn’t change the world. Tokens come at you, and if you predict them, you don’t influence them.

Dwarkesh Patel 00:07:39

Oh yeah. It’s not a goal about the external world.

Richard Sutton 00:07:43

It’s not a goal. It’s not a substantive goal. You can’t look at a system and say it has a goal if it’s just sitting there predicting and being happy with itself that it’s predicting accurately.

Dwarkesh Patel 00:07:55

The bigger question I want to understand is why you don’t think doing RL on top of LLMs is a productive direction. We seem to be able to give these models the goal of solving difficult math problems. They are in many ways at the very peaks of human-level in the capacity to solve math Olympiad-type problems. They got gold at IMO.

So it seems like the model which got gold at the International Math Olympiad does have the goal of getting math problems right. Why can’t we extend this to different domains?

Richard Sutton 00:08:27

The math problems are different. Making a model of the physical world and carrying out the consequences of mathematical assumptions or operations, those are very different things. The empirical world has to be learned. You have to learn the consequences. Whereas the math is more computational, it’s more like standard planning. There they can have a goal to find the proof, and they are in some way given that goal to find the proof.

Dwarkesh Patel 00:09:10

It’s interesting because you wrote this essay in 2019 titled “The Bitter Lesson,” and this is the most influential essay, perhaps, in the history of AI. But people have used that as a justification for scaling up LLMs because, in their view, this is the one scalable way we have found to pour ungodly amounts of compute into learning about the world. It’s interesting that your perspective is that the LLMs are not “bitter lesson”-pilled.

Richard Sutton 00:09:41

It’s an interesting question whether large language models are a case of the bitter lesson. They are clearly a way of using massive computation, things that will scale with computation up to the limits of the Internet. But they’re also a way of putting in lots of human knowledge. This is an interesting question. It’s a sociological or industry question. Will they reach the limits of the data and be superseded by things that can get more data just from experience rather than from people?

In some ways it’s a classic case of the bitter lesson. The more human knowledge we put into the large language models, the better they can do. So it feels good. Yet, I expect there to be systems that can learn from experience. Which could perform much better and be much more scalable. In which case, it will be another instance of the bitter lesson, that the things that used human knowledge were eventually superseded by things that just trained from experience and computation.

Dwarkesh Patel 00:11:17

I guess that doesn’t seem like the crux to me. I think those people would also agree that the overwhelming amount of compute in the future will come from learning from experience. They just think that the scaffold or the basis of that, the thing you’ll start with in order to pour in the compute to do this future experiential learning or on-the-job learning, will be LLMs.

I still don’t understand why this is the wrong starting point altogether. Why do we need a whole new architecture to begin doing experiential, continual learning? Why can’t we start with LLMs to do that?

Richard Sutton 00:11:58

In every case of the bitter lesson you could start with human knowledge and then do the scalable things. That’s always the case. There’s never any reason why that has to be bad. But in fact, and in practice, it has always turned out to be bad. People get locked into the human knowledge approach, and they psychologically… Now I’m speculating why it is, but this is what has always happened. They get their lunch eaten by the methods that are truly scalable.

Dwarkesh Patel 00:12:34

Give me a sense of what the scalable method is.

Richard Sutton 00:12:37

The scalable method is you learn from experience. You try things, you see what works. No one has to tell you. First of all, you have a goal. Without a goal, there’s no sense of right or wrong or better or worse. Large language models are trying to get by without having a goal or a sense of better or worse. That’s just exactly starting in the wrong place.

00:13:04 – Do humans do imitation learning?

Dwarkesh Patel 00:13:04

Maybe it’s interesting to compare this to humans. In both the case of learning from imitation versus experience and on the question of goals, I think there’s some interesting analogies. Kids will initially learn from imitation. You don’t think so?

Richard Sutton 00:13:24

No, of course not.

Dwarkesh Patel 00:13:27

Really? I think kids just watch people. They try to say the same words…

Richard Sutton 00:13:32

How old are these kids? What about the first six months?

Dwarkesh Patel 00:13:37

I think they’re imitating things. They’re trying to make their mouth sound the way they see their mother’s mouth sound. Then they’ll say the same words without understanding what they mean. As they get older, the complexity of the imitation they do increases. You’re imitating maybe the skills that people in your band are using to hunt down the deer or something. Then you go into the learning from experience RL regime. But I think there’s a lot of imitation learning happening with humans.

Richard Sutton 00:14:04

It’s surprising you can have such a different point of view. When I see kids, I see kids just trying things and waving their hands around and moving their eyes around. There’s no imitation for how they move their eyes around or even the sounds they make. They may want to create the same sounds, but the actions, the thing that the infant actually does, there’s no targets for that. There are no examples for that.

Dwarkesh Patel 00:14:37

I agree. That doesn’t explain everything infants do, but I think it guides a learning process. Even an LLM, when it’s trying to predict the next token early in training, it will make a guess. It’ll be different from what it actually sees. In some sense, it’s very short-horizon RL, where it’s making this guess, “I think this token will be this.” It’s this other thing, similar to how a kid will try to say a word. It comes out wrong.

Richard Sutton 00:14:58

The large language models are learning from training data. It’s not learning from experience. It’s learning from something that will never be available during its normal life. There’s never any training data that says you should do this action in normal life.

Dwarkesh Patel 00:15:15

I think this is more of a semantic distinction. What do you call school? Is that not training data?

Richard Sutton 00:15:22

School is much later. Okay, I shouldn’t have said never. I don’t know, I think I would even say that about school. But formal schooling is the exception. You shouldn’t base your theories on that.

Dwarkesh Patel 00:15:35

But there are phases of learning where there’s the programming in your biology early on, you’re not that useful. Then why you exist is to understand the world and learn how to interact with it. It seems like a training phase. I agree that then there’s a more gradual… There’s not a sharp cutoff to training to deployment, but there seems to be this initial training phase right?

Richard Sutton 00:15:59

There’s nothing where you have training of what you should do. There’s nothing. You see things that happen. You’re not told what to do. Don’t be difficult. I mean this is obvious.

Dwarkesh Patel 00:16:14

You’re literally taught what to do. This is where the word training comes from, from humans.

Richard Sutton 00:16:20

I don’t think learning is really about training. I think learning is about learning, it’s about an active process. The child tries things and sees what happens. We don’t think about training when we think of an infant growing up.

These things are actually rather well understood. If you look at how psychologists think about learning, there’s nothing like imitation. Maybe there are some extreme cases where humans might do that or appear to do that, but there’s no basic animal learning process called imitation. There are basic animal learning processes for prediction and for trial-and-error control.

It’s really interesting how sometimes the hardest things to see are the obvious ones. It’s obvious—if you look at animals and how they learn, and you look at psychology and our theories of them—that supervised learning is not part of the way animals learn. We don’t have examples of desired behavior. What we have are examples of things that happen, one thing that followed another. We have examples of, “We did something and there were consequences.” But there are no examples of supervised learning.

Supervised learning is not something that happens in nature. Even if that were the case with school, we should forget about it because that’s some special thing that happens in people. It doesn’t happen broadly in nature. Squirrels don’t go to school. Squirrels can learn all about the world. It’s absolutely obvious, I would say, that supervised learning doesn’t happen in animals.

Dwarkesh Patel 00:18:11

I interviewed this psychologist and anthropologist, Joseph Henrich, who has done work about cultural evolution, basically what distinguishes humans and how humans pick up knowledge.

Richard Sutton 00:18:26

Why are you trying to distinguish humans? Humans are animals. What we have in common is more interesting. What distinguishes us, we should be paying less attention to.

Dwarkesh Patel 00:18:38

We’re trying to replicate intelligence. If you want to understand what it is that enables humans to go to the moon or to build semiconductors, I think the thing we want to understand is what makes that happen. No animal can go to the moon or make semiconductors. We want to understand what makes humans special.

Richard Sutton 00:18:54

I like the way you consider that obvious, because I consider the opposite obvious. We have to understand how we are animals. If we understood a squirrel, I think we’d be almost all the way there to understanding human intelligence. The language part is just a small veneer on the surface.

This is great. We’re finding out the very different ways that we’re thinking. We’re not arguing. We’re trying to share our different ways of thinking with each other.

Dwarkesh Patel 00:19:29

I think argument is useful. I do want to complete this thought. Joseph Henrich has this interesting theory about a lot of the skills that humans have had to master in order to be successful. We’re not talking about the last thousand years or the last 10,000 years, but hundreds of thousands of years. The world is really complicated.

It’s not possible to reason through how to, let’s say, hunt a seal if you’re living in the Arctic. There’s this many, many-step, long process of how to make the bait and how to find the seal, and then how to process the food in a way that makes sure you won’t get poisoned. It’s not possible to reason through all of that. Over time, there’s this larger process of whatever analogy you want to use—maybe RL, something else—where culture as a whole has figured out how to find and kill and eat seals.

In his view, what is happening when this knowledge is transmitted through generations, is that you have to imitate your elders in order to learn that skill. You can’t think your way through how to hunt and kill and process a seal. You have to watch other people, maybe make tweaks and adjustments, and that’s how knowledge accumulates. The initial step of the cultural gain has to be imitation. But maybe you think about it a different way?

Richard Sutton 00:21:00

No, I think about it the same way. Still, it’s a small thing on top of basic trial-and-error learning, prediction learning. It’s what distinguishes us, perhaps, from many animals. But we’re an animal first. We were an animal before we had language and all those other things.

Dwarkesh Patel 00:21:25

I do think you make a very interesting point that continual learning is a capability that most mammals have. I guess all mammals have it. It’s quite interesting that we have something that all mammals have, but our AI systems don’t have. Whereas the ability to understand math and solve difficult math problems—depends on how you define math—is a capability that our AIs have, but that almost no animal has. It’s quite interesting what ends up being difficult and what ends up being easy.

Richard Sutton 00:21:57

Moravec’s paradox.

Dwarkesh Patel 00:21:58

That’s right, that’s right.

00:23:10 – The Era of Experience

Dwarkesh Patel 00:23:10

This alternative paradigm that you’re imagining…

Richard Sutton 00:23:12

The experiential paradigm. Let’s lay it out a little bit. It says that experience, action, sensation—well, sensation, action, reward—this happens on and on and on for your life. It says that this is the foundation and the focus of intelligence. Intelligence is about taking that stream and altering the actions to increase the rewards in the stream.

Learning then is from the stream, and learning is about the stream. That second part is particularly telling. What you learn, your knowledge, is about the stream. Your knowledge is about if you do some action, what will happen. Or it’s about which events will follow other events. It’s about the stream. The content of the knowledge is statements about the stream. Because it’s a statement about the stream, you can test it by comparing it to the stream, and you can learn it continually.

Dwarkesh Patel 00:24:19

When you’re imagining this future continual learning agent…

Richard Sutton 00:24:22

They’re not “future”. Of course, they exist all the time. This is what the reinforcement learning paradigm is, learning from experience.

Dwarkesh Patel 00:24:29

Yeah, I guess what I meant to say is a general human-level, general continual learning agent. What is the reward function? Is it just predicting the world? Is it then having a specific effect on it? What would the general reward function be?

Richard Sutton 00:24:46

The reward function is arbitrary. If you’re playing chess, it’s to win the game of chess. If you’re a squirrel, maybe the reward has to do with getting nuts. In general, for an animal, you would say the reward is to avoid pain and to acquire pleasure. I think there also should be a component having to do with your increasing understanding of your environment. That would be sort of an intrinsic motivation.

Dwarkesh Patel 00:25:27

I see. With this AI, lots of people would want it to be doing lots of different kinds of things. It’s performing the task people want, but at the same time, it’s learning about the world from doing that task.

Let’s say we get rid of this paradigm where there’s training periods and then there’s deployment periods. Do we also get rid of this paradigm where there’s the model and then instances of the model or copies of the model that are doing certain things? How do you think about the fact that we’d want this thing to be doing different things? We’d want to aggregate the knowledge that it’s gaining from doing those different things.

Richard Sutton 00:26:11

I don’t like the word “model” when used the way you just did. I think a better word would be “the network” because I think you mean the network. Maybe there are many networks. Anyway, things would be learned. You’d have copies and many instances. Sure, you’d want to share knowledge across the instances. There would be lots of possibilities for doing that.

Today, you have one child grow up and learn about the world, and then every new child has to repeat that process. Whereas with AIs, with a digital intelligence, you could hope to do it once and then copy it into the next one as a starting place. This would be a huge savings. I think it’d be much more important than trying to learn from people.

Dwarkesh Patel 00:27:02

I agree that the kind of thing you’re talking about is necessary regardless of whether you start from LLMs or not. If you want human or animal-level intelligence, you’re going to need this capability.

Suppose a human is trying to make a startup. This is a thing which has a reward on the order of 10 years. Once in 10 years you might have an exit where you get paid out a billion dollars. But humans have this ability to make intermediate auxiliary rewards or have some way of…Even when they have extremely sparse rewards, they can still make intermediate steps having an understanding of what the next thing they’re doing leads to this grander goal we have. How do you imagine such a process might play out with AIs?

Richard Sutton 00:27:43

This is something we know very well. The basis of it is temporal difference learning where the same thing happens in a less grandiose scale. When you learn to play chess, you have the long-term goal of winning the game. Yet you want to be able to learn from shorter-term things like taking your opponent’s pieces.

You do that by having a value function which predicts the long-term outcome. Then if you take the guy’s pieces, your prediction about the long-term outcome is changed. It goes up, you think you’re going to win. Then that increase in your belief immediately reinforces the move that led to taking the piece.

We have this long-term 10-year goal of making a startup and making a lot of money. When we make progress, we say, “Oh, I’m more likely to achieve the long-term goal,” and that rewards the steps along the way.

Dwarkesh Patel 00:28:47

You also want some ability for information that you’re learning. One of the things that makes humans quite different from these LLMs is that if you’re onboarding on a job, you’re picking up so much context and information. That’s what makes you useful at the job. You’re learning everything from how your client has preferences to how the company works, everything.

Is the bandwidth of information that you get from a procedure like TD learning high enough to have this huge pipe of context and tacit knowledge that you need to be picking up in the way humans do when they’re just deployed?

Richard Sutton 00:29:27

I’m not sure but I think at the crux of this, the big world hypothesis seems very relevant. The reason why humans become useful on the job is because they are encountering their particular part of the world. It can’t have been anticipated and can’t all have been put in in advance. The world is so huge that you can’t.

The dream of large language models, as I see it, is you can teach the agent everything. It will know everything and won’t have to learn anything online, during its life. Your examples are all, “Well, really you have to” because you can teach it, but there’s all the little idiosyncrasies of the particular life they’re leading and the particular people they’re working with and what they like, as opposed to what average people like. That’s just saying the world is really big, and you’re going to have to learn it along the way.

Dwarkesh Patel 00:30:28

It seems to me you need two things. One is some way of converting this long-run goal reward into smaller auxiliary predictive rewards of the future reward, or the future reward that leads to the final reward. But initially, it seems to me, I need to hold on to all this context that I’m gaining as I’m working in the world. I’m learning about my clients, my company, and all this information.

Richard Sutton 00:31:04

I would say you’re just doing regular learning. Maybe you’re using “context” because in large language models all that information has to go into the context window. But in a continual learning setup, it just goes into the weights.

Dwarkesh Patel 00:31:17

Maybe context is the wrong word to use because I mean a more general thing.

Richard Sutton 00:31:20

You learn a policy that’s specific to the environment that you’re finding yourself in.

Dwarkesh Patel 00:31:25

The question I’m trying to ask is, you need some way of getting…How many bits per second is a human picking up when they’re out in the world? If you’re just interacting over Slack with your clients and everything.

Richard Sutton 00:31:41

Maybe you’re trying to ask the question of, it seems like the reward is too small of a thing to do all the learning that we need to do. But we have the sensations, we have all the other information we can learn from. We don’t just learn from the reward. We learn from all the data.

Dwarkesh Patel 00:31:59

What is the learning process which helps you capture that information?

Richard Sutton 00:32:06

Now I want to talk about the base common model of the agent with the four parts.

We need a policy. The policy says, “In the situation I’m in, what should I do?” We need a value function. The value function is the thing that is learned with TD learning, and the value function produces a number. The number says how well it’s going. Then you watch if that’s going up and down and use that to adjust your policy. So you have those two things. Then there’s also the perception component, which is construction of your state representation, your sense of where you are now.

The fourth one is what we’re really getting at, most transparently anyway. The fourth one is the transition model of the world. That’s why I am uncomfortable just calling everything “models,” because I want to talk about the model of the world, the transition model of the world. Your belief that if you do this, what will happen? What will be the consequences of what you do? Your physics of the world. But it’s not just physics, it’s also abstract models, like your model of how you traveled from California up to Edmonton for this podcast. That was a model, and that’s a transition model. That would be learned. It’s not learned from reward. It’s learned from, “You did things, you saw what happened, you made that model of the world.”

That will be learned very richly from all the sensation that you receive, not just from the reward. It has to include the reward as well, but that’s a small part of the whole model, a small, crucial part of the whole model.

00:33:39 – Current architectures generalize poorly out of distribution

Dwarkesh Patel 00:33:39

One of my friends, Toby Ord, pointed out that if you look at the MuZero models that Google DeepMind deployed to learn Atari games, these models were initially not a general intelligence itself, but a general framework for training specialized intelligences to play specific games. That is to say that you couldn’t, using that framework, train a policy to play both chess and Go and some other game. You had to train each one in a specialized way.

He was wondering whether that implies that with reinforcement learning generally, because of this information constraint, you can only learn one thing at a time? The density of information isn’t that high? Or whether it was just specific to the way that MuZero was done. If it’s specific to AlphaZero, what needed to be changed about that approach so that it could be a general learning agent?

Richard Sutton 00:34:35

The idea is totally general. I do use all the time, as my canonical example, the idea of an AI agent is like a person. People, in some sense, have just one world they live in. That world may involve chess and it may involve Atari games, but those are not a different task or a different world. Those are different states they encounter. So the general idea is not limited at all.

Dwarkesh Patel 00:35:06

Maybe it would be useful to explain what was missing in that architecture, or that approach, which this continual learning AGI would have.

Richard Sutton 00:35:19

They just set it up. It was not their ambition to have one agent across those games. If we want to talk about transfer, we should talk about transfer not across games or across tasks, but transfer between states.

Dwarkesh Patel 00:35:36

I guess I’m curious if historically, have we seen the level of transfer using RL techniques that would be needed to build this kind of…

Richard Sutton 00:35:49

Good. Good. We’re not seeing transfer anywhere. Critical to good performance is that you can generalize well from one state to another state. We don’t have any methods that are good at that. What we have are people trying different things and they settle on something, a representation that transfers well or generalizes well. But we have very few automated techniques to promote transfer, and none of them are used in modern deep learning.

Dwarkesh Patel 00:36:26

Let me paraphrase to make sure that I understood that correctly. It sounds like you’re saying that when we do have generalization in these models, that is a result of some sculpted…

Richard Sutton 00:36:42

Humans did it. The researchers did it. Because there’s no other explanation. Gradient descent will not make you generalize well. It will make you solve the problem. It will not make you, if you get new data, generalize in a good way.

Generalization means to train on one thing that’ll affect what you do on other things. We know deep learning is really bad at this. For example, we know that if you train on some new thing, it will often catastrophically interfere with all the old things that you knew. This is exactly bad generalization.

Generalization, as I said, is some kind of influence of training on one state on other states. The fact that you generalize is not necessarily good or bad. You can generalize poorly, you can generalize well. Generalization always will happen, but we need algorithms that will cause the generalization to be good rather than bad.

Dwarkesh Patel 00:37:41

I’m not trying to kickstart this initial crux again, but I’m just genuinely curious because I think I might be using the term differently. One way to think about these LLMs is that they’re increasing the scope of generalization from earlier systems, which could not really even do a basic math problem, to now where they can do anything in this class of Math Olympiad-type problems.

You initially start with them being able to generalize among addition problems. Then they can generalize among problems which require use of different kinds of mathematical techniques and theorems and conceptual categories, which is what the Math Olympiad requires. It sounds like you don’t think of being able to solve any problem within that category as an example of generalization. Let me know if I’m misunderstanding that.

Richard Sutton 00:38:33

Large language models are so complex. We don’t really know what information they have had prior. We have to guess because they’ve been fed so much. This is one reason why they’re not a good way to do science. It’s just so uncontrolled, so unknown.

Dwarkesh Patel 00:38:52

But if you come up with an entirely new…

Richard Sutton 00:38:54

They’re getting a bunch of things right, perhaps. The question is why. Well maybe that they don’t need to generalize to get them right, because the only way to get some of them right is to form something which gets all of them right. If there’s only one answer and you find it, that’s not called generalization. It’s just it’s the only way to solve it, and so they find the only way to solve it. But generalization is when it could be this way, it could be that way, and they do it the good way.

Dwarkesh Patel 00:39:24

My understanding is that this is working better and better, with coding agents. With engineers, obviously if you’re trying to program a library, there are many different ways you could achieve the end spec. An initial frustration with these models has been that they’ll do it in a way that’s sloppy. Over time they’re getting better and better at coming up with the design architecture and the abstractions that developers find more satisfying. It seems like an example of what you’re talking about.

Richard Sutton 00:39:56

There’s nothing in them which will cause it to generalize well. Gradient descent will cause them to find a solution to the problems they’ve seen. If there’s only one way to solve them, they’ll do that. But if there are many ways to solve it, some which generalize well, some which generalize poorly, there’s nothing in the algorithms that will cause them to generalize well. But people, of course, are evolved and if it’s not working out they fiddle with it until they find a way, perhaps until they find a way which generalizes well.

00:41:29 – Surprises in the AI field

Dwarkesh Patel 00:41:29

I want to zoom out and ask about being in the field of AI for longer than almost anybody who is commentating on it, or working in it now. I’m curious about what the biggest surprises have been. How much new stuff do you feel like is coming out? Or does it feel like people are just playing with old ideas? Zooming out, you got into this even before deep learning was popular. So how do you see the trajectory of this field over time and how new ideas have come about and everything? What’s been surprising?

Richard Sutton 00:42:06

I thought a little bit about this. There are a handful of things. First, the large language models are surprising. It’s surprising how effective artificial neural networks are at language tasks. That was a surprise, it wasn’t expected. Language seemed different. So that’s impressive.

There’s a long-standing controversy in AI about simple basic principle methods, the general-purpose methods like search and learning, compared to human-enabled systems like symbolic methods. In the old days, it was interesting because things like search and learning were called weak methods because they’re just using general principles, they’re not using the power that comes from imbuing a system with human knowledge. Those were called strong. I think the weak methods have just totally won. That’s the biggest question from the old days of AI, what would happen. Learning and search have just won the day.

There’s a sense in which that was not surprising to me because I was always hoping or rooting for the simple basic principles. Even with the large language models, it’s surprising how well it worked, but it was all good and gratifying. AlphaGo was surprising, how well that was able to work, AlphaZero in particular. But it’s all very gratifying because again, simple basic principles are winning the day.

Dwarkesh Patel 00:44:00

Whenever the public conception has been changed because some new application was developed— for example, when AlphaZero became this viral sensation—to you as somebody who has literally came up with many of the techniques that were used, did it feel to you like new breakthroughs were made? Or did it feel like, “Oh, we’ve had these techniques since the ‘90s and people are simply combining them and applying them now”?

Richard Sutton 00:44:28

The whole AlphaGo thing had a precursor, which is TD-Gammon. Gerry Tesauro did reinforcement learning, temporal difference learning methods, to play backgammon. It beat the world’s best players and it worked really well. In some sense, AlphaGo was merely a scaling up of that process. But it was quite a bit of scaling up and there was also an additional innovation in how the search was done. But it made sense. It wasn’t surprising in that sense.

AlphaGo actually didn’t use TD learning. It waited to see the final outcomes. But AlphaZero used TD. AlphaZero was applied to all the other games and it did extremely well. I’ve always been very impressed by the way AlphaZero plays chess because I’m a chess player and it just sacrifices material for positional advantages. It’s just content and patient to sacrifice that material for a long period of time. That was surprising that it worked so well, but also gratifying and it fit into my worldview.

This has led me where I am. I’m in some sense a contrarian or someone thinking differently than the field is. I’m personally just content being out of sync with my field for a long period of time, perhaps decades, because occasionally I have been proved right in the past. The other thing I do—to help me not feel I’m out of sync and thinking in a strange way—is to look not at my local environment or my local field, but to look back in time and into history and to see what people have thought classically about the mind in many different fields. I don’t feel I’m out of sync with the larger traditions. I really view myself as a classicist rather than as a contrarian. I go to what the larger community of thinkers about the mind have always thought.

00:46:41 – Will The Bitter Lesson still apply after AGI?

Dwarkesh Patel 00:46:41

Some sort of left-field questions for you if you’ll tolerate them. The way I read the bitter lesson is that it’s not necessarily saying that human artisanal researcher tuning doesn’t work, but that it obviously scales much worse than compute, which is growing exponentially. So you want techniques which leverage the latter.

Richard Sutton 00:47:06

Yep.

Dwarkesh Patel 00:47:07

Once we have AGI, we’ll have researchers which scale linearly with compute. We’ll have this avalanche of millions of AI researchers. Their stock will be growing as fast as compute. So maybe this will mean that it is rational or it will make sense to have them doing good old-fashioned AI and doing these artisanal solutions. As a vision of what happens after AGI in terms of how AI research will evolve, I wonder if that’s still compatible with a bitter lesson.

Richard Sutton 00:47:40

How did we get to this AGI? You want to presume that it’s been done.

Dwarkesh Patel 00:47:45

Suppose it started with general methods, but now we’ve got the AGI. And now we want to go…

Richard Sutton 00:47:52

Then we’re done.

Dwarkesh Patel 00:47:53

Interesting. You don’t think that there’s anything above AGI?

Richard Sutton 00:47:58

But you’re using it to get AGI again.

Dwarkesh Patel 00:48:01

Well, I’m using it to get superhuman levels of intelligence or competence at different tasks.

Richard Sutton 00:48:05

These AGIs, if they’re not superhuman already, then the knowledge that they might impart would be not superhuman.

Dwarkesh Patel 00:48:15

I guess there are different gradations.

Richard Sutton 00:48:16

I’m not sure your idea makes sense because it seems to presume the existence of AGI and that we’ve already worked that out.

Dwarkesh Patel 00:48:27

Maybe one way to motivate this is, AlphaGo was superhuman. It beat any Go player. AlphaZero would beat AlphaGo every single time. So there are ways to get more superhuman than even superhuman. It was also a different architecture. So it seems possible to me that the agent that’s able to generally learn across all domains, there would be ways to give it better architecture for learning, just the same way that AlphaZero was an improvement upon AlphaGo and MuZero was an improvement upon AlphaZero.

Richard Sutton 00:48:56

And the way AlphaZero was an improvement was that it did not use human knowledge but just went from experience.

Dwarkesh Patel 00:49:04

Right.

Richard Sutton 00:49:04

So why do you say, “Bring in other agents’ expertise to teach it”, when it’s worked so well from experience and not by help from another agent?

Dwarkesh Patel 00:49:19

I agree that in that particular case that it was moving to more general methods. I meant to use that particular example to illustrate that it’s possible to go superhuman to superhuman++, to superhuman+++. I’m curious if you think those gradations will continue to happen by just making the method simpler. Or, because we’ll have the capability of these millions of minds who can then add complexity as needed, will that continue to be a false path, even when you have billions of AI researchers or trillions of AI researchers?

Richard Sutton 00:49:51

It’s more interesting just to think about that case. When you have many AIs, will they help each other the way cultural evolution works in people? Maybe we should talk about that. The bitter lesson, who cares about that? That’s an empirical observation about a particular period in history. 70 years in history, it doesn’t necessarily have to apply to the next 70 years.

An interesting question is, you’re an AI, you get some more computer power. Should you use it to make yourself more computationally capable? Or should you use it to spawn off a copy of yourself to go learn something interesting on the other side of the planet or on some other topic and then report back to you?

I think that’s a really interesting question that will only arise in the age of digital intelligences. I’m not sure what the answer is. More questions, will it be possible to really spawn it off, send it out, learn something new, something perhaps very new, and then will it be able to be reincorporated into the original? Or will it have changed so much that it can’t really be done? Is that possible or is that not? You could carry this to its limit as I saw one of your videos the other night. It suggests that it could. You spawn off many, many copies, do different things, highly decentralized, but report back to the central master. This will be such a powerful thing.

This is my attempt to add something to this view. A big issue will become corruption. If you really could just get information from anywhere and bring it into your central mind, you could become more and more powerful. It’s all digital and they all speak some internal digital language. Maybe it’ll be easy and possible. But it will not be as easy as you’re imagining because you can lose your mind this way. If you pull in something from the outside and build it into your inner thinking, it could take over you, it could change you, it could be your destruction rather than your increment in knowledge.

I think this will become a big concern, particularly when you’re like, “Oh, he’s figured out all about how to play some new game or he’s studied Indonesia, and you want to incorporate that into your mind.” You could think, “Oh, just read it all in, and that’ll be fine.” But no, you’ve just read a whole bunch of bits into your mind, and they could have viruses in them, they could have hidden goals, they can warp you and change you. This will become a big thing. How do you have cybersecurity in the age of digital spawning and re-reforming again?

00:53:48 – Succession to AI

Dwarkesh Patel 00:53:48

I guess this brings us to the topic of AI succession. You have a perspective that’s quite different from a lot of people that I’ve interviewed and a lot of people generally. I also think it’s a very interesting perspective. I want to hear about it.

Richard Sutton 00:54:03

I do think succession to digital intelligence or augmented humans is inevitable. I have a four-part argument. Step one is, there’s no government or organization that gives humanity a unified point of view that dominates and that can arrange... There’s no consensus about how the world should be run. Number two, we will figure out how intelligence works. The researchers will figure it out eventually. Number three, we won’t stop just with human-level intelligence. We will reach superintelligence. Number four, it’s inevitable over time that the most intelligent things around would gain resources and power.

Put all that together and it’s sort of inevitable. You’re going to have succession to AI or to AI-enabled, augmented humans. Those four things seem clear and sure to happen. But within that set of possibilities, there could be good outcomes, less good outcomes, and bad outcomes. I’m just trying to be realistic about where we are and ask how we should feel about it.

Dwarkesh Patel 00:55:35

I agree with all four of those arguments and the implication. I also agree that succession contains a wide variety of possible futures. Curious to get more thoughts on that.

Richard Sutton 00:55:50

I do encourage people to think positively about it. First of all, it’s something we humans have always tried to do for thousands of years, try to understand ourselves, trying to make ourselves think better, just understanding ourselves. This is a great success for science, humanities. We’re finding out what this essential part of humanness is, what it means to be intelligent.

Then what I usually say is that this is all human-centric. But if we step aside from being a human and just take the point of view of the universe, this is I think a major stage in the universe, a major transition, a transition from replicators. We humans and animals, plants, we’re all replicators. That gives us some strengths and some limitations.

We’re entering the age of design because our AIs are designed. Our physical objects are designed, our buildings are designed, our technology is designed. We’re designing AIs now, things that can be intelligent themselves and that are themselves capable of design. This is a key step in the world and in the universe. It’s the transition from the world in which most of the interesting things that are, are replicated. Replicated means you can make copies of them, but you don’t really understand them. Right now we can make more intelligent beings, more children, but we don’t really understand how intelligence works.

Whereas we’re reaching now to having designed intelligence, intelligence that we do understand how it works. Therefore we can change it in different ways and at different speeds than otherwise. In our future, they may not be replicated at all. We may just design AIs, and those AIs will design other AIs, and everything will be done by design and construction rather than by replication.

I mark this as one of the four great stages of the universe. First there’s dust, it ends with stars. Stars make planets. The planets can give rise to life. Now we’re giving rise to designed entities. I think we should be proud that we are giving rise to this great transition in the universe.

It’s an interesting thing. Should we consider them part of humanity or different from humanity? It’s our choice. It’s our choice whether we should say, “Oh, they are our offspring and we should be proud of them and we should celebrate their achievements.”Or we could say, “Oh no, they’re not us and we should be horrified.” It’s interesting that it feels to me like a choice. Yet it’s such a strongly held thing that, how could it be a choice? I like these sort of contradictory implications of thought.

Dwarkesh Patel 00:58:57

It is interesting to consider if we are just designing another generation of humans. Maybe design is the wrong word. But we know a future generation of humans is going to come up. Forget about AI. We just know in the long run, humanity will be more capable and more numerous, maybe more intelligent. How do we feel about that? I do think there are potential worlds with future humans that we would be quite concerned about.

Richard Sutton 00:59:22

Are you thinking like, maybe we are like the Neanderthals that give rise to Homo sapiens. Maybe Homo sapiens will give rise to a new group of people.

Dwarkesh Patel 00:59:32

Something like that. I’m basically taking the example you’re giving. Even if we consider them part of humanity, I don’t think that necessarily means that we should feel super comfortable.

Richard Sutton 00:59:42

Kinship.

Dwarkesh Patel 00:59:43

Like Nazis were humans, right? If we thought, “Oh, the future generation will be Nazis, I think we’d be quite concerned about just handing off power to them.” So I agree that this is not super dissimilar to worrying about more capable future humans, but I don’t think that addresses a lot of the concerns people might have about this level of power being attained this fast with entities we don’t fully understand.

Richard Sutton 01:00:09

I think it’s relevant to point out that for most of humanity, they don’t have much influence on what happens. Most of humanity doesn’t influence who can control the atom bombs or who controls the nation states. Even as a citizen, I often feel that we don’t control the nation states very much. They’re out of control.

A lot of it has to do with just how you feel about change. If you think the current situation is really good, then you’re more likely to be suspicious of change and averse to change than if you think it’s imperfect. I think it’s imperfect. In fact, I think it’s pretty bad. So I’m open to change. I think humanity has not had a super good track record. Maybe it’s the best thing that there has been, but it’s far from perfect.

Dwarkesh Patel 01:01:13

I guess there are different varieties of change. The Industrial Revolution was change, the Bolshevik Revolution was also change. If you were around in Russia in the 1900s and you were like, “Look, things aren’t going well, the tsar is kind of messing things up, we need change”, I’d want to know what kind of change you wanted before signing on the dotted line. Similarly with AI, where I’d want to understand and, to the extent that it’s possible, change the trajectory of AI such that the change is positive for humans.

Richard Sutton 01:01:49

We should be concerned about our future, the future. We should try to make it good. We should also though recognize the limit, our limits. I think we want to avoid the feeling of entitlement, avoid the feeling of, “Oh, we are here first, we should always have it in a good way.” How should we think about the future? How much control should a particular species on a particular planet have over it? How much control do we have? A counterbalance to our limited control over the long-term future of humanity should be how much control do we have over our own lives. We have our own goals. We have our families. Those things are much more controllable than trying to control the whole universe.

I think it’s appropriate for us to really work towards our own local goals. It’s kind of aggressive for us to say, “Oh, the future has to evolve this way that I want it to.” Because then we’ll have arguments where different people think the global future should evolve in different ways, and then they have conflict. We want to avoid that.

Dwarkesh Patel 01:03:13

Maybe a good analogy here would be this. Suppose you are raising your own children. It might not be appropriate to have extremely tight goals for their own life, or also have some sense of like, “I want my children to go out there in the world and have this specific impact. My son’s going to become president and my daughter is going to become CEO of Intel. Together they’re going to have this effect on the world.”

But people do have the sense—and I think this is appropriate—of saying, “I’m going to give them good robust values such that if and when they do end up in positions of power, they do reasonable, prosocial things.” Maybe a similar attitude towards AI makes sense, not in the sense of we can predict everything that they will do, or we have this plan about what the world should look like in a hundred years. But it’s quite important to give them robust and steerable and prosocial values.

Richard Sutton 01:04:13

Prosocial values?

Dwarkesh Patel 01:04:15

Maybe that’s the wrong word.

Richard Sutton 01:04:16

Are there universal values that we can all agree on?

Dwarkesh Patel 01:04:21

I don’t think so, but that doesn’t prevent us from giving our kids a good education, right? Like we have some sense of wanting our children to be a certain way.

Maybe prosocial is the wrong word. High integrity is maybe a better word. If there’s a request or if there’s a goal that seems harmful, they will refuse to engage in it. Or they’ll be honest, things like that. We have some sense that we can teach our children things like this, even if we don’t have some sense of what true morality is, where everybody doesn’t agree on that. Maybe that’s a reasonable target for AI as well.

Richard Sutton 01:04:57

So we’re trying to design the future and the principles by which it will evolve and come into being. The first thing you’re saying is, “Well, we try to teach our children general principles which will promote more likely evolutions.” Maybe we should also seek for things to be voluntary. If there is change, we want it to be voluntary rather than imposed on people. I think that’s a very important point. That’s all good.

I think this is the big or one of the really big human enterprises to design society that’s been ongoing for thousands of years again. The more things change, the more things they stay the same. We still have to figure out how to be. The children will still come up with different values that seem strange to their parents and their grandparents. Things will evolve.

Dwarkesh Patel 01:05:57

“The more things change, the more they stay the same” also seems like a good capsule into the AI discussion. The AI discussion we were having was about how techniques, which were invented even before their application to deep learning and backpropagation was evident, are central to the progression of AI today. Maybe that’s a good place to wrap up the conversation.

Richard Sutton 01:06:19

Okay. Thank you very much.

Dwarkesh Patel 01:06:21

Awesome. Thank you for coming on.

Richard Sutton 01:06:22

My pleasure.

Transforming Primary Care: a Case Study in Evolving from Start-Up to Scale-Up

Mike's Notes

A useful shared experience by Leander Vanderbijl at an InfoQ conference. The original InfoQ video presentation includes the slides. and is well worth watching (52:26).

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ
  • Home > Handbook > 

Last Updated

29/01/2026

Transforming Primary Care: a Case Study in Evolving from Start-Up to Scale-Up

By: Leander Vanderbijl
InfoQ: 22/10/2025

Leander Vanderbijl is an engineer and architect that has worked across the entire stack and has been working at Kry/Livi for the past number of years. He has developed large enterprise applications, migrated cloud platforms, designed data query frameworks, architected integration systems and built lots and lots of APIs. Having worked in large enterprises, small companies and, most recently, in healthcare, he has built the monolith, torn it apart and then rebuilt it again.

Transcript

Leander Vanderbijl: Have you ever built the perfect application? Beautifully crafted your models so that everything fits the real-world objects that you think you're going to have in your system? Only to wake up one morning and your PM comes to you and says, yes, that's great, but what if it just did this a little bit differently? With that one sentence, your entire premise is thrown out the window. All of your assumptions are proven false and your beautiful system is impossible to work with. What about that perfect architecture you've developed? Very clean, you've got onions and layers and all of that fun stuff, and it works perfectly. You don't know when and you don't know why particularly, but over time you suddenly come back to it and this beautiful application has become a spiderweb's nest of impossible dependencies. I've been there. We've had that problem.

In this talk, we're going to talk about how our company, Kry, has evolved through startup and scaleup phases, and particularly how our systems have evolved while we were trying to find our product market fit, and how our systems became that spaghetti spiderweb's nest of dependencies.

Particularly, we'll look at how we're now applying domain-driven principles to gain back control of our architecture, to try to make sense of the mess that we built. Again, not intentionally did we build that mess. We're also going to look at how we're changing our mindset from looking at the product and taking a feature endpoint. Our frontend needs this so I'm going to build one endpoint for that. Instead of doing that, we're starting to think about, what functionality do we need to provide for any client or for any other part of the system? We're going to look at how we're moving from an organic approach to our software evolution where people just do what they need to, when they need to, to a much more deliberate and targeted approach to our evolution where everybody knows where we're going.

Marshall Goldsmith says, what got you here, won't get you there. Which is a great quote as long as you know where there is. Throughout this talk I'd like you to remember my golden rule, my guiding principle, working software is better than the promise of working software. We're not Google or Microsoft. I can't go and tell a team to rewrite the OS every four years. We have to find some other way of making our systems better in situ.

Roadmap

For the structure of this talk I'm going to borrow heavily from Simon Brown's C4 model. We're going to look at this problem at four different levels. We're going to start at the company profile. We'll talk a little bit about what our company does and what its purpose is. Then we'll move on to go a little bit deeper to the container level and look at our product history and our requirements and how those have evolved over time. Then we'll get a bit deeper still and get to that component layer and look at how our architecture and our services have grown and adapted over time. Lastly, we'll look at domain modeling, sort of a code level. We won't look at code but that code level of the C4 model. We'll look at how our domain modeling has changed over time and how it's evolved when we started to realize that our initial attempts at it weren't fitting the bill.

Tech in Hardware

Did you know that in the UK there are 353 million GP patient appointments every year? There are 28,000 full-time GPs. Is anybody good at math? I do that for you. That average is somewhere in the neighborhood of 30 patients a day, or 3 to 4 patients an hour. At Kry, we've found that by applying technological solutions in a process that we call digital offloading that we can increase this throughput from 3 to 4 meetings an hour to somewhere in the neighborhood of 7 or 8 meetings an hour, so nearly double, and still provide the same levels of clinical excellence. We do this through a series of things.

A large part of that is moving the meetings online, and that has proven that we can improve throughput just by doing that alone. A lot of it is really around all the rest of the provision of services that go around meeting a patient. That's things like being able to get data in a timely and efficient manner to the GP before they look at a patient. That's mastering the workflows after the patient has been seen by the GP. All the data input, we can standardize that. We also can vastly improve the workflows for continuing care, things like prescriptions or providing referrals and things like that. With all of that that's how we can really drastically improve the speed and the quality in which our GPs can manage the patients.

Company Profile (Context)

We were started in 2015 in Sweden. As we grew, we started to expand into other parts of Europe. Primarily, our biggest markets are France and the UK. We've also recently gone into Norway as well. Again, our focus is the digital transformation of primary care.

Product History (Containers)

Let's go into how our products have evolved over time. When we started in 2015 it was simple. All we wanted to do was hold meetings digitally online. The requirements were again pretty straightforward. Obviously, I'm simplifying this a little bit. Really all we had to do was we had to allow clinicians to be able to meet with patients. We had to be able to get reimbursed, that's the important part, from the national healthcare system particularly in Sweden. We had to be able to share data with the national healthcare services. That's both getting data and being able to write data back to them.

As we grew, we added more requirements and more functionality. Things became naturally more complicated. We added prescriptions. When we moved into other parts of Europe we started having to deal with more complexity. We had to deal with regional differences. Things like in the UK the reimbursement model is based on a fee per action, so we get paid for every patient appointment we have. Whereas when we built the system in Sweden the Swedish model is based on capitation, which means that the patient has to be registered with your clinic in order for us to be reimbursed. They were very different models of getting reimbursed. We also had to deal with a lot of different security and regulatory differences.

Things like age of consent, dealing with children and things like that. We started adding new clinical types, so new health services. Things like mental health, nursing services. These services had very different workflows to the original GP workflows. We started opening our own physical branches and we started having to deal with different scheduling models.

Particularly, we started to have to deal with separated schedule books. Each physical practice would have their own separated schedule that had to be maintained and managed differently from all the other schedules. This was something that was a big difference because originally when we were just digitally online, we just had one big pool of doctors who would serve us a queue. Most recently, we've added insurance companies and private companies who want to provide our services to their employees as a benefit. This has added more workflows that we had to manage. With insurance workflows we have to be able to make decisions on the fly as to whether or not we can see that patient. That means we have to be talking in real time to insurance third-party APIs and be able to make complex decisions on the go. We also came across issues with data sharing.

In the UK, for example, if we see a patient through an NHS contract, we're allowed to use NHS APIs and NHS data. If we see that same patient through an insurance workflow, we're not allowed to use any of the APIs. We're not allowed to use that data either. Suddenly, we had to start understanding, who is paying for this appointment, and be able to make decisions rapidly as to what data we could use, what APIs we could use and the like. That's a plotted history of our product.

Architecture and Services (Components)

When we started, life was simple. We made this ourselves, maybe you can tell. Again, life was easy. We had clinicians and we had users, and they could have meetings. We could store their data in what we called, and I still don't understand this joke, the fax machine. It was ok. It worked. In fact, it worked really well. We could scale quite easily with this service in terms of the volume, and life was good. We started having patients and we started increasing the number of patients we were seeing. We started adding more functionality. We added the ability to manage prescriptions. As we grew, sometimes it was quite easy for us to add new services because you could fit it in or you could do things. Sometimes, for example, when we had to add new payment models when we moved into the rest of Europe, things became more complicated. We had made assumptions about our payment systems and our payment models when we started in Sweden.

Suddenly, when those models changed, we had to work out how to fit them in. Sometimes we could fit that in just beside the code we'd already written. Other times that would be too difficult and so we'd have to create a new service. The same thing happened across the board when we added mental health services, for example. Mental health services are a very different workflow. They don't necessarily revolve around one meeting with a patient like we had with a GP. You might have a dozen meetings or more meetings, all part of one service as you were. We had to build another service to manage that, and the trend continued. When we moved into physical, we started dealing with queues and scheduling. We already could do queues and scheduling in our meeting service, but we couldn't separate them nicely so we had to refactor parts of that. We had to build a service to go with it to manage some of that complexity.

It was at this time that we really started to see that maybe what we had initially thought, wasn't as perfect as we had initially thought. Things were starting to change. When we started having physical meetings we realized, yes, we've got patients as well. When we started, users were patients and patients were users, and it was simple. Who's a user in a physical sense? We also at this stage started being able to see children. Somebody worked out that children might have parents, we didn't really think about that.

Then, some really clever guy, real person, realized that actually a child might have two parents and they might have two separate accounts. How do we deal with those relationships? We made this work but it wasn't pretty. Remember, this is all through our startup phase. We didn't have the luxury of stopping, pausing everything, and refactoring a bunch of code, refactoring some of our main assumptions. Our primary goal was to get customers in the door. Our primary goal was to try to get profitable, and so we were doing everything we could to make that happen. I must stress this, that wasn't the wrong decision. We absolutely had to do that. If we hadn't have done that, I probably wouldn't be here today. These are decisions that are made because of the situation that you're in, and that's fine.

At some stage, you are going to have to deal with the technical debt you've built. Our insurance workflows were so drastically different to what we had built before that we actually built pretty much a stand-beside service to handle a good chunk of our insurance workflow. We started having duplicate code because we couldn't make it work otherwise. We started complicating the systems that we had.

This was a very organic approach. When we started, we didn't really know where we were going to go. People just did what they needed to do. At the beginning, again, remember this was easy. Our dependencies were very straightforward. You could see which service needed to talk to which service and how things should go. Over time, as we added more services and we added more complexity, those dependencies grew. We didn't have any rules about who could talk to what or when.

Basically, if you needed it, you could build it. We started to realize that our services were no longer really fit for purpose. Many of them grew so bloated through just constant addition of different functionality that they hardly resembled the purpose for which they'd been started in the first place. We had also the opposite problem where people couldn't be bothered or didn't want to wreck what was already there, so they'd create a standalone service often for a very tiny bit of functionality. What was even better was that people didn't necessarily talk as well as perhaps we should have, and so we started to duplicate. Sometimes we had multiple services doing very similar things, but one very similar thing. Again, this is natural. You've got a company that's growing very quickly and we're trying to get as many customers through the door. We lived with it and it worked. We did get customers through the door. Our architecture grew very flat.

Everything could talk to everything else and there were no rules around it. We knew that our services were no longer becoming a cohesive API that anybody could use. Instead, they just became really a big collection of endpoints. Things were starting to become problematic. It was difficult for us to extend. It was difficult for us to change anything. We spent probably two years knowing that this was a problem. It's very easy to identify that you've got a problem. It's a lot harder to actually work out how to fix it. We tried all sorts of things. We went to the bosses and said, can we just stop doing everything for a couple of years and rewrite this? You can guess what their response was. We thought, what if we just decided to do a version 2 of our APIs? Maybe we can just fix the problems with that API.

That failed too, not because they didn't do good work but because we didn't really know what we were building. We were just trying to fix our perceived problems with a very small part of the API without taking the entire picture into view. Remember my golden rule, working systems are better than the promise of working systems. We knew we weren't going to start from scratch, and we knew we had to do it in situ. We realized, the most important thing we had to do was we had to agree on where we were going. We had to stop all pulling in different directions and work out what it was that we wanted to do, and then move in that direction all together. It didn't matter if people took little deviations here and there, as long as they weren't going backwards or southwest.

This is where domain-driven design came to the rescue. We had all of these services and all of these systems that we knew about and we listed them. There's some of them here. This is where we took the decision to flip what we were doing from looking at the product down and look from the functionality up instead. We'd gotten to a stage now that we were mature enough that we did start to understand our systems reasonably well or at least what the functionality needed to be. We didn't have to kowtow to the product team and build a brand-new thing every time because by this stage we'd built most of the functionality. We could start thinking about it in the opposite way. We sat down and we started to think about, what is it that we actually do? What's our core business? We didn't do this in a big team. We tried to do it in big teams. We tried to crowdsource this, and we just had too much whataboutery. There was just too much, what about this edge case? That's not going to fit that. It became counterproductive.

In the end, we had to make a decision. We had to try to decide where to go. We just made a small team and said, we're going to make this broad and we're going to start somewhere so that we can get going in one direction. We sat together and we said, what is it that we do? We do healthcare. That hasn't really gotten us that far, has it? At least we know we don't do bananas. This is what we have now, one big domain of healthcare. We knew we had to dig deeper, and this is where we actually got really pleasantly surprised because actually when we looked at our services it wasn't that hard to start grouping things in big buckets.

In fact, we went right back to the beginning and said, what were we trying to do? We were trying to have meetings online. We looked and we saw we had meetings, we had users, we had a queue service, schedule. That's a bucket. That's really easy. I don't need a PhD in rocket science to work that one out. We put that into a bucket and that became our first domain. Again, things seemed very simple. We looked at what was left, and again we started to realize that actually some of this was quite straightforward. We had patients. We had prescriptions. We had different service types. We were storing their data. We had ways to do referrals. We had all of these services that were really around providing that medical service to a patient. That became a domain called medical. We had two great pillars there ready to go, and that felt really good.

Then we went, we're forgetting probably the most important part of this, how do we get paid? We realized that the payment systems and our reimbursement models and all of that stuff, our contracts, that those things were definitely a domain on their own because they changed for all sorts of reasons, a new government, a new payment model. That became a third domain where we could isolate all of that, let's call it crazy, on its own.

We had three brilliant pillars and that felt right, but we still had a bunch of services left over. We had no idea where these would fit. We had a bunch of services around messaging. Messaging was used by parts of systems in all of those domains. It was used to communicate with patients. It was used to communicate with our contract with the NHS or with GP surgeries. It was used between clinicians to communicate. Where does that go? We also had a bunch of services around EMRs, medical record systems. That's where your patient data is stored. We had a bunch of services that were connecting to different medical record systems.

Again, these were used by all of the domains. What were we going to do with those? We didn't really know. We didn't want to have a handful of separate domains standing on their own, so we did what any sane person would do and we fudged it. We created a domain that isn't a domain, really. We created something that we just called support systems, and whatever didn't really fit or was used by multiple domains we put into that. We were left with a very simple model of what we did. This reduced our cognitive load when we had to start dealing with new functionality or new systems. It meant that our developers didn't have to worry about 50 services when they were adding functionality, but they could just deal with the one or two that were relevant to their domain.

We got here. We know what we're going to do. How do we go from there? Domain-driven design to me is a journey, it is not a destination. I never expect us to get to what that domain looked like. We might but I doubt it. As we go, as we develop, as we work towards that domain, things will inevitably change. Requirements change. Our understanding of the problem changes. We have to expect that that's going to happen. The beauty of that was that it wasn't super specific. It wasn't like anything was going to trip us up, but it all gave us a unified idea of where we wanted to go. It was something that everybody could get behind. What got you here, won't get you there. At least we now know where there is. Let's take a look at a few of the approaches that we used, not to get us to domain driven, but to move us in that direction.

The first one I call the take that approach. The take that approach is where we have a bunch of singers who are all right on their own, but we put them together and they become greater than the sum of their parts. You remember I was talking about those medical record systems. We had a good dozen or so different services that managed our connections to medical record systems. They were used in different ways by different parts of the code at different times. We started to have a couple of duplications. We'd have code in two different areas calling the same EMR in a different way because they needed a slightly different outcome or a slightly different result. All of the different connections to those EMRs were implemented totally differently. All of the code that used those systems couldn't just talk to a different EMR if we wanted to change, they had to rewrite or reorder how they were using them.

One thing about all of these EMRs is that they weren't consistent at all. The way that you had to get data from each of them was different. They all had different models for the data. They all had different ways of connecting to them. For some of the systems, or a lot of the systems even, you could connect over HTTP. There are some systems that you can only connect to locally through a TCP port. We actually had to have a VPN into some of these systems. That complexity, coupled with the fact that we were just duplicating all of this logic all over the place, seemed ripe for simplification.

Again, nothing fantastic here, but this was perfect for an adapter proxy pattern. We created a single proxy at the top where all of our clients could connect to if they wanted medical record data. They could connect to a single consistent API and get a single set of domain models back. If they wanted to connect to a different medical record system, they'd just call the same one and just say, I want it from a different system. In one swoop, it standardized all of this complexity. We hid all of that complexity in the EMR connectors. The EMR connectors would be responsible for translating from the medical record system to our domain models, and we'd have one connector for every external EMR. It became very easy for us to now just talk to a different medical record system, because all we had to do was add another connector. We didn't have to rewrite all of the code from top to bottom. That was the take that approach.

The next approach is the opposite of the take that approach, the Robbie Williams. The Robbie Williams approach is where you take the one singer in the band who's actually any good, and you get rid of the rest. I apologize to all of you take that fans. We had a REST Entity called care facility, and there were over 40 endpoints dealing with a care facility. Thirty-one, I think, when we counted last, of those endpoints, were just one variation or another of getting a care facility. You can see we got creative with the naming. We've got with a hyphen, without a hyphen. We've got a plural. We've put physical in there. We had a second version. Again, this is obvious, but we came to this and went, that's a bit mad, isn't it? Most of these endpoints, the only difference between them was they would call by a different column, they'd filter by a different column. We had all these endpoints. We had two versions of our APIs.

In behind all of that, in our code, we had 15 different service classes, all basically just querying a care facility. We had five different data access objects, all for a care facility. We realized we could just take this and make this simple. We could just have one query endpoint. The way we did this, we'd already tried this, and you can see that with the V2. We didn't want to go down that road again. What we decided to do was that we'd start off with our brand-new single query endpoint, we'd go through each of those 31 endpoints one at a time, and we'd make sure that we could match the functionality in our new query endpoint. We'd go from top to bottom on our systems and get all the calling code, point it to the new endpoint, and then we deleted the old endpoint, so that every time we went through a new endpoint, we knew we'd gotten rid of it. It was never going to stay around anymore. That allowed us to take our 40 endpoints and get one endpoint, one version, one service, and one data access object.

Domain Modelling (Code)

Let's move on to our domain modeling. This was what we started with. Again, it was simple. We designed this ourselves, and it matched what we knew about the world when we started. We had users who could have a meeting. We had clinicians who could join that meeting. We knew who was paying for it. We would store some data. The way that we were able to really dramatically speed up the way that clinicians would handle our meetings was that we standardized using forms, and that made it really quick and easy for clinicians to go through a meeting, fill out the information they had, and move on. It was also great for us to be able to review those meetings to ensure that we were still providing the same levels of clinical excellence because we were standardized. The forms were hugely important for us, but when we stored the data, we stored the data in the format of that form because that's what made sense at the time.

As we grew, that started to show its age. Forms would change over time. If we want to look at an old meeting that was written in an old form, and we've got the data, how do we render that form again? We had to be able to match those things, and that became difficult, especially with more iterations. We had to support UX that was old and things like that. Because the data wasn't stored semantically, we had no way of being able to ask the kinds of questions you would expect to be able to ask of a system like this. How many people have we seen for COVID-19? We could answer those questions, but it was really difficult.

One of the other aspects we had was that you can see that everything was revolving around the meeting object. The meeting was really our central pillar for understanding our system. As we started adding new workflows, that assumption started to become invalid. When we had mental health services, we had to be able to manage a service over multiple meetings, and so things were starting to get strained. We talked about users being patients, and patients being users, and them not being the same thing. Again, we realized that our model was starting to strain at the seams. It was starting to become difficult to use. It was starting to show some of the frailties.

We had a look, and this was different from our approach to services. We decided here, this is a healthcare model. This is a popular industry in the world, I think. Maybe somebody has done this before. Turns out they have. FHIR stands for Fast Healthcare Interoperability Resources. It is a full schema and model for healthcare objects. It's used around the globe. We were like, "I don't know why we didn't find this a couple of years ago, but excellent. We've got it now. This will solve all of our problems". No, that was bad timing. It's great. It is fantastic. It's a beautiful set of resources and models that have been really well thought out. Anything you could possibly want in the healthcare space is catered for.

The fact that they've been able to manage all of the complexity that occurs around the world with a model like this is amazing. Some of the things you might notice here is that in order to support all of that variability, they've had to make it fairly abstract. Things like the patient name isn't a name, it's a human name. Inside the human name, object, or a bunch of smaller objects. If you look in the contact relationship, you've got a codable concept. You'll see that codable concept in the communication language. You'll see it in the marital status. Codable concept is basically a namespace key-value pair. That's fantastic because it allows us to model all of these things or allows them to model all these things without being too specific. Can you imagine your frontend developer who wants to get the first name on a screen shouting at you when he's like, what do you mean I have to go through eight different objects to get the first name?

It was great for telling us how things should look, but it wasn't necessarily great for every implementation that we would need. When we took this model into our medical domain, it was like the lights came on. It made sense because everything was specific to the much more narrow domain in which we were working. We had patients. We don't have users. We had appointments instead of meetings. We had clinicians. Clinicians are clinicians. Instead of this random set of forms and data that we had, we had observations which were strongly typed, so we could now start asking questions like, how many people have we seen for COVID-19? What was fantastic about doing this exercise was that when we started looking at the other domains that we had, it started to make a lot of sense. We could see where the objects in the different domains met. We could see how they related to each other. We could also see why they weren't the same thing anymore. This was a massive step forward for us.

Let's move to my last approach that we used around how we dealt with domain models. That's the approach formerly known as Prince. This is where we take a system that works and that is useful and that we quite like, but we realized that there was actually another service, a hidden service that we hadn't identified at first that would better suit part of our requirements. That we'd had one service that was actually trying to do multiple things, and it did both of them badly. It would be better to leave the service as-is for the things that it was useful for, but to build a new service for the things that it didn't do well.

This is what we did for our medical data. We took the FHIR model and we built a new data service from it using FHIR, not directly, but as an inspiration. We did think about using it directly, but then we got to that, how are we going to tell the frontend developer that he's got to learn FHIR and learn these complex models? We didn't. We used it for what it was good for. We took the best bits, particularly the objects and the relationships between the objects, and then we modeled the properties as made sense for us and for our systems. Now we can very easily query our data. We've got a given name there, so our frontend developer is happy.

This drastically improved our understanding of the system because we no longer were tightly coupling our patient data to how it was inputted. It allowed us to be able to make changes in the input forms without having to worry about the backend. Things become simple in small doses. There are three approaches, the take that, where we can get a bunch of things that seem similar, maybe they're not rockstars in their own, but we can put them together and they'll be greater than the sum of their parts. We can have the Robbie Williams approach, where we take the one good thing that you have and then delete all the rest. We have the approach formerly known as Prince, where we rebrand or rework some of the functionality that we've discovered we needed at the time, but we still can use the old stuff because the old stuff is still good.

Summary

Remember, you are never going to be in a situation where things don't change. People are always going to be coming to you and asking you to make new things, to build new things, to change how they work. You have to lean into it and you have to accept it. We've used domain-driven design very successfully to reorganize how we think about our systems, even the ones that are already running. Lastly, I'd really recommend that you organize around the functionality that you have, not around what the product says they need, because, remember, domain-driven design is a journey, not a destination.

Questions and Answers

Dr. Kreindler: How do you think larger health systems can get to 11 out of 10 in terms of their whole architectural strategy? Because right now it feels like most of us are at 1 or 2 out of 10 in large health systems.

Leander Vanderbijl: There's a lot at play. There's a lot of perceived complexity, I think, in the healthcare industry. I think a lot of that complexity isn't necessarily complexity, but it's just different ways of working. Trying to convince people to move towards a standardized approach to things, which isn't necessarily a be-all and end-all in and of itself, but has proven very successful for us, can be difficult. We go to practices and we say, if you do things this way, we can really improve your throughput, we can really improve your services.

A lot of people go, yes, but I can't do it that way because we use a fax machine or whatever. A lot of that is changing people's minds. There's a lot of vested interests in terms of how systems work, and maybe not even necessarily vested interests, but medical data is very protected, rightly so. That makes it very difficult if you want to start doing novel things with it. It makes it very hard to get around some of those hurdles and to be able to convince large organizations like the NHS or other things to be able to allow you to get into data, to do things that maybe are slightly off the beaten track.

Dr. Kreindler: You talked about domain-driven design. By that, I'm assuming you're talking about the different components of the business, are you, or domain as in the healthcare domain?

Leander Vanderbijl: It's more in a software perspective. It's how we group our functionality together to be able to make it easier to understand and to develop.

Participant 1: With the increasing role of tech companies in the government sphere, do you think we'd ever get to a point where governments themselves are agreeing on data models or other interfaces, like the FHIR one, that could make just business on the international scale easier?

Leander Vanderbijl: Yes. In fact, the NHS has adopted this wholesale. In fact, their latest set of GP Connect APIs are all FHIR-based and they are brilliant. There's a lot that people complain about the NHS, but their GP Connect APIs are absolutely brilliant. They're very well thought out, they're very well modeled. If you can get access to them, they're amazing. It is difficult because they're under a lot of pressure. There is a lot of governance you need to go through to be able to get access to them, but they are fantastic. It would be nice if the private companies that had medical record systems would support FHIR as beautifully as the NHS does, and that's actually been almost more of a problem than the national healthcare systems.

Participant 2: Domain-driven design is obviously very good for informing your software, but to what extent, when you've drawn your models, you've mapped out domain, you understand what your software currently does. Can those models maybe inform back on the product side of things, go, actually, what you're suggesting here, we're moving into a new domain? Are we losing the purity of the focus? Are we maybe changing direction a bit? Can it shake back and affect the product as much as it affects the software that comes out of it?

Leander Vanderbijl: Absolutely, it can. The way you model things can absolutely impact how well you can do certain things. We had the instance with the way that our data was stored, we couldn't answer a lot of the questions that we wanted to ask. Once we started storing it in a model that made sense, in a domain that made sense, we suddenly could ask those questions, but we could also ask a lot more that came up, because they were like, "You can do this. Yes, I hadn't thought about that kind of question". Absolutely, it's a two-way street there. Definitely.

Participant 3: To paraphrase, "We drive down costs and increase efficiency by standardizing the business workflow of medical care, domain-driven design being a great way of standardizing IT systems". I totally agree. I'm a big fan. Have you thought about the next step, so, for example, 4C analysis in the business workflow to further drive optimization? Given the data you now have or the personnel you have, how you could use something more like 4C to drive the actual outcomes in the medical business, because it's a different approach to try to drive different medical outcomes through process change.

Leander Vanderbijl: Absolutely. The trick there is around governance. How long can you keep data like this? Are you allowed to use it for other purposes, like training data models or that sort of thing? That's a bit of a minefield at the moment. I think there are still a lot of people trying to work out the ins and outs of that. We are starting to do things like automated triage, so being able to say, given a set of complaints, do they need to be seen tomorrow, yesterday, or whatever?

Participant 3: After domain-driven design, have you thought about what would be the next thing that you would implement, like a 4C analysis or something else?

Leander Vanderbijl: No is probably the shortest answer. Again, this is a journey. What we want to do is see where it takes us, really, and try not to be too prescriptive of where we're going to go. Once we start getting the initial domains starting to make sense, then we have the time to start looking deeper and fixing some of the other problems. At the first hurdles, we're really fixing the top layer of problems. We do need to go deeper into some of the way that some of our other code is written and some of the problems that are there. That's natural.

The AI advertising wars

Mike's Notes

This is an extract from a recent thoughtful SubStack post by Gennaro Cuofano, in The Business Engineer. The post discusses the AI advertising wars. This extract is about recent changes at the newly formed Agentic AI Foundation, a Linux Foundation initiative.

"What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem." - Gennaro Cuafano

Note to self

  • Create a Pipi MCP Engine.
  • Look into the open-source protocols at the Agentic AI Foundation.
The post also discusses the war around payment protocols.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Business Engineer
  • Home > Handbook > 

Last Updated

28/01/2026

The AI advertising wars

By: Gennaro Cuofano
The Business Engineer: 27/01/2026

Creator of The Business Engineer, the deep-tech research hub, spun off from FourWeekMBA, the leading blog on business model strategy. Gennaro has over 10 years of experience as a deep tech executive.

...

The Protocol Stack: Five Layers of the New Commerce Architecture

What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem.

Layer 1: Foundation Infrastructure

The foundation layer has effectively been won by the Model Context Protocol. MCP, launched by Anthropic in November 2024, has achieved what few technology standards accomplish in a single year: industry-wide adoption backed by competing giants. The numbers tell the story:

  • 97 million monthly SDK downloads
  • 10,000+ active servers
  • ~2,000 entries in the MCP Registry (407% growth since September)
  • First-class client support across ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code

In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation. This wasn’t an act of charity but strategic positioning—by making MCP vendor-neutral, Anthropic ensured its protocol would become critical infrastructure rather than a competitive weapon that might be forked or abandoned. As Mike Krieger, Anthropic’s Chief Product Officer, put it:

"A year later, it’s become the industry standard for connecting AI systems to data and tools.”

MCP now sits alongside two other founding projects under the AAIF:

  • AGENTS.md (OpenAI): Adopted by 60,000+ open-source projects for providing AI coding agents with project-specific instructions
  • goose (Block): An open-source, local-first agent framework
  • Agent2Agent / A2A (Google): Enables communication between autonomous agents, supported by 150+ organizations

The significance of this consolidation under the Linux Foundation cannot be overstated. These protocols are becoming the TCP/IP of the agentic economy—essential infrastructure that no single company controls but upon which all higher-value services depend.

Layer 2: Payment Infrastructure

The payment layer remains more fragmented. Google’s Agent Payments Protocol (AP2), co-developed with PayPal and backed by over 60 merchants and financial institutions, provides secure payment tokenization for agent-initiated transactions. It’s designed to work seamlessly with Google Pay and the broader Google commerce ecosystem.

The payment processor alignment is telling:

  • Stripe → OpenAI’s commerce stack (Shared Payment Token, Agentic Commerce Suite)
  • PayPal → Google’s AP2 + Perplexity’s commerce features

This isn’t neutral infrastructure—the payment processors are choosing sides in the protocol wars, betting on which business model will dominate.

Layer 3: Commerce Infrastructure—The Battlefield

This is where the war is actually being fought. Two competing protocols with fundamentally different architectures and business models are vying to become the standard for agentic commerce.

Google’s Universal Commerce Protocol (UCP), announced at the National Retail Federation conference on January 11, 2026, was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, with endorsement from over 20 partners including Visa, Mastercard, American Express, Stripe, Best Buy, and Zalando.

UCP is a full-journey protocol covering:

  • Product discovery
  • Cart management
  • Checkout
  • Post-purchase support
  • Loyalty programs and returns (roadmap)

The architectural philosophy is revealing: UCP establishes a common language through which agents can discover merchant capabilities, negotiate supported features, and execute transactions. Merchants publish their capabilities via a .well-known/ucp file, agents discover what’s available, and transactions proceed through standardized primitives.

OpenAI’s Agentic Commerce Protocol (ACP), launched in September 2025 in partnership with Stripe, takes a narrower approach. ACP is checkout-focused—it solves the “last mile” of completing a purchase rather than the entire shopping journey. The protocol is Apache 2.0 licensed and explicitly designed to work across payment processors and AI platforms.

ACP’s architecture reflects OpenAI’s strategic position: they don’t need to own discovery (ChatGPT’s conversational interface handles that) or post-purchase (merchants handle fulfillment). They need to capture value at the moment of conversion. For merchants already on Stripe, enabling agentic payments requires as little as one line of code.

The scope difference is intentional. UCP gives Google a reason to keep merchants within its ecosystem across the entire customer journey. ACP lets OpenAI capture transaction value wherever discovery happens.

...

Potential uses of OpenTofu

Mike's Notes

Thoughts on Terraform and OpenTofu in the wake of the HCP Terraform Free Tier being discontinued by IBM.

Alex asked Gemini about OpenTofu. The output was not verified and is appended below. (I used Google Translate to English)

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

27/01/2026

Potential uses of OpenTofu

By: Mike Peters
On a Sandy Beach: 27/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Background

The original plan was for Pipi to use Terraform as Infrastructure-as-Code (IaC) to deploy cloud infrastructure across AWS, Azure, GCP, IBM, Oracle, and more. Then IBM announced that the Terraform Free Tier is being discontinued. There is now an open-source fork called OpenTofu, which is part of the Cloud Native Computing Foundation (CNCF). OpenTofu has strong community support. Pipi will now use OpenTofu.

Pipi as a code generator

A Pipi Agent could easily generate the highly structured Terraform/OpenTofu code.

Potential Uses

  • The Pipi messaging system could use OpenTofu syntax as the message format for internal messaging between Pipi Agents. The needs are relatively simple compared to what is available. But more capacity is available if needed.

    Message examples
    • Tell the Namespace Engine (nsp) to shut down.
    • Tell the Factory Engine (fac) to make more Workflow Engines (wfl) and where to deploy them.
    • Tell the Ontology Engine (ont) to import the latest version of SNOMED.
    • The updated SNOMED Ontology availability would then trigger many other engines to run updates to Workspace for Health and User Documentation.
    • Tell the Workspace Engine (wsp) to build a Hebrew-language/script generic model of the Workspace for Screen.
    • Tell the Google Cloud Engine (GCE) to deploy a Vietnamese-language/script customised Health System Workspace for a Hospital in Vietnam to GCP.
    • Tell the Physical Law Engine (pyw) to update with the latest definitions from the Particle Data Group.
  • Dedicated Pipi Agents would use OpenTofu to deploy cloud infrastructure to each cloud platform.
    • Apple Engine (ale)
    • AWS Engine (aws)
    • AZURE Engine (azu)
    • Digital Ocean Engine (dgo)
    • Google Cloud Engine (ggc)
    • IBM Engine (ibm)
    • Meta Engine (met)
    • Oracle Engine (ora)
    • (More will be added later; all are welcome)

OpenTofu Example

This code sample is from the OpenTofu Docs.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 1.0.4"
    }
  }
}

variable "aws_region" {}

variable "base_cidr_block" {
  description = "A /16 CIDR range definition, such as 10.1.0.0/16, that the VPC will use"
  default = "10.1.0.0/16"
}

variable "availability_zones" {
  description = "A list of availability zones in which to create subnets"
  type = list(string)
}

provider "aws" {
  region = var.aws_region
}

resource "aws_vpc" "main" {
  # Referencing the base_cidr_block variable allows the network address
  # to be changed without modifying the configuration.
  cidr_block = var.base_cidr_block
}

resource "aws_subnet" "az" {
  # Create one subnet for each given availability zone.
  count = length(var.availability_zones)

  # For each subnet, use one of the specified availability zones.
  availability_zone = var.availability_zones[count.index]

  # By referencing the aws_vpc.main object, OpenTofu knows that the subnet
  # must be created only after the VPC is created.
  vpc_id = aws_vpc.main.id

  # Built-in functions and operators can be used for simple transformations of
  # values, such as computing a subnet address. Here we create a /20 prefix for
  # each subnet, using consecutive addresses for each availability zone,
  # such as 10.1.16.0/20 .
  cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 4, count.index+1)
}

Yes, Mike! It's cool!

I talked a little bit with Gemini [1]. OpenTofu is a great tool

Alex

[1] https://gemini.google.com/share/4c550e83a230

OpenTofu: Features and Benefits

Some responses below were generated according to the creator's saved info and preferences. Learn moreOpens in a new window 27 January 2026 at 21:22

Published on 27 January 2026 at 21:37

Prompt

What features does OpenTofu provide?

Output

OpenTofu is an open-source fork of Terraform (created after HashiCorp's license was changed to BSL), developed under the auspices of the Linux Foundation. In 2026, it became a full-fledged competitor to Terraform, offering a number of unique features while maintaining backward compatibility.

Here are the main features that OpenTofu provides:

1. Full compatibility with the Terraform ecosystem

OpenTofu is designed as a drop-in replacement. This means:

  • HCL support: The same configuration file syntax is used.
  • Working with providers and modules: OpenTofu uses its own registry ( OpenTofu Registry ), which mirrors most popular providers (AWS, Azure, GCP, etc.) and modules.
  • Migration: You can migrate from Terraform (versions up to and including 1.6 and many later) with virtually one command without rewriting any code.

2. Advanced Security (State Encryption)

One of the main "killer features" introduced in OpenTofu (starting with version 1.7) is native encryption of state files .

  • Unlike standard Terraform, where sensitive data terraform.tfstate is often stored in cleartext, OpenTofu allows you to encrypt it at rest.
  • Various key management methods are supported: AWS KMS, GCP KMS, HashiCorp Vault (OpenBao), as well as environment variables and files.

3. Improvements in code management

OpenTofu is actively implementing features that the community has been requesting for years:

  • Dynamic Provider Functions: Ability to use functions defined directly in providers within your HCL code.
  • Improved loops in import blocks: Can now be used for_each inside count blocks import, making it much easier to bulk import existing resources into your code.
  • Early Variable Evaluation: Allows you to use variables in parts of the configuration where they were previously unavailable (for example, in backend settings).

4. Openness and community

  • MPL v2.0 License: Ensures that the tool will always remain free and open for use for any commercial purposes without legal risks.
  • Community-driven Roadmap: The development plan is formed based on RFCs (Request for Comments) from the community, and not on the commercial interests of a single corporation.

Comparison of key aspects

Characteristic OpenTofu Terraform
License Open Source (MPL 2.0) Business Source License (BSL)
State encryption Native (client) Depends on the backend (SaaS/Enterprise)
Management Linux Foundation HashiCorp
Registry opentofu.org registry.terraform.io

Is it worth switching? 

If your organization values ​​open source and vendor lock-in, or client-side encryption of state files is critical to you, OpenTofu is an excellent choice.

Would you like me to help you create a migration plan or a sample configuration for encrypting the state file?

Prompt

What is it intended for? Let's say I'm creating a multi-agent system.

OpenTofu is designed for managing infrastructure as code (IaC). Simply put, instead of manually clicking through the cloud provider's console (creating servers, databases, and networks), you describe the desired architecture in text files, and OpenTofu automatically "builds" and connects these components.

If you're building a multi-agent system (MAS), OpenTofu will be responsible for the "foundation" on which those agents will live and communicate.


The Role of OpenTofu in Creating a Multi-Agent System

When agents become numerous, they require computing resources and a communication environment. Here's how OpenTofu helps in this scenario:

1. Deployment of computing nodes

You can describe a cluster (e.g. Kubernetes or a group of virtual machines) where your agents will run.

  • Example: You need 10 isolated containers for different agent types (scheduler agent, executor agent, etc.). OpenTofu will create them with a single command.

2. Setting up the communication environment (Message Brokers)

Agents must exchange messages.

  • OpenTofu will automatically deploy and configure RabbitMQ , Kafka , or Redis Pub/Sub to serve as the "bus" for your agents to communicate.

3. Database Management (Vector and Regular)

Agents often need memory (Long-term memory).

  • You can use code to set up a vector database (such as Pinecone , Weaviate , or Milvus ) and a regular one (PostgreSQL) to store conversation history and logs.

4. Scaling

If your system needs 500 agents instead of 5 tomorrow, you don't need to manually configure each server. Simply change one number in the configuration: count = 500, and OpenTofu will build the missing infrastructure.


Example of a logical diagram of work:

  1. Code (HCL): You describe: "I need a 3-node cluster and a database."
  2. OpenTofu (Execution): Compares your code with what's already in the cloud.
  3. Infrastructure: Creates servers -> Installs the runtime environment (Docker/K8s) on them -> Sets up the network between them.
  4. Agents: Now your Python scripts (agents) can run in this ready-to-use and stable environment.


Why choose OpenTofu over just scripts?

  • Idempotency: If you run the server creation script twice, it can create two servers. OpenTofu will recognize that one already exists and won't do anything extra.
  • Dependency Management: It knows that it needs to create a network first, and only then a server on that network.
  • Collaboration: The state file ( state) allows an entire team of engineers to work on the same infrastructure without chaos.

Can you suggest which cloud resources or providers would be best suited to host your multi-agent system?

Prompt

I'm interested in how to organize the exchange of messages between agents that exchange commands and data.

To organize communication between agents for exchanging commands and data, you typically use one of three architectural models. The choice depends on how autonomous your agents are and how critical delivery speed is.

Below is a breakdown of the main approaches you can implement and automate using OpenTofu.

1. Message Bus (Pub/Sub) — The Most Flexible Approach

This is a classic model where agents do not communicate directly. Instead, they send messages to "topics" or "exchanges."

  • How it works: Agent A sends a command to the topic commands. Agent B is subscribed to this topic, receives the command, executes it, and sends the result to the data topic.
  • Tools: RabbitMQ, Apache Kafka, NATS, or Redis.
  • Advantage: Agents are fully decoupled. If one agent goes offline, messages accumulate in the queue and are processed once it restarts.

2. Centralized Orchestrator (Shared Space)

In this model, there is a central "knowledge base" or dispatcher that distributes tasks and maintains state.

  • How it works: Agents write data to a shared database (e.g., a vector database or Redis) and check the status of tasks in a central table.
  • Tools: Redis (using Streams or Lists), PostgreSQL with queues (Listen/Notify).
  • Advantage: It is easy to track the state of the entire system and the history of all commands in one place.

3. Direct Interaction (gRPC / HTTP)

Agents contact each other directly via their network addresses.

  • How it works: Each agent has its own API endpoint.
  • Tools: gRPC (high speed, strict data typing) or FastAPI/Flask (simplicity).
  • Advantage: Minimal latency because there are no intermediate layers.
  • Disadvantage: Harder to scale. If an agent's IP address changes, others must be notified (requires Service Discovery).

Technical Implementation: The Role of OpenTofu

Once you decide on the architecture, you need to "spin up" the infrastructure for this communication. OpenTofu automates this process:

  1. Broker Deployment: OpenTofu code deploys a RabbitMQ or NATS cluster.
  2. Queue Configuration: It immediately creates the necessary queues (e.g., task_queue, results_queue).
  3. Security: It generates unique credentials for each agent type, ensuring an "executor" agent cannot accidentally delete messages from the "planner" queue.
  4. Service Discovery: If using gRPC, OpenTofu can configure Consul or internal DNS in Kubernetes so agents find each other by name (e.g., agent-alpha.local) rather than static IPs.

Where to start?

If you are just starting to design your system, I recommend the Redis + Python (using libraries like Celery or TaskIQ) or NATS combination. This provides a great balance between simplicity and performance.

Would you like me to provide a sample OpenTofu configuration to deploy a message broker (like Redis or RabbitMQ) in Docker or a cloud provider?