Beyond the Harness: A Journey Towards Adaptative Engineering - Rajiv Chandegra, Annicha Labs

Hello, I'm Rajiv. I'm a practicing medical doctor here in London, and I've been doing some AI engineering for the past few years. I'm particularly interested in real-world application and really the future, which is multi-agent, multi-human, multi-institutional collaboration through a company called Annicha 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 Py, Claude Code, Cursor, Codex, whatever it is, ahead of runtime, 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 engineeringright now is to use a harness and steer agents. But the future is going to be different in at least two ways.

Number 1: models are going to become so powerful that existing fixed harnesses are constantly going to become outdated. And number 2 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 clawed .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, granting them unique capabilities 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.

And that enables them to deliver targeted outputs and specified outputs, whether it be code, documentation, issues, handoffs. And most recently, we've seen the genesis of kind of loops. Loop engineering has become a thing. So that eventually we reach some sort of outcome, whether it's a feature, a problem solved, which is eventually reviewed by a human.

So what you see from this is that before running the engineering process, the entire harness has been predetermined or pre-engineered. And that's harness engineering. And it's been remarkable at getting the most out of the latest models.

And just sort of stepping a bit back, defining exactly what a harness is. Essentially, the model is the engine, and the harness is everything built around to make that engine useful. There's many different types of harnesses. I mean, there's hundreds, actually, but I guess the most common ones are, you know, CLI coding, such as Claude Code, Codex, Py.

You have IDEs like Cursor, multi-agent orchestration through LangChain, and things like Hermes as well, Kline, and Goose. And these are all differentiated based on, number 1, properties and how they're configured. But actually, more importantly, number 2, 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, and they allow for, I guess, different use cases. 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 is predefined, you know. You can customize them, of course, like for example, the Py agent. It's minimalist and it's maximally extensible. But everything is predefined, you know, the roles, fixed outputs, sequencing protocols, how memory is created.

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, and not mid-engineering. And that's largely directed by us as humans.

And for someone like me, who started AI engineering about 2 years ago, it's probably the most powerful and predictable method. And it's got really 3 payoffs. It's reliable. You know, the same input leads to a similar set of outputs.

Obviously, there's going to be some variation. It's auditable. You can inspect exactly what changed and when. And there's some sort of linear causality where, you know, if something breaks, you can actually trace it back to its source. This is like a factory line, though.

Like, think tailorism for AI. Just like a factory assembly line, every station is engineered in advance. 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 problem, and you know the kind of features you want to build.

You know the sort of solutions that you need.

But here's the catch, and it's a real trade-off, that that reliability isn't free. You buy it by suppressing

variance that I'd argue novelty requires. And determinism and emergence pull kind of in opposite directions. And this is where we have to pivot to the real world, because in real-life situations, when AI eventually, 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, there's a hard ceiling on novelty.

Because the real world is messy, and it keeps changing. And so a fixed harness starts to break down. So like I mentioned, there's a hard ceiling on novelty, because essentially its reliability is predicated on suppressing variance. 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.

And that kind of leads to this whole dilemma of brittleness, where every situation you didn't anticipate, you didn't anticipate, needs a human to patch the harness. The more real-world it meets, 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 theright answer to a fixed problem, and the wrong answer to a moving problem.

And so let's really examine what the real world is about. And I'm going to go down a bit of a philosophical route here.

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, are 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, you wire them together, and you get a product. The second paradigm, what we call the systems or relational paradigm, 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 it flips the order. It says that the real world isn't made up of things at all. It's made up of processes and 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.

And there's a really good payoff in understanding this paradigm. And once you see the world in this way, you start to notice something remarkable, 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 its constituent parts, oxygen and hydrogen, are not wet.

But they're coming together, again, putting emphasis on the relationships. They're 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. 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 into each other.

And he gave that a name. He called it a mess. A mess 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 tiny 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 distinction between different types of problems. So engineering is all about solving problems. And I'd argue that, very simply put, there are two kinds of problems. There are complicated problems, 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, 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. Its 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.

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, essentially, you know, the ingredients of it are, first, you need a diverse set of agents or actors, if it's a human organization. Not clones, essentially, but different from one another in some sort of way.

So because the diversity is the fuel there. They need to interact locally. Because no agent, no individual actor, no individual component sees the whole. 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, 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. Basically, it's a new novel pattern, or organization, or behavior that no single part designed on its own can 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 or 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. 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 I 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've covered so far lives inside a particular framework, which is this kind of fixed or factory harness.

The human engineer decides it all up front, the sequencing, the roles, capabilities. That's really the factory model. And it works. And we've seen that. Because problem spaces that are complicated yet predictable is exactlyright. 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've found, messy and complex, not just complicated, we need something genuinely new, a different idea of what optimal design and engineering even is.

And obviously, it rests on those two assumptions, that models are going to become exponentially better, and that AI will come outside of a sandbox situation. And actually, engineering will run in real time in contact with the social and physical environment.

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 the definition, 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, just to make it a bit more concrete, is given that agents have capabilities 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.

So think bird and 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. 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, essentially, you have agents that are isomorphic, but yet undifferentiated, but fully capable of interacting and learning and changing.

You let those agents interact. At first, there's nothing. There'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 occurs with each agent.

And suddenly, you start to see this whole emerge, a system, you could say. And I guess as an engineer, your new lever becomes how the rate of coupling, like, do you dial it up, or do you dampen it down?

Again, the adaptive path focuses on the interactions

until, you know, agents start to actually specialize with respect to one another. So let's say you've 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 time. So I guess a tiny difference, 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 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, they stop connecting at random. In fact, they start to work well together in terms of sort of clusters. And you see the first boundaries appear. And crucially, the system drew them.

You didn't, as an engineer, ahead of time. So these are kind of emergent clusters until a new convention crystallizes, you know, a division of norms and protocols. And the system produces some level of governance without a governor. Conventions emerge spontaneously from their local coordination with no central authority.

Because, as we've seen, central authority can lead to brittleness in a changing environment. 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 emergent order arises. So 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 the order needs to essentially restructure itself.

So the question is that what is the role of an engineer? And really, in adaptive engineering, you don't abolish the engineer. You're just relocating the emphasis of engineering. So if you can exploit the model's capabilities, so agents can essentially interact, learn, and change, what you're doing as an engineer is essentially 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. And then once that emergent harness starts to take shape, you are sensing it and responding to that rather than stopping the engineering process and starting from scratch.

And I think this slide sort of portrays that. This is not binary. This is not either/or. In fact, it's very much a continuum.

There's no purely fixed harness way. And there's no purely, completely adaptive autonomous way. Fixed engineering is essentially, in one hand, prescribing the structure which agents run. And you rarely change this structure mid-engineering. 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 to be created by them and change mid-engineering.

So it's not like a swarm of agents loose with no roles and this sort of intelligence that magically appears. And it's not sort of better. One way is not better than the other. They just have two different use cases.

And if I could just, you know, bring it back to some examples of existing harnesses. So for example, Hermes,

on the 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. But I do want to make a distinction here.

Because 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 bitorthogonal.

And the thesis that I'm presenting is that it's horizontal intelligence that is the most adaptive method, the most agile method, and arguably the higher leverage point

compared to vertical. Another example is Pi, you know, a great harness, which is sort of essentially minimal, yet it's maximally extensible. So it's fully customizable to an extent. 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,

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 runtime, where the system reorganizes itself whilst running in response to the changing problem space or the environment.

And, you know, Pi is a strong example of the first kind. But it doesn't make any claims to be anything other. It's not a self-organizing multi-agent system yet.

I'm just going to skip over some of the nitty-gritties of what that could mean. So for example,

when it comes to agent capabilities, 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 because 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, the 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 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 because 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, you know, the structure is imposed up front by the engineer.

And so the harness becomes the input. Whereas in the adaptive path, the harness emerges and is essentially the output. And one of the crucial things here is that control is decentralized in the adaptive path

in the field continuously. Because the problem space, eventually, when AI comes, AI engineering comes off a screen into the real world, the problem space is constantly changing.

Now, it's important to understand that, you know, there are particular use cases for this. But there are a huge number of failure modes in this as well. You know, just to list a few of those failure modes, you know, emergence leans towards stability, what we call an attractor, where you find a structure that feels stable and optimal.

But that doesn't necessarily mean it's the best.

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 giving us certain 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. And 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.

Legibility does collapse. You know, as adaptability increases,

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 obviously, it goes without saying that there's no more predictability ahead of runtime because things are constantly moving.

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 from the future.

I guess a bit of a takeaway then, you know, as models improve exponentially, AI engineering will move into the real world scenarios, you know, the real world where it touches the physical space on an ongoing basis. It's in contact with multiple agents across different institutions.

It's in contact with multiple human beings. So there's a real cusp here where AI is heading towards. And so the discipline of design and engineering is going to be forced to rethink itself around continual production. 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. And adaptability really here means multi-agent, which is essentially about coordinating amongst agents, so multi-agent orchestration, which is decentralized. And it's not adaptable ahead of runtime. In fact, it starts becoming adaptable mid-runtime or during an entire engineering 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.

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. Thank you.