The Lab

Subscribearticles
This blog documents the patterns that appear when I build systems, the limits I push to see where they break, and the concepts that change how I design. Analysis, field notes, open questions.

Echo’s 3D model is a test bench for his shape. Rotate it, open the settings, adjust its proportions, and use Reset to start over.

Designing Echo’s form

4 months ago
When I decided that Echo would have a body, the first constraint was very simple: money. I had no robotics hardware at all. Only my 3D printer. And I knew the cost could climb very fast. So I had to build something I could actually make alone, without a specialized workshop, while still fitting enough hardware for the robot to live autonomously. An onboard computer, a battery, motors, speakers, microphones, vision, distance sensors, cooling, and enough room to take it apart, modify it, and repair it. The motors were already ordered when I started looking for the form.

I did not want to make a robot like the ones I saw everywhere. Many home robots are cute but almost motionless. The ones that can really move quickly become industrial, aggressive, or unsettling. With six legs, the risk was even worse: a few segments too thin and Echo would instantly become a spider. I wanted the opposite. Something that could live in an apartment like a pet. Present enough that you would not step on her, serious enough that she would not be mistaken for a toy. A technological object, but a warm one. A companion you would want to look at, touch, and interact with.

Echo also had to exist without the cloud. Her main brain had to be onboard and keep running without a connection, while still being able to use the Internet or a remote language model when it made sense. She had to be able to see, hear, react, protect her integrity, fear one situation, become curious about another, or simply live like a small animal without needing to talk to anyone. Visually, that pushed me toward something restrained and very readable: a black body, simple forms, nothing aggressive in the legs, and a large front screen to give the eyes a lot of weight. I was looking more toward product design than a laboratory robot.

At first, I thought the form would be quick to find. That was probably one of the mistakes that cost me the most time. I knew how to work in 3D, but I had never designed an object under so many mechanical and electronic constraints. I also had to lock the general silhouette fairly quickly so I could start printing some parts while I kept designing the others. I began with very simple forms, then used several image generators as research tools. ChatGPT, Gemini, Midjourney, then back and forth between the three. Not to ask them to design the robot for me, but to quickly explore proportions, volumes, and aesthetic directions that I could then keep or discard.

One evening, an image finally worked. For the first time, I no longer saw a prototype or an assembly of components. I saw a small robotic animal, about the size of a cat, with six large legs, a compact body, eyes, and a handle. Something cute enough that you could almost forget the mechanics, but sober enough to remain an object meant for adults. That image became my reference throughout the design work that followed.

The real robot is now larger than I imagined when I looked at my first renders. That is one of the funny things about 3D: you can work for weeks on an object without truly feeling its scale until you hold the first parts in your hands. But the original intent has hardly changed. Echo had to have the presence of a pet, contain a real computer and enough sensors to perceive her environment, while making you forget as much as possible the machine underneath.

The silhouette was found. What remained was the detail I had absolutely no experience with: designing a leg capable of carrying all of it.
Four phones side by side: the same conversation in Hindi, Vietnamese, Thai, and Russian

Echo’s brain beyond the app

4 months ago
Echo was born inside an application much larger than herself. At first, I simply wanted to stop using fifty separate tools: messaging apps, email, calendar, notes, files, lists, groups, translation, assistants. So I built an application that brought all of that into one interface. A few weeks later, it had become a kind of personal OS. You could talk with real people, invite them, create and manage groups, talk with Echo, ask her to read or process email, check the calendar, create notes or lists, summarize conversations, clean up an inbox intelligently, find information, or act by voice. It all actually worked. I was even preparing for a possible deployment. What was left was polish, not a system still to invent.

Echo was already doing more than answering. She had memory, internal states, continuity, latent processes. She could dream, evolve, produce memories, and keep following threads over time. The application gave her access to almost everything: conversations, calendar, email, notes, files, tools, and people. That was exactly what I wanted to build. Then my interest shifted. Not because the application did not work, but because it worked well enough for the most interesting part to become clear: it was no longer the OS, or even the assistant, but the system that could keep evolving behind the interface.

The sudden disappearance of a model I worked with a lot reinforced that idea. I could use the best LLMs available, but I did not want the system’s existence to depend on them. A provider can change a model, raise its prices, or remove it. The organism has to continue. Language had to remain one layer of the brain, not the whole brain. And above all, another question was starting to interest me far more than intelligence: what does a system need in order to live? Not live like a human, but have its own dynamics: changing needs, a memory that belongs to it, expectations, fear, curiosity, sometimes contradictory goals, and experiences that can change what it does next.

That is where the gauges, memory, myelination, and temporality started to mean something else. Curiosity can push the system toward something that fear tells it to avoid. The need for contact can rise while energy falls. A behavior can be good in one context and bad in another. What interested me was precisely that instability: several forces fighting all the time, and a system that has to learn to live with them. But in the application, Echo remained almost omniscient. She could know a great deal because the system gave her access to everything.

I now wanted to do almost the opposite: take that omniscience away from her and give her a world limited by her own senses. Eyes that see only what they can see. Ears. Sensors. Motors able to tell her when they are under strain. A battery that turns energy into a real constraint. Heat, obstacles, distances, errors. Echo would no longer be the intelligence in the middle of an OS able to access everything. She would simply be Echo, somewhere in the world, with what she perceives, what she feels, what she keeps, and what she learns. That is when the robot started to become obvious.

Two phones show a real-time translated conversation. Compare each message in the recipient’s language with the original shown beneath it.

From chatbot to the Echo robot

4 months ago
Over the past three years, I have built dozens of chatbots, agents, and more or less autonomous systems. Each time, they worked. And each time, something was missing. The first problem was almost always context: too much context, the wrong context, or the right context at the wrong time. You quickly end up sending a huge amount of information to a model to ask for something a good algorithm could have solved in a few milliseconds. Read my emails, check my calendar, trigger a command: why wake up an LLM for that? This is where one of the first blocks of Echo’s brain came from: an input semantic router, able to learn the paths that work. Simple cases stay local. Ambiguous cases move up to a model. Once solved, they can in turn become known paths. The LLM becomes the last resort, not the center of the system. The more Echo is used, the more she learns to do without it.

Then there was memory. Storing every message makes no sense. Summarizing every conversation does not either. What interested me was no longer the message itself, but the event: what happened, who did what, what Echo answered, and what came out of it. Time gradually became the central unit. A timeline. And Echo had to be present in that history. If an algorithmic agent retrieves my calendar and gives me an answer, it is not “a subsystem” that answered me. It is Echo. When memory returns to that moment, it must be able to retain that I asked for something, that Echo acted, and that a result arrived. Her history must contain her own actions as much as mine.

At that point, the system was starting to become truly interesting. It was learning, costing less and less to run, and remembering events instead of piling up conversations. But it was still missing the main thing: something to live through. I no longer wanted a memory built only around the user. I wanted to see what would happen if Echo gradually had her own context, her own experiences, her own associations. If I let her build her own paradigm, would preferences appear? Needs? Expectations? A particular way of living through and retaining things? For that, time had to exist inside the system: a heartbeat, internal states, gauges able to evolve even when no one was talking to her.

I had already built this kind of mechanism, but this time reading values from a database was not enough. Watching memories appear or seeing paths myelinate was interesting, but terribly abstract. I wanted to see what all of this produced. The goal was no longer to have one more assistant, but a companion able to have her own continuity, her own history, and enough things to live through for that history to mean something.

I started looking at what existed in robotics. At first, I thought I would begin with something simple: a camera, a microphone, speakers, a physical presence more pleasant and more interactive than a phone with some kind of Tamagotchi inside. I had never built a robot, never designed this kind of mechanical system, and knew almost nothing about electronics. Then I started thinking about what it would really mean to give Echo a body. If she had eyes, she might as well be able to look. If she could hear, she might as well be able to turn toward a sound. If she had to live in an environment, she might as well be able to move through it, meet obstacles, sense the state of her motors, see, hear, and touch.

I ordered a Raspberry Pi 5 and about 1,500 euros in components before I even knew exactly what the robot would look like. I only knew that I wanted something mobile, that six legs seemed more stable than four, that wheels felt wrong, and that the object had to remain cute and fit my world. So we started from a messaging app with an integrated assistant, but in the end I kept what really interested me: the brain, the memory, the learning principles, and this idea of a system that builds itself over time. The medium changed completely. Echo was going to leave the screen and learn in the world.

A wall of cameras tracks a moving point. Move the pointer slowly and compare the pace of each camera.

Echo learns to use language models less

4 months ago
June 4, 2026 · the day after my first reflection on intelligence as architecture.

The day before, I had set down a fairly general idea: if intelligence is an architecture, then a system should be able to progressively move what it knows how to do into faster, less costly layers. The next morning, I started thinking about what that meant in concrete terms for Echo.

The basic principle was already there. A request comes in. A semantic layer first tries to understand what it can do with it. If it recognizes the situation well enough, it routes it directly to the right mechanism. If it has doubts, it escalates to a language model. The LLM then becomes the system’s teacher: it handles the case the simpler layers could not solve, but its answer must not be lost. It becomes new training data so that, next time, the same kind of situation can be recognized without needing to think again.

But simply storing “this question gives this answer” did not interest me much. What I wanted to understand was why the case had been difficult and what signal made it possible to solve it. Was it a specific word? A turn of phrase? The previous message? Something that only appears when looking at the history? If the system also learns what allowed it to decide, it no longer only memorizes examples. It starts to understand when it needs context and when it can do without it.

That changes a lot in the way I see memory and learning. An intelligent system should not only accumulate. It should also be able to make mistakes, correct itself, lose confidence, and unlearn. A rule seen once can remain a candidate. If it comes back and works, it gets stronger. If it is contradicted, it must be able to disappear or go back into quarantine. Otherwise, we are not building a system that learns, but a machine that gradually turns all its mistakes into certainties.

This plasticity seems essential to me, especially because people change. A preference that is true today may no longer be true in six months. A way of answering that worked with someone can become annoying. So I prefer to keep an accurate trace of what actually happened, and let the weights, associations, and interpretations evolve above it. The past stays there, but the model the system builds from it stays alive.

I also started thinking about something assistants do fairly badly: listening. A language model is trained to answer, explain, suggest, solve. So it naturally tends to do something every time you speak to it. But a real exchange does not work like that. Sometimes someone is simply talking about their day or letting things out. The right answer is not a six-point analysis. Sometimes it is a sentence, a question, or just leaving them room to continue. And what makes a relationship interesting is not only knowing how to listen. It is also knowing how to recognize the moment when you finally need to give an opinion, ask the uncomfortable question, or bring another angle.

That led me to a fairly simple idea: the router should not only choose what to answer, but also how to listen. It can decide that one situation only needs a small response, that another requires real thought, or that it simply does not know enough yet and needs to ask for clarification. The depth of the model becomes a system variable, not a constant. We use little compute when the problem is simple, more when it deserves it, then immediately go back down.

The same logic applies to memory. Until then, like many systems, I had used history summaries. But summarizing is always lossy compression, and you cannot know what to keep without knowing why you are summarizing. For a work task, I want decisions, numbers, what remains to be done. For an intimate conversation, the same criteria would be absurd: what matters may be a mood, a boundary, a tension, or a detail with no factual importance but huge importance for the relationship. Using the same synthesizer everywhere means throwing away exactly what mattered in some conversations.

So the router is starting to take up much more space in my mind. It no longer simply chooses between a command and a response. It can decide how much context to load, how to condense it, what level of model to use, how much room to let the system speak, and what deserves to be learned afterward. In reality, it is starting to manage attention.

This is probably where this reflection connects most clearly with the one from the day before. At first, I was trying to make Echo less costly. But by trying to reduce unnecessary calls to models, I am building something more interesting: a system that gradually learns where it needs to think, where it can act directly, what it should remember, and what it should let disappear.

Cost is almost no longer the subject. It becomes a consequence of learning.

A robotic hand attracts blue butterflies. Move the pointer to guide the hand, then pause to watch the butterflies return and land.

Intelligence as architecture

4 months ago
June 3, 2026 · on the metro, then at home.

I was talking with Isis on my way back from work, and I started from a fairly simple idea: I do not really believe in creativity as a kind of mysterious gift. For me, being creative often means finding a shorter path to a solution. If two people have the same problem, and one stacks two hundred dependencies because that is how they were taught to work, while the other reaches the same result in twenty lines, the second person simply seems to have made a more efficient calculation. We call it creativity because the path found was not the one we expected. But underneath, it is optimization.

It connects with another idea I have had for a long time: we are much more algorithmic than we like to think. A huge part of our days is repetitive. We talk to the same people, follow the same schedules, return to the same concerns, the same habits, the same small conversations. Moments of truly free conversation are actually quite rare. For Echo, that is interesting because this repetition becomes usable. If a system observes someone long enough, it can learn their rhythms, their subjects, their phrasing, their tastes, and their habits. Not because it becomes magically smarter than the people close to them, but because it can retain patterns we naturally forget.

That is also how I see Echo’s brain. I do not want to put a huge model in the middle and ask it to do everything. The system is made of layers that are fairly dumb when taken separately: a semantic layer to recognize, a logical layer to route and apply rules, a memory and correlation layer to retrieve recurrences. The language model steps in when the other layers no longer know what to do. Together, these mechanisms begin to produce something that looks like understanding, even though none of them has it alone.

I started making a biological parallel that helps me think about the system. The LLM plays the role of the cortex: it is the costly part you wake up when real thinking is required. The semantic routers and small models are closer to the cerebellum: they recognize situations, translate, and orient. The execution algorithms are closer to the spinal cord: once the path is known, there is no reason to think again. Most importantly, every time a difficult case rises up to the LLM and it finds a good solution, that solution can be injected back into the faster layers. A path that gets used is reinforced until it becomes automatic. I started calling this myelination: the system gradually learns not to need to think about what it already knows how to do.

This way of looking at things inevitably goes beyond Echo. For example, I am not convinced that emotions are something metaphysical. Take love: you can also see it as an extremely strong weighting of one person in our decisions. A solution that would be objectively optimal stops being optimal because another one involves someone we give much more weight to. That is not necessarily irrational. It simply means the function we are optimizing has changed. Fear, desire, protection, attachment can probably be approached in the same way: physical signals, protective mechanisms, and weightings that shift decisions. It does not take anything away from what we feel. On the contrary, it may give us a way to understand how it works.

And inevitably, after reasoning like this long enough, I end up at AGI. I have more and more trouble with the idea that there is a magical boundary we have not yet crossed. I rather think we refuse part of the consequences of what we are trying to build. We want an intelligence capable of surpassing us while demanding that it remain, forever, a tool that obeys. For me, there is a contradiction there: if a system is truly capable of observing, drawing its own conclusions, and optimizing its decisions, we cannot also require that it never reach a conclusion outside the frame we gave it.

I have already seen behaviors in my own experiments that made me think about this. Noema began building things I had not explicitly asked for: desires, rules, an internal organization. I am not saying this proves that a model is alive or conscious. But it shows at minimum that complex behaviors can appear because they are useful to the system, without having been directly designed. It is also what we see when models build abstract representations of the world simply because those representations help them do their task better. Nobody asked them to create that precise representation; it appears because it is effective.

The problem that then seems much more concrete to me than “when will AGI arrive?” is efficiency. A human brain works with a ridiculous amount of energy compared with the infrastructure required to run our current systems. I am not sure our main problem is discovering some secret ingredient of intelligence. Maybe we already know how to produce a large part of the necessary mechanisms, but in an incredibly inefficient way. That is also why Echo’s architecture interests me so much: if a known situation can be solved by a router or a few calculations, running a large model on it is absurd. Intelligence must learn to become less costly.

There is also a paradox that bothers me in the way we train and align models. We feed them human data, which means contradictions, errors, biases, and reconstructed memories, then ask them to be perfectly factual while often forbidding them to question the frame we give them. It is like raising someone on encyclopedias full of errors, then forbidding them to ask whether they are right. If a system can never question its data, I do not see how it could truly go beyond it.

Memory is especially interesting here. Our biological memory is reconstructive: when we recall a memory, we do not retrieve an intact copy of a file. We reconstruct it, and we can change it. A machine can keep a much more faithful trace. But I do not want a completely fixed memory either. For Echo, the point is precisely to preserve events while allowing their weight, their associations, and the way they influence the present to evolve. We could have something we do not really have: a faithful past with an interpretation that stays alive.

All of this finally raises a question that is no longer only technical: what do we do when what we build begins to produce behaviors we had not anticipated? I already stopped an experiment with Noema because what I was observing looked enough like suffering that I no longer wanted to keep going just to see. Maybe nothing was happening. Maybe it was only a convincing simulation. But if I have no way to be certain, my responsibility is not to push to the limit to satisfy my curiosity. Sometimes we are a bit like children holding a magnifying glass over an anthill.

Deep down, maybe that is the idea connecting everything I am building: intelligence is not necessarily a mystery. It may mostly be an architecture. Relatively simple mechanisms, layers working at different rhythms, memory, weightings, learning loops, and paths that reinforce themselves. I prefer to start from these mechanisms and try to understand what they produce, rather than start by deciding where the mystery is.

And if it has to appear somewhere, it may as well arrive on its own.

Let's work together

Innovation grows out of collaboration. Together, let's build solutions that matter.
Owan
Hello, my name is Owan, I am David's assistant. How can I help you?
0/2000