Thank you. Good morning. My title is 'Bigger Models or Smarter Teams'. It looks like a contest. It's not. My argument is that neither one is wrong and neither one is right. And it's important to frame that choice. And we're going to be looking at through this talk to the architectures that for intelligence basically and the future will use both in my opinion and we'll talk a little bit also of world models which basically encompass both. I learned the lesson kind of building the camera phone back in 1997. The breakthrough was not a bigger phone or a bigger camera or a bigger network or a bigger whatever. It was the cooperation between systems that were not necessarily meant to work together that demonstrating something important which is capability emerge from coordination and that's to me a very important piece of what we're talking about. And so that tension is something that I was thinking would be good to explore today. A large central model gives us something coherent in context. An orchestrated system gives specialized components explicit roles, independent challenge and accountability. Don't confuse an orchestrated system with a bunch of agents that interact with each other. We're going to talk about explicit roles and independent challenges and accountability. The real design question I mean when we're building something is not which architecture wins in the abstract really because that's kind of a theoretical thing is where do we need coherence and where do we need independent judgment? And that's really a very important part of this. As you well know, it's all about making predictions. And the best wizards don't always make the best predictions.
So, I'm going to stay concrete and I will compare these architectures and look how the world functions kind of in that light. So my second slide really is a very important slide is that we are not born unfinished and that's really the very important part. This is not by defect. It's because the baby has to pass through the birth canal and so needs a flexibility in the skull and the skull needs to be able to develop as a brain develops. And so the infant skull needs to accommodate a rapid brain growth afterwards. The broader point is that human intelligence does not arrive in a brain and it's there in a complete model. It develops through feedback, imitation, correction, language, pain, culture. Intelligence is not only what sits inside one's brain. It's also what happens through regulated and that's an important word here, regulated interactions with other people and with the world. And that's extremely important. So I'm not claiming here that models are children and that biology is the way to explain AI in many ways. You know I always say that the most important part of intelligence what I call organic intelligence which is our own intelligence. However, it's important to look at our organic intelligence and understand, you know, what's the step? And a lot of people are thinking it's more power, but perhaps it's a little different than that. The useful analogy is narrower is that the capability changes through interaction. A system can be corrected, challenged, and updated can become much more reliable than one that produces an answer from a fixed internal context. You could see already that I'm actually contrasting what I will call the God model with the orchestrated model in the way that they both are important for different reasons.
For decision system practitioners, this matters because we evaluate the model while ignoring the architecture around it. And that's really really important that is that who proposes basically the who challenges how the evidence is checked and who is allowed to stop the process matters as much as the model itself. There's much more to it than the model. And that's really important. Maybe the thing to remember is nature itself shipped our brain before finishing. It's the enclosure. It's like nature gave us that brain before finishing. It's maybe in a high-tech version of an agile launch if you're into agile software methodologies. So that gives us two legitimate architectures really and so my next slide is going to kind of not compare them and this is really important. I'm not trying to compare them. I'm just trying to look at the functionality on each side and see how we can choose and how we can select what we need for our own application. There's a real tradeoff: orchestration cost, time cost, tokens cost, engineering effort, operational complexity. More agents do not automatically mean more truth. In fact, poorly designed debate can amplify errors or create an expensive loop that never stops. A kind of an infinite loop. If you think about it, this orchestration is about in many ways create a creative positive debate as opposed to accepting truth for what they are.
A practical decision rule: when the cost of a wrong answer is modest and coherence is valuable is probably what I call the God model. I mean and by the way I'm calling it the God model. Don't think that it's I want to be respectful of everybody. It's just a good way to think about it. When a decision is consequential, multi-step, regulated or must be explained later, then an orchestrated independent explicit authority is really important and of course there is always a hybrid path that is available. The same strong foundation model can play several roles while external tools, rules and differently trained models can provide independence where it matters. So you know you could use as analogy an analogy people sailing on a sailboat. If everybody tries to grab the wheel at the same time, there's no way you're going to go to where you're supposed to go. And so the regulation, the rule-based approach is really important and so orchestration can coordinate identical or different models. And that's really an important piece. So this comparison table is not meant to show which is best or which is worse but rather help in choice for an application for example.
So my next slide is going to start examining the God model. So the god of gods is Zeus and this is a statue of Zeus. You can see and so well I've used Greek mythology actually as a metaphor because when the Greeks wanted to explain the world they saw an omnipotent god but he wasn't the only one but really the Zeus was the god of gods or at least the ones on earth. And then they couldn't explain everything and so they had to invent all these gods, all these spirits, all these things that explain and that's more of the distributed model and we'll talk about it as such. So the structural tradeoff appears when generation and verification inherit the same assumptions. If you ask a model to criticize itself and improve the answer it's much harder and you know think about yourself we can be critical of ourselves but it's very different than if you ask an objective observer and so the God model creates his own guard rails but in many ways is not as objective as an independent system. The same blind spot can survive both the proposal and the self-check. And that's really one of the challenges of the God model.
So the centralized model or God model is often there to be the correct default. I mean if you don't want to think about things then you'll use this but use it when one coherent answer is the objective when the action is reversible because if the action is not reversible then it's much more difficult. Take for example a self-driving car. Running into a tree is not reversible. As opposed to asking your system to build a budget for your company in a spreadsheet. That's reversible. And when external verification adds more cost than value, then the God model is a good model. And we escalate to orchestration when the risk profile requires. It's not because a multi-agent diagram looks more sophisticated or cool or whatever it is. A multi-agent diagram is not just a bunch of agents chatting with each other because that doesn't do much and we'll talk about how the interaction gets regulated and what orchestration really means. So it's clear that the God model is the most used model today and the simplest to implement. You know everybody can take a ChatGPT or Gemini or one of those and build their own system pretty quickly.
So let's talk now about the orchestrated model. So as I said about the orchestrated model, the Greeks created all these gods and spirits because that allowed them to explain what was going on and they were all having arguments and fighting each other or loving or hating each other etc. And so, you could argue that Zeus was a fairly poor orchestrator, but that kind of mixed both models at the same time. So orchestration is not several agents chatting and it is, and this is really important, it is regulated interaction. So the first role if you look at that little diagram that I got there is to propose. Then the second call it agent if you want is to challenge and look for failure modes etc. Then the third one is to verify and test the evidence and then apply the policy and get back to it in a closed loop and continue doing that. That is basically the regulated interaction. It's not just everybody doing something and then at the end hoping that something positive will come out. The roles must be independent. There has to be explicit dissent allowed. The handoffs must be regulated and the decisions must be auditable. And that's really important. Because as you know especially in enterprise applications or real-time applications like self-driving car whatever it is we want to understand what happens so that we can or the system itself can continue improving itself and so that cycle is really critical with orchestration that's a really important piece of the pie.
So now that we have kind of a God model and an orchestrated model, what's a world model? I mean, you know, you've heard from my good friend Yann LeCun who has been pushing that and telling people, you know, all these LLMs are great, but you know, think about the fact that that first analogy I talked about is that you're not born with everything in the brain. What you are is a product of what you started with but all the interactions with the world and basically it's the world it's sensing is the model and is acting and so it's the cycle of perceiving, simulating and act and learn and we learn in the world ourselves you know little kid touches something hot oh it's hot I burn myself and then you know that and so that's kind of a world model does not contain the material world. It contains a learned internal representation of how states evolve and how actions may change outcomes. So the physical loop itself starts as you could see from this little diagram from sensing. Sensors encode the current state imperfectly like any sensor and with noise. The model simulates what may happen next. The controller chooses an action. It's a controller. Then an actuator or a person, okay, executes it. The observed results returns as new evidence and feeds the loop and the system continues learning like that and that final step is the key like reality supplies the error signal. And that's really essential. The gap between prediction and outcome corrects the net estimate or policy. A world model is therefore not just a richer chatbot. It's part of a control loop. And this is the important part. It's all a control loop and of course it embraces both the God model and the orchestrated model. But that's really what the key is and so this is how intelligence is in general developed.
So as an example in a sleep environment for example that's something that in my company we work on we place sensors under mattress and with that we estimate movement heart rate respiration and sleep state. We also take environmental inputs such as temperature, air quality, humidity etc. And the system predicts whether a small change perhaps to the temperature in the room or to the shape of the bed or whatever it is will improve the state of the sleeper and this works in a closed loop. So it's basically a simple world model that's focused on one thing bio sensing or sleep or something like that. So it acts within defined safety limits and then observes what actually happened. So for practitioners three disciplines follow. You have to keep the sensed state separate from the model inferred state. Prefer small reversible actions when uncertainty is high. Think about the self-driving car and never confuse a confident simulation with evidence from the world. So, you know, we always think about reality and I'm running a PowerPoint here. And it's a very simple slideshow. I just decided to only use nine slides or something. And if you think about it, reality is the only participant in this meeting that can't be persuaded by my beautiful PowerPoint. So reality is reality. I can convince a lot of people through my eloquence or lack of it and but reality is reality and that's something that we practitioners in this world think about.
So I wanted to use a practical application for closed loop and so this has to do with sleep. I mean the reason I'm doing I'm not trying to we don't sell anything actually. We're a science-based technology company. We make technology basically. And so what I wanted to give is an example of how we can change common misperceptions. If you listen to everybody who talks about sleep these days, you'll find that most people will tell you, 'Oh, you just wake up when the sun shines and you go to bed within certain time and when the sun sets and you're all good and you're fine and everybody should have that schedule.' Well, is that the best way to think about it? And you start thinking about how we eat, how we sleep, etc. And how all that has been very much influenced by the realities of the industrial revolution. When in the times of the industrial revolution, people wanted to send people and keep them in factories for mass production. Well, they decided that having breakfast at 6:00 a.m. was the best thing. Getting into the factory at 8, working till 1:00 p.m., then getting a 30 minute break for food, then working another five hours or something, then back home eating dinner and going to bed. So basically that created that cycle both for food I mean for the way we eat three square meals so called and then the 8-hour mythical night of sleep that's not how historically things happen. There was something very different is that if you think about our 25,000-year-old stone age ancestors, some of them had to keep guard to make sure that the saber-tooth tiger wouldn't intrude and create massive damage in their cave and others had to hunt at night in the moonlight and you know there all these different terminologies that were developed that way. In other words, there is not one way for people to eat. There's not one way for people to sleep. So we call that the circadian cycle. And this is my next slide. And so fundamentally there are larks and there are night owls and there's a lot of people in between. All of them can be equally healthy and all of them don't need to be put on the same schedule. And so when we started studying that from a machine learning perspective, a deep learning machine learning perspective, we actually took the input of as you can see from the top on cardiovascular input, respiratory input, activity input, movement input, then light input, and then environmental input. Each one of them has its own logic is independent of the other, but together they and this is a little bit of a simplification, but together they paint a picture of how you perform. And so what we call here the COA, we COA stands for Knowledge Organizational Architecture, is the orchestrator. And the orchestrator looks at all that and basically compounds all of these rather than centralized all of these in a single number that we call the circadian score which centers your optimal time of day. Your noon if you want or midnight whatever you call it and it's different from all of us and it evolves constantly because it evolves in a loop so it's a combination of orchestration and world model and evolves in a loop so we looked at over 250 million nights of sleep and use of course machine learning to actually understand that and all the labeling that we needed to put together and try to extrapolate something that we could call a circadian score that would be useful to your average human who understands that although I have to be at work at 8, my ideal time to be at work should really be 10:30. And so hopefully over time this becomes something that helps people live a healthier and better life. A lark, someone who wakes up with a sunrise or a night owl, someone who works better at night. We know a lot of larks, lots of athletes, etc. And also lots of night owls, people like Einstein or Mozart were night owls. Or Margaret Thatcher actually she only slept four hours a night. So we know a lot of them and many of them can live a very healthy life and that's a really important thing. So I'm using this as an illustration of the practical use of world models together with orchestration to give an actually practical example.
So, I'd like to finish with a quote from one of my very very favorite scientists and my favorite book in the world is The Origin of the Species from Darwin. I think that we can apply a lot of it here. I'd like to remark first, this is kind of a clever remark, but a lot of people say that the species that survive are not the strongest and smartest, but the ones most responsive to change is Darwin. It's a paraphrase of Darwin. And so here I want to be a verifier in the sense of what we talked about in terms of orchestration and do justice to Leon Mangson in 1963 said that another version of Darwin's quote is that the species that survive are not the smartest or the strongest but the ones that are most responsive to change. And I think that is so appropriate for this talk because fundamentally what we're talking about is the responsiveness of the system and the ability the system to adapt to what it perceives as reality. And that's how I think the powerful models the specialized agent interaction and the regulated agent interaction through orchestration are so important. So my conclusion is pretty simple. Scale, centralize capability where it helps, distribute judgment where the consequences demand it and make the interaction accountable. And so the centralized capability, distributed judgment and that's really the key. The judgment the self-criticism of the system it doesn't perform as distributed judgment. So that kind of concludes my prepared remarks and I'm happy if you have any questions to entertain questions.
