A talk by Rajiv Chandegra (medical doctor and director of Annicha Labs) arguing that as AI commoditizes product-building, engineering's value shifts to complex, real-world problems. The speaker critiques reliance on fixed "harnesses" — predetermined structures imposed on problems — and proposes "adaptive engineering": harnesses that adapt in real time to shifting systems. The talk traces the limits of the current engineering paradigm, draws on complexity science to examine how natural and social complex systems behave, and explores the philosophy and practice of adaptive engineering as a next frontier. # Channel Identity Observations — "Beyond the Harness: A Journey Towards Adaptative Engineering" ## Speaker Self-Description (Explicit Claims) - The presenter identifies himself as **Rajiv**, a **practicing medical doctor in London** who has "been doing some AI engineering for the past few years." - He works **"through a company called Annicha Labs"** (spelled "Anitcha Labs" in the title), described as focused on "real world application... the future which is multi-agent multi-human multi-institutional collaboration." - He states he "started AI engineering about two years ago." > "Hello, I'm Rajiv. I'm a practicing medical doctor here in London and been doing some AI engineering for the past few years." ## Intended Audience - The talk addresses an audience assumed to already be **AI engineering practitioners** — familiar with harnesses like "Pi, Claude, Code, Cursor, CodeX," "LangChain," "Hermes," "Klein and Goose," and concepts like `agents.md` files, tool calling, and "loop engineering." - The speaker explicitly invites audience contact, suggesting a **peer/community conference or meetup setting**: > "I'd be really interested in hearing your thoughts on this and whether this is something that other people are also exploring. Please do reach out to me." ## Claimed Scope of the Channel/Content - The video presents a **conceptual design philosophy talk**, not a tutorial or demo. The speaker coins and defines a term: > "Adaptive engineering is the discipline of designing constraints to the extent that the harness emerges on its own, stabilizes, and adapts as needed in response to the changing environment in ways that you could not specify in advance." - Scope spans: critique of fixed-harness AI engineering ("Taylorism for AI"), complexity science (emergence, attractors, complicated vs. complex problems), a cited **Russell Ackoff** reference on "messes," and a forward-looking thesis about multi-agent systems meeting the physical world. ## Observable Presentation Patterns (Not Self-Described Claims) - **Conceptual/philosophical register**: extended metaphors (factory line, flock of birds, "more like a flame than a crystal," wetness of water) rather than code or hands-on demonstrations. - **Balanced framing**: repeatedly hedges that neither approach is superior — "one is not better than the other. It's just two different design engineering philosophies" — indicating a nuanced, non-promotional style. - **Coined terminology and distinctions**: "vertical intelligence" vs. "horizontal intelligence"; "adaptive at the design stage" vs. "adaptive during the run time," used to position the thesis against existing tools (Hermes, Pi). - **Honest treatment of failure modes**: lists risks of his own proposal (drift without selection pressure, monoculture, legibility collapse, loss of predictability). - **Credibility signals used**: reference to named tools and vendors, quotation of Ackoff, and his dual identity as physician-engineer; no product pitch or call-to-action beyond "reach out to me." ## Evidence Gaps - No curated metadata was supplied, so no channel-level claims (subscriber counts, channel description, series branding) can be observed — only this single talk. - Whether "Annicha Labs" content appears elsewhere on the channel is **not evidenced** in this material. # Delivery Observations: "Beyond the Harness" — Rajiv Chandegra ## Tone & Register - **Conversational-academic hybrid**: The speaker blends informal filler with conceptual vocabulary — e.g., "Um, and it's been remarkable at getting the most out of the latest models" sits alongside phrases like "ontological emphasis on the relationships." - **Hedged, first-person framing**: Frequent use of "I'd argue" ("I'd argue that this is where the real challenges are"), "I guess" ("And I guess if there's one takeaway here"), and "I mean" — softening claims rather than asserting them. - **Polite disclaimer habit**: The speaker repeatedly preemptively concedes to avoid seeming one-sided: > "And I want to be absolutely clear here. I don't mean that you can't customize harnesses. Of course, you can." > > "And one is not better than the other. It's just two different design engineering philosophies." ## Vocabulary & Recurring Terms - **Core repeated concepts**: *harness*, *emergence / emergent*, *adaptive engineering*, *fixed / factory harness*, *multi-agent*, *messy*, *real world*, *mid-engineering / mid-runtime*, *constraints*, *coupling*, *complex vs. complicated*. - **Repetition as emphasis device**: Key terms recur in near-identical constructions, e.g. "the real world is dynamic and messy" and later "the real world is messy, and it keeps changing." Also: "No bird has a flock in it" appears twice nearly verbatim. - **Coining language**: The speaker explicitly frames terms as his own: "what I coin as adaptive engineering." ## Teaching Habits & Structural Patterns - **Numbered/parallel framing**: "the future's going to be different in at least two ways. Number one... And number two is..." and "there are two kinds of problems. There are complicated problems... and there are complex problems." - **Analogy-heavy explanation**: Recurring concrete analogies for abstract ideas: - **Taylorism/factory**: "This is like a factory line though. Like think Taylorism for AI." - **Flame vs. crystal**: "It's more like a flame than a crystal." - **Bird flock** (used at least four times). - **Wetness of water** (used twice). - **Explicit signposting**: Frequent transitions announce structure: "So, let's look firstly at the current paradigm," "Before that, let's just take stock a bit," "This slide basically summarizes my entire talk." - **Definitional habit**: Pauses to define terms mid-flow: "just sort of stepping a bit back, um, defining exactly what a harness is." - **Memorable aphorisms**: Condenses arguments into quotable one-liners: > "the factory method is the right answer to a fixed problem and the wrong answer to a moving problem." > > "The harness becomes the ongoing output rather than the input." > > "governance without a governor." - **Distinction-drawing**: A recurring move is separating easily-conflated pairs — complicated vs. complex, vertical vs. horizontal intelligence, "adaptive at the design stage... versus adaptive during the run time," parts vs. relationships. ## Verbal Fillers & Delivery Quirks - Heavy use of **"um," "uh," "you know," "so," "and"** as connective tissue throughout — including run-on "and and" ("And And these are all differentiated," "And and and obviously goes without saying"). - The transcript records **[snorts]** and **[clears throat]** markers, indicating audible physical interruptions during delivery. - Occasional **self-correction mid-sentence**: "when when AI eventually, uh, when it becomes a norm for AI to capture real-world scenarios"; "It's uh in contact with multiple agents." ## Closing Pattern - **Invitational ending**: The talk closes by soliciting engagement: "I'd be really interested in um hearing your thoughts on this... please do reach out to me." ## Uncertainty Notes - Vocal tone, pacing, and gesture cannot be assessed from transcript alone; observations here are limited to lexical and structural features. - Filler-word frequency and the [snort]/[clears throat] markers suggest a somewhat improvised or lightly-scripted delivery, but the degree of scripting is not directly observable. # Position Record: "Beyond the Harness: A Journey Towards Adaptive Engineering" **Speaker:** Rajiv Chandegra (per video metadata), practicing medical doctor in London, AI engineer, founder of Annicha/Anitcha Labs. ## Central Thesis - Introduces a new design philosophy he coins **adaptive engineering**: allowing the harness to emerge, stabilize, change, and dissolve during runtime, rather than being fixed ahead of runtime. - > "Adaptive engineering is the discipline of designing constraints to the extent that the harness emerges on its own, stabilizes, and adapts as needed in response to the changing environment in ways that you could not specify in advance. Essentially, the harness becomes the ongoing output rather than the input." ## The Current Paradigm: Fixed Harness Engineering - Current AI engineering uses or builds a harness (Pi, Claude Code, Cursor, Codex) **ahead of runtime** with fixed roles, tools, and sequencing. - Harness components named: **system prompts** (vendor-established), **agents.md / Claude.md** files, **tool calling**, specialized agents, and recently **loop engineering**. - Definition: > "The model is the engine and the harness is everything built around to make that engine useful." - Harnesses differ by configuration and, more importantly, by design philosophy; they are **opinionated**. - Qualification emphasized: > "I don't mean that you can't customize harnesses. Of course, you can. But the customization occurs ahead of the engineering runtime... not mid-engineering." - Payoffs: **reliable**, **auditable**, **linear causality**. Analogy: "Think Taylorism for AI" / a factory assembly line. - Trade-off claim: reliability is bought by **suppressing variance**; determinism and emergence "pull in opposite directions." Key takeaway: > "The factory method is the right answer to a fixed problem and the wrong answer to a moving problem." ## Why Change Is Needed (Two Stated Drivers) 1. Models will become so powerful that fixed harnesses constantly become outdated — scaffolding may be irrelevant "in the next month." 2. **Real-world exposure**: AI will move off-screen into multi-agent, multi-human, multi-institutional, physical contexts, where the world is "dynamic and messy" and a fixed harness is "quite brittle." Bolting on rules for unanticipated situations leads to a harness "more complicated than the actual problem." ## Philosophical Grounding - Two worldviews contrasted: - **Reductionist/analytical**: world made of stable parts; relationships secondary — "the metaphysics of a factory and of nearly all software." - **Systems/relational**: relationships and processes come first; > "a stable thing really is just a slow pattern in an ongoing flow... more like a flame than a crystal." - Emergence examples: **wetness of water** (not present in H₂ or O₂), **flock of birds** (no bird "has a flock in it"; local rules — align, don't crash, stay close). - Quotes Russell Ackoff's concept of a **"mess"**: dynamic tangles of interdependent problems, not decomposable into tidy boxes. ## Complicated vs. Complex Problems - **Complicated** (jumbo jet, clock): analyzable, plannable, predictable by experts. - **Complex** (flock, market, organization): parts adapt to each other; must **probe–sense–respond**, not analyze and plan. - Claim: one of "the most expensive mistakes" in modern engineering is **treating complex problems as complicated** — failures come from miscategorization, not execution. - Complex system ingredients: **diverse agents**, **local interaction** (no agent sees the whole), **recursive learning/adaptation**, yielding **emergence** and **attractors** (stable states, e.g., water at room temperature). Crucially: "nobody's steering here. It's self-organizing." ## The Adaptive Engineering Vision - Simulation sketch: isomorphic, undifferentiated agents interact; at roughly **one connection per agent on average**, a whole system emerges. Engineer's lever: **rate of coupling** (dial up or dampen). - **Specialization emerges**: environmental pressure breaks ties between redundant agents; > "the agent's identity isn't something you gave it. It's actually the position, role, or capability it took relative to the others." - **Emergent clusters and boundaries** appear — "the system drew them, you didn't." Norms/protocols crystallize into **governance without a governor**, avoiding central-authority brittleness. - **Engineer's role**: relocated, not abolished — sets **constraints / rules of the game**, then senses and responds to the emergent harness rather than restarting. - Three constraint questions for engineers: - Enable agents more, or govern/guardrail them more? - Reward coherence toward a goal, or cost them for leaving a container? - How fast or slow (e.g., rate of coupling)? - Emphasized repeatedly: **a continuum, not binary**; > "one is not better than the other. It's just two different design engineering philosophies." Contrasts with a naive view of "a swarm of agents loose with no roles and this sort of intelligence that magically appears." ## Distinctions from Existing Tools - **Hermes AI** ("self-improving agent that creates skills from experience"): a step in the adaptive direction, but it is **vertical intelligence** (making individual agents smarter). His thesis concerns **horizontal intelligence** (group coordination), which he argues is "the most adaptive method... arguably the higher leverage point." - **Pi**: "minimal, yet maximally extensible" — adaptive **at the design stage**, but **not adaptive during runtime**; "it's not a self-organizing multi-agent system yet," though he notes it makes no claim to be. ## Acknowledged Failure Modes - **Attractors**: emergent stability may feel optimal without being best. - **Lack of genuine selection pressure**: without it, "you just get drift"; the community must find an analogue to evolutionary pressure. - **Monoculture risk**: agents trained on the same data may lack genuine diversity. - **Legibility collapse**: as adaptability increases, the system can't be pinned down or explained. - **No predictability ahead of runtime**. ## Closing Claims - As models improve, AI engineering moves into real-world, multi-institutional, physical contexts; the discipline will be "forced to rethink itself around continual production." - Limiting factor claim: > "The limiting factor... is not going to be the strength of the model. It's going to be the adaptability of the harness." - Adaptability means **decentralized multi-agent orchestration**, adapting mid-runtime — which he calls, in the harness-adaptability sense, "real intelligence." - Ends with an open invitation for others exploring these ideas to reach out. # Speaker & Provenance Observation Record **Video ID:** 01a15ca8-d214-797a-83ba-6d250d19c15d **Title:** Beyond the Harness: A Journey Towards Adaptative Engineering — Rajiv Chandegra, Annicha Labs ## Speakers & Roles - **Rajiv (Rajiv Chandegra)** — **Sole speaker; creator/presenter** - Self-identified: "practicing medical doctor here in London," AI engineering for "the past few years," affiliated with **Annicha Labs** (transcript spells it "Anitcha Labs" once; title metadata says "Annicha Labs") - No guests, narrators, or other identified speakers in the transcript ## Speaker's Claims About Self & Affiliation - Medical doctor in London - ~2 years of AI engineering experience - Interested in multi-agent, multi-human, multi-institutional collaboration - Coiner of the term "adaptive engineering" (self-claimed: "what I coin as adaptive engineering") ## Referenced Sources & Third-Party Claims - **Russell Ackoff** — quoted/paraphrased: managers are handed "dynamic situations, tangles of problems" — he "called it a mess" - **Hermes AI** — third-party claim cited from its website: "a self-improving AI agent that creates skills from experience and learns from it" - **Pi** — described as minimalist and "maximally extensible" harness; speaker notes it makes no claims to be a self-organizing multi-agent system - **Named harnesses/tools:** Claude Code, Codex, Pi, Cursor, LangChain, Hermes, Klein, Goose - **Concepts cited from complexity science:** emergence, attractors, complicated vs. complex systems, flocking local rules, wetness of water as emergent property — no specific published sources cited for these ## Third-Party Attribution Boundaries - Claims about Hermes AI and Pi are **vendor/product descriptions restated by the speaker**; not independently verified in the source - Ackoff quotation is paraphrased, not a verbatim quote ## Promotional Segments - **None detected.** No sponsorship, product promotion, or monetized segments in the transcript ## Comment / Feedback Availability - Speaker invites audience contact: "I'd be really interested in hearing your thoughts... please do reach out to me" - **No metadata on comment availability** was supplied ## Uncertainty Notes - Company name spelling conflict: transcript ("Anitcha Labs") vs. title metadata ("Annicha Labs") - No timestamps, dates, venue, or event context present in the source material Hello, I'm Rajiv. I'm a practicing medical doctor here in London and been doing some AI engineering for the past few years. Particularly interested in real world application and really the future which is multi-agent multi-human multi-institutional collaboration through a company called Anitcha Labs. And really the premise of my talk today is to introduce a new design philosophy for the future of AI engineering which is beyond a harness or beyond a fixed static harness and towards adaptive engineering. This slide basically summarizes my entire talk and really it's about exploring what the current AI engineering paradigm is which is to use fixed harnesses to steer agents. So we either use or build an existing harness like Pi, Claude, Code, Cursor, CodeX, whatever it is ahead of run time that remains fairly consistent throughout the engineering process and is largely constrained with fixed roles and tools and sequencing which again ahead of the process beginning of the process we can tweak and it essentially produces very reliable and orderly work and it's great for most engineering problems and ideas. And so your role as an AI engineering right now is to use a harness and steer agents. But the future's going to be different in at least two ways. Number one, models are going to become so powerful that existing fixed harnesses are constantly going to become outdated. And number two is there's going to be a huge exposure to the real world. Right now a lot of AI engineering is software based. It's within behind a screen. But actually, as things get more powerful, as models get more powerful, we're going to have exposure to the real world where I'd argue that this is where the real challenges are. And the real world is dynamic and messy. You know, it's full of multi-agent, multi-human, cross-institutional, and really touching the physical world, which means that a fixed harness is quite brittle. And so that's where we enter what I coin as adaptive engineering, where you actually allow the harness to emerge and adapt mid-engineering to find its most optimal position and structure. And essentially, the engineer's role is going to be to design some of the constraints, which are kind of the rules of play, and really allowing the harness to emerge, stabilize, change, and eventually dissolve as you go through the runtime of engineering. So, let's look firstly at the current paradigm for AI engineering. And it's essentially where a harness serves as the primary method to guide an LLM, which is typically stateless, and make it into something quite useful. And there's a couple of aspects of a harness, which I won't go to in detail, but essentially things like system prompts, which is established by the harness vendor, meaning that users can't actually modify it. And this essentially tells the harness what it can and can't do. You've also got the agents.md files or the Claude.md if you're using Claude code, which is loaded into every context window at the start of a session, tool calling, and essentially then you have the genesis of agents, which are specialized entities that have been harnessed uh, granting them unique capabilities um, and and allowing them to differentiate from other agents. And these capabilities are typically manifest as specific skills when it comes to role typology, their capabilities, the rules um, and that enables them to deliver targeted outputs and specified outputs, whether it be code documentation issues, handoffs and and most recently we've seen the genesis of kind of loops, loop engineering has become a thing um so that eventually we reach some sort of outcome uh, whether it's a feature, uh, a problem solved which is eventually reviewed by a human. Um, so what you see uh, from this is that before running the engineering process the entire harness has been predetermined or pre-engineered. And that's harness engineering. And uh, it's been remarkable at getting the most out of the latest models. Um and just sort of stepping a bit back, um, defining exactly what a harness is. Essentially the model is the engine and the harness is everything built around to make that engine useful. Um, there's many different types of harnesses. I mean, there's hundreds uh, actually, but I guess the most common ones are, um, you know, CLI coding, um, such as Claude Code, Codex, Pi. You have IDEs like Cursor uh, multi-agent orchestration through LangChain and and things like Hermes as well, Klein and Goose. And And these are all differentiated based on number one, properties and how they're configured. But actually more importantly, number two, based on some sort of design and engineering philosophy that they believe in. And what makes them so great and so distinct is that they are opinionated to a lesser or greater degree. Um and they allow for, I guess different use cases. Um and depending on your temperament as an engineer, you'd pick one over the other. But what we do see in all of these is that everything's predefined. You know, you can customize them, of course, like for example, the Pi agent. It's minimalist and it's maximally extensible. Um but everything is predefined. You know, the roles, fixed outputs, sequencing protocols, how memory is created. Uh and so I want to be absolutely clear here. I don't mean that you can't customize harnesses. Of course, you can. But the customization occurs ahead of the engineering runtime. Uh and not mid-engineering. And that's largely directed by us as humans. And for someone like me who started AI engineering about two years ago, it's probably the most powerful or predictive uh predictable method. And it's got really three payoffs. It's reliable. Um you know, the same input leads to a similar set of outputs. Obviously, there's going to be some variation. It's auditable. Um you can inspect exactly what changed and when. And there's some sort of linear causality where uh you know, if something breaks, you can actually trace it back to its source. Um this is like a factory line though. Like think Taylorism for AI. Just like a factory assembly line, every station is engineered in advance. Um, each agent has one job, a fixed place, a sequence, and maybe a defined handoff to the next agent. I mean, there's clearly some incredible uses for this and, you know, factory engineering gives you, you know, accuracy, speed, reproducibility, behavior that you can certify, and it really shines in these kind of closed deterministic systems, where you have a well-defined product or problem, and you know the kind of features you want to build. You know the sort of solutions that you need. Um, but here's the catch. Um, and and it's a real trade-off that that reliability isn't free. Um, you buy it by suppressing, um, variance that I'd argue novelty requires. Um, and determinism and emergence pull kind of in opposite directions. Um, and this is where we have to pivot to the real world, because in real life situations, in when when AI eventually, uh, when it becomes a norm for AI to capture real-world scenarios, where you've got multi-agents, multi-humans, multi-institutions interacting, and also touching the physical world, um, there's a hard ceiling on novelty, um, because the real world is messy, and it keeps changing. And so, fixed harness starts to break down. Um, so like I mentioned, there's a hard ceiling on novelty, um, because, uh, essentially, its reliability is predicated on suppressing variants. Um the models are going to keep accelerating. You know, you can build a careful harness today or you can use one off the shelf. But it could be irrelevant in the next month. The model just got so good that it didn't need that kind of scaffolding anymore. Um and that kind of leads to this whole dilemma of brutalness where every situation you didn't anticipated you didn't anticipate needs a human to patch the harness. The more real world it needs, the more rules you bolt on and eventually the harness just becomes ever more complicated than the actual problem that you need to solve. And I guess if there's one takeaway here is that the factory method is the right answer to a fixed problem and the wrong answer to a moving problem. And so let's really examine in what the real world is about and and I'm going to go down a bit of a philosophical route here. Um as we've said, you know, agentic systems will eventually collide with the real world and that raises a question. What is the real world actually made of? Because there's two ways to answer this actually. So the first paradigm, the first way to see the world is through what we call a reductionist or analytical view which we're all very used to actually. It says to understand the whole a big problem or a system or a big thing like an organization we've got to take it apart and study the individual parts. So essentially the world is made up of these individual parts which are things that are stable and change is just something that happens to those stable things now and then. The relationships amongst those things are secondary or an afterthought. And this is really the metaphysics of a factory and of nearly all software that we build. You know, you make the components. Uh you wire them together. And you get a product. The second paradigm, what we call the systems or relational paradigm, um takes the emphasis away from there being separate things or components and actually puts more what we call ontological emphasis on the relationships amongst those things. So, flips the order. It says that the real world isn't made up of things at all. It's made up of processes and um relationships which come first. So, what we call a stable thing really is just a slow pattern in an ongoing flow. Think an organism. It's more like a flame than a crystal. A flame looks like an object, but it isn't. It's a pattern held together moment by moment by a process. You stop the process and the thing doesn't exist. Uh and there's a really good payoff in understanding this paradigm. Um and once you see the world in this way, you start to notice something remarkable. Where where you have simple local rules between, let's say, particles or between people or between creatures, that local interaction gives rise to a whole new level of order that can't be predicted from its constituent parts and that no constituent part designed ahead of time. For example, water. Water has a property of being wet. But it's constituent parts, oxygen and hydrogen, are not wet. But their coming together, again putting emphasis on the relationships, their coming together is where you had the emergence of a novel new property, i.e. wetness. Another example is a flock of birds. Not one bird wakes up every morning intending to make a flock. Each probably just follows three simple local rules, which is align with your neighbor, don't crash into them, stay close, and that's it. Local rules, local interactions, and out of that you get a flock, a new pattern alive and coordinated that you could never understand by pulling it apart and studying one bird because no single bird has a flock in it. The flock lives in the relationships, not the parts. So this factory method of engineering assumes a world of parts. But the non-machine world, and I'd argue that AI is sort of on the cusp of that, the non-machine world is a world of patterns and moving patterns of emergence. And that sort of reflects what sort of problems we face in this moving messy world. Um and there's a line from Russell Ackoff that I absolutely love. He says that managers aren't handed neat separate problems. They're handed dynamic situations, tangles of problems that keep changing and keep bumping to each other. And he And he gave that a name. He called it a mess. A mess is a isn't just a pile of separate parts, it's actually a system of relationships in motion. Which is exactly why the factory based on a fixed harness way of engineering will struggle when it collides with real-world live scenarios. Because you can't decompose a mess into tidy boxes and solve each of them because they're not individual parts, they're a moving pattern of relationships. We can then look at problems through this this distinction between different types of problems. So, um engineering is all about solving problems and I'd argue that very simply put there are two kinds of problems. There are complicated problems um and there are complex problems. So, a complicated system or complicated problem is like building a jumbo jet or a clock. There are passive parts um but experts can take them apart, analyze them, plan, predict, document. It's hard, but it's actually knowable and it works in a very predictable way. In contrast, when you have a complex system or a complex problem like a flock of birds, a market, a human organization, it's slightly different. It's parts are constantly interacting and adapting to one another. So, the whole can't be derived from analyzing the parts. So, you don't analyze and plan a complex system. Instead, you probe and sense and respond and this is probably one of the most expensive mistakes we make in the modern world of design and engineering, which is that we treat a complex problem like a complicated one um and and things fail not due to lack of execution, but essentially because there's a failure in categorizing the problem spaces. If we go just one step deeper into what a complex system is, um essentially, you know, the ingredients of it are first, you need a diverse set of agents or actors if it's a human organization. Um not clones essentially, but different from one another in some sort of way. So, because the diversity is the fuel there. Um they need to interact locally uh cuz no agent, no individual actor, no individual component sees the whole. Um instead each respond to whoever's next to it. And this is like the bird aligning with the neighbor. And they learn. They learn recursively. They adapt, then they adapt to the results of their own adapting, and it constantly loops, and um you know, with respect to one another and the environment. Everything is moving in response to everything else, and nothing holds still. And out of all of that local adaptive looping interaction, you get something called emergence, which is a key concept in complexity science. Um basically, it's a new novel pattern uh or organization or behavior that uh no single part designed on its own and can't be explained by splitting that whole into its parts and studying them. Again, think the flock of birds. No bird has a flock in it. Think about the wetness of water. None of the individual oxygen hydrogen molecules have wetness within them. And yet, it leads to the emergence of something quite novel. Now, these systems don't fly apart into chaos. They tend to settle into attractors, which are essentially stable states. Uh they keep pulling back towards some sort of equilibrium. So, for example, water is stable at room temperature. So, you get this sort of beautiful tension. You've got constant change at a local level, but then you've got recognizable stable patterns at a whole system level. And crucially, nobody's steering here. It's self-organizing. And that's the whole mystery. And I'd argue that's the whole opportunity for design and engineering. And this is where really want to introduce this new design and engineering philosophy called adaptive engineering. Before that, let's just take stock a bit. So, everything we covered so far lives inside a particular framework, which is this kind of fixed or factory harness. Uh the human engineer decides it all up front, the sequencing, the roles, capabilities. That's really the factory model, and it works. Um and we've seen that um because problem spaces that are complicated yet predictable is exactly right. And I'd argue for most engineering problems, that is the perfect method. But the moment AI becomes exponentially better, and it collides with the real world, which is, as we found, messy and complex, not just complicated, we need something genuinely new, a different idea of what optimal design and engineering even is. Um And it's obviously it rests on those two assumptions that models have become become exponentially better. Uh and that AI will uh come outside of a sandbox situation, and actually um engineering will run in real time in contact with the social and physical environment. Um so, essentially what we're saying is that the harness must adapt mid-flow. And that's the crux of harness engineering. And I guess if I were to crystallize um the definition, um adaptive engineering is the discipline of designing constraints to the extent that the harness emerges on its own, stabilizes, and adapts as needed in response to the changing environment in ways that you could not specify in advance. Essentially, the harness becomes the ongoing output rather than the input. And you know, what this means in practice, uh just to make it a bit more concrete, is given that agents have capabilities um to interact with each other, organization emerges from those interactions in response to the environment or a goal, such that new levels of order appear, ones that you could never have specified up front. Um so, think bird in a flock, think agent and harness. So, the agents are actually creating the harness in the same way as the birds are relating to one another so that the flock can emerge. So, you don't build the harness anymore. You let the agents form the harness that best fits the environment in that moment, in that context. \>\> \[snorts\] \>\> The harness then becomes a self-organizing, constantly evolving multi-agent system. And if we're to just simulate what it may become, because this is when agents become a lot more capable. Um essentially, you have agents that are isomorphic um but yet undifferentiated. Um but fully capable of interacting and um learning and changing. Um you let those agents interact. At first, there's nothing. It's a bit of few exchanges here and there. But the coupling continues and slowly builds until you reach a point where roughly one connection on average um occurs um with each agent. And suddenly, you start to see this whole emerge. \>\> \[snorts\] \>\> Um a system, you could say. Uh and I guess as an engineer, your new lever uh becomes uh how the rate of coupling. Like, do you dial it up or do you dampen it down? Um again, the adaptive path focuses on the interactions. Um until, you know, agents start to actually specialize with respect to one another. So, let's say you got two agents doing the same thing in the same place. That's just redundant and the environment knows that. The pressure from the environment knows that. So, it rewards anything that essentially breaks the tie. Um so I guess a tiny difference um you know, who got there first, who is slightly better gets amplified by the feedback until those two agents are no longer interchangeable. And so, the pool stops becoming something uniform and it actually falls into uh niches. And really, the key insight here is that the agent's identity isn't something you gave it. It's actually the position, role, or capability it took relative to the others and its environment. So, here we see specialization emerges from the interaction. And if you go on a bit further, uh they stop connecting at random. Uh in fact, they start to work well together um, in terms of sort of clusters. Um, and you see the first boundaries appear and crucially the system drew them, you didn't as an engineer ahead of time. Um, so these are kind of emergent clusters. Um, until a new convention crystallizes, you know, a division of norms and protocols, and the system produce some level of governance without a governor. Conventions emerge spontaneously from the local coordination with no central authority because as we've seen, central authority can lead to brittleness in a changing environment. Um, so there's just enough repeated interaction to tip the group into some sort of shared norm. And this is crucial really because it means that it can continue to adapt in a decentralized way based on the changing environment or problem space. And essentially a new um, emergent order um, arises from those tiny little interactions amongst those agents, you have a new level of organization that is fairly stable up until the next iteration, up until the environment changes and um, the order needs to essentially restructure itself. So the question is that what is the role of an engineer? And and really in adaptive engineering, uh, you don't abolish the engineer, you're just relocating the emphasis of engineering. So if you can exploit the model's capabilities, um, so agents can essentially um, interact, learn, and change. What you're doing as an engineer is essentially um, exploring the constraints, you're dictating the constraints, the rules of the game. You're not deciding what should happen or what you want to happen, but you're giving the agent space to explore that field. \>\> \[clears throat\] \>\> And then, once that emergent harness uh starts to take shape, you are sensing it and responding to that rather than um stopping the engineering process and starting from scratch. Um And I think this slide sort of um portrays that. This is not binary, this is not either or. Uh in fact, it's very much a continuum. Um if you you there's no purely fixed harness way, and there's no purely uh completely adaptive autonomous way. Um fixed engineering is essentially in one hand um prescribing the structure, which agents run and you rarely change the structure mid-engineering. Um whereas on the other end of the scale, you've got adaptive engineering where you allow the agents to freely interact and allow the harness or the structure that guides them uh to be created by them and change mid-engineering. Uh so it's not like a swarm of agents loose with no roles and this sort of intelligence that magically appears. Um and it's not sort of better one one way is not better than the other. They just have two different use cases. And um if I could just, you know, bring it back to some examples of existing uh harnesses, so for example, Hermes AI um on on their website, it states that it's a self-improving AI agent that creates skills from experience and learns from it. So, obviously, this is a huge step in terms of adaptive direction. Um but I do want to make a distinction here um because um that adaptation is in the form of vertical intelligence, which is about making individual agents smarter. What I'm talking about here is horizontal intelligence, which is all about how groups of agents coordinate. And so, those two directions are a bit orthogonal. Um And the thesis I'm presenting is that it's horizontal intelligence uh that is the most adaptive method, the most agile method. Um and and and arguably the higher leverage point. Uh compared to vertical. Um Another example is Pi, um you know, a great harness, uh which is uh sort of essentially minimal, um yet it's maximally extensible. Um so, it's fully customizable to an extent. Um so, you could class that as adaptive, but again, there's a distinction here. There's adaptive at the design stage, like when you're preparing for that engineering process. Um Uh where the engineer can customize and the tool's quite malleable. But, when it comes to adaptive engineering, that's all about being adaptive during the run time, where the system reorganizes itself whilst running in response to the changing problem space of the environment. And you know, Pi is a strong example of the first kind, um but it doesn't make any claims um to be anything other. Uh it's not a self-organizing multi-agent system yet. I'm just going to skip over some of the uh nitty-gritties of what that could mean. Um so, for example, um uh when it comes to agent capabilities, um you know, obviously, they need to interact, learn, and change. That's kind of a prerequisite for adaptive engineering and I don't doubt that that will become the case as models get exponentially more powerful. There's a few things that the designer can actually do in the form of constraints and I'm not going to list out all the different types of constraints cuz they're sort of largely dictated by some of the properties like the roles and the sequencing and the memory. These are all sort of categories or properties of harness. But essentially there are three questions that you could ask yourself as an engineer which is do you want to enable the agents more or do you want to close them in and govern them more and produce more give them more guardrails. Are you rewarding them to cohere towards a particular goal or are you costing them if they fall outside a particular container? And how fast or slow do you want this um to happen? Some of the properties, you know, what's the speed for example the rate of coupling. So these are some of the engineering tweaks that you can make when it comes to adaptive engineering. And then finally like this emergent harness that is constantly shaping and reshaping itself based on the problem space. You can only really sense and respond to that emergent harness. You're not going to completely be able to I guess edit it in some sort of hard engineering fashion cuz that's not in the best interest of you as an adaptive engineer. This slide is just a more detailed comparison of both approaches and again I want to emphasize that one is not better than the other. It's just two different design engineering philosophies. Where on one hand in the factory model, um you know, the structure is imposed up front by the engineer, and so the harness becomes the input. Um whereas in the adaptive path, the harness emerges and is essentially the output. Um And And one of the crucial things here is that control is decentralized in the \[clears throat\] adaptive path. Um in the field continuously um because the problem space eventually when AI um comes or AI engineering comes off a screen into the real world, um the problem space is constantly changing. Um Now, it's important to understand that, you know, there are particular use cases for this. Um but there are a huge number of failure modes um in this as well. Um you know, just to list a few of those failure modes, you know, emergence leans towards uh stability, what we call an attractor, uh where you find a structure that feels stable and optimal, but that doesn't necessarily mean it's the best. Um you need some sort of genuine selection pressure. So, if you imagine in the social world or the physical or the natural world, the environment is um giving us certain uh pressures. You know, that's what encourages us to adapt. That is evolution. You know, there is some sort of selection pressure here. And you kind of need to find that um in or we as a community need to find that in adaptive engineering, otherwise you just get drift. There is a risk of monoculture, where you don't get genuine diversity amongst agents because they're all trained on the same data. Um legibility does collapse. Um you know, you as adaptability increases, um you can't really pin down or explain things that well. And again, that's a feature of complex systems. You can't really pin them down. And and and obviously goes without saying that there's no more predictability ahead of runtime because things are constantly moving. Um And and and these are the real failure modes that we must apprehend because I do feel like adaptive engineering is something that we're going to be more inclined towards and it's going to race forward um from the future. \>\> \[clears throat and cough\] \>\> I guess a bit of a takeaway then. Um you know, as models improve exponentially um AI engineering will move into the real world scenarios. You know, the real world where it touches um the physical space uh on an ongoing basis. It's uh in contact with multiple agents across different institutions. It's in contact with multiple human beings. So So there's a real cost peer where AI is heading towards. And so the discipline of design and engineering is going to be forced to rethink itself around continual production. \>\> \[snorts\] \>\> And the limiting factor which is the case now, but probably more so in the future, is not going to be the strength of the model. It's going to be the adaptability of the harness. Um and adaptability really here means multi-agent um which is essentially about coordinating amongst agents. A multi-agent orchestration which is decentralized. Um and it's not adaptable ahead of runtime. In fact, it starts becoming adaptable mid run-time or during an entire engineering a process. And I think that's real intelligence. That's Well, when I say real intelligence, I mean that's the intelligence when it comes to adaptability of the harness. Uh, I'd be really interested in um hearing your thoughts on this um and whether this is something that uh other people are also exploring. Um please do reach out to me. Thank you.