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

A harness gives agents roles, tools and a sequence of work before execution begins. What happens when the environment changes enough that those arrangements no longer fit? That question motivates Rajiv Chandegra, a practicing medical doctor in London working through Annicha Labs on collaboration among agents, humans and institutions. His starting point is familiar: use or configure a harness such as Pi, Claude Code, Cursor or Codex, then steer agents through it. The resulting work can be orderly and reliable, and he considers this a good fit for most engineering problems.

Chandegra expects two pressures to challenge that arrangement. More capable models may outgrow scaffolding built around earlier limitations. Meanwhile, AI engineering may move beyond software behind a screen into continuous contact with people, institutions and the physical world. Those environments change while work is underway. His proposed response is adaptive engineering: engineers establish constraints—the rules of play—under which a harness can emerge, stabilize, change and eventually dissolve during execution.

The current harness supplies the machinery that turns a typically stateless language model into a useful working system. System instructions establish behavior; files such as AGENTS.md and CLAUDE.md provide project context; tool calling gives the model ways to act. Chandegra describes vendor system prompts as fixed and project instructions as loaded at session start. Product capabilities need a narrower reading today: current Claude Code documentation supports replacing or extending system prompts, while Pi supports prompt customization and /reload during a session. These current capabilities do not reconstruct the versions used for the talk. The durable distinction is between engineer-directed customization and a group autonomously reorganizing its own structure during execution.

Within that configured environment, agents acquire differentiated roles, capabilities, rules and skills. They produce code, documentation, issues or handoffs. Loops carry that work toward an outcome—a feature or a solved problem—which a human eventually reviews. The harness therefore specifies more than a prompt: it establishes how capabilities become specialized work, how outputs feed further work, and how the process reaches review. Predetermining this machinery is harness engineering, which Chandegra credits with extracting substantial value from current models.

The model is the engine; the harness is everything around it that makes the engine useful. That surrounding machinery takes different forms: command-line coding tools such as Claude Code, Codex and Pi; an IDE such as Cursor; multi-agent orchestration through LangChain; and tools including Hermes, Cline and Goose. Their differences concern configuration and capabilities, but also engineering philosophy. An opinionated harness encodes a view of how work should happen, which makes it attractive for particular tasks and particular engineers.

Extensibility does not eliminate those structural choices. Pi, for example, emphasizes a minimal core and broad extensibility. Chandegra’s concern is who determines roles, expected outputs, sequencing protocols and memory creation. In the factory approach, the engineer largely settles those arrangements before the work they govern. That buys three useful properties:

• Reliability: similar inputs tend to produce similar outputs, allowing for model variation.
• Auditability: changes and their timing can be inspected.
• Traceable causality: when something breaks, the engineer can follow the chain back toward its source.

This is his factory-line analogy: each station is engineered in advance, and each agent has a job, a position in the sequence and a defined handoff.

An assembly line is valuable when the product and problem are well defined. Known features and solutions make accuracy, speed, reproducibility and certifiable behavior attainable goals. Chandegra argues that the same arrangement carries a cost: suppressing variance to obtain reliability can also suppress the novelty a changing problem requires. A process optimized around known work may have little room to discover a different organization of that work.

Model progress adds another source of change. In his illustrative forecast, scaffolding carefully built today could become unnecessary a month later because a stronger model no longer needs it. Environmental change creates the complementary problem: every unanticipated situation requires another human patch. Rules accumulate until the harness becomes more complicated than the problem it serves. His dividing line is consequently the movement of the problem itself: a factory method fits fixed work, while continually moving work may require a structure that can move with it.

To explain why a moving problem might need different engineering, Chandegra changes the unit of analysis. A reductionist approach begins with stable components: take a whole apart, study its pieces, then understand how they fit together. Relationships enter after the parts. Much software follows that pattern—build components, wire them together, obtain a product.

A systems or relational approach gives priority to processes and relationships. What appears to be a stable object can instead be a persistent pattern sustained by ongoing activity. An organism, in this view, resembles a flame more than a crystal. A flame looks like a thing, but its existence depends on a process continuing from moment to moment. Stop the process and the apparent object disappears.

Local interactions can also produce properties that are absent from individual constituents. Chandegra uses water’s wetness as an intuitive example: the collective property does not belong to oxygen or hydrogen considered separately. His more operational example is a flock of birds. Each bird follows local rules: align with neighbors, avoid collisions and stay close. Coordinated movement appears at the group level without any bird planning the flock. Studying a single bird in isolation cannot reveal the relationships that sustain that organization. The analogy redirects engineering attention from fixed components toward patterns of interaction.

Chandegra draws on Russell Ackoff’s description of a mess: managers encounter changing situations whose problems interact, rather than a collection of neatly separated tasks. Solving each apparent problem independently can miss the moving relationships that make the situation difficult. A mess is a system of problems, not simply a larger backlog.

That leads to a distinction between complicated and complex work:

A complicated system may be extremely difficult to build, but expert analysis can make its behavior knowable and predictable. In a complex system, participants change in response to one another, so analyzing isolated parts cannot fully specify the evolving whole. Chandegra identifies treating a complex problem as merely complicated as a design failure: better execution of the original plan does not repair the mistaken classification.

The proposed ingredients of a complex adaptive system begin with diversity. Its agents or actors must differ in useful ways rather than behave as clones. They interact locally, with no participant seeing the whole system. Each responds to nearby participants and then learns recursively: it adapts, encounters the consequences of that adaptation, and adapts again in relation to its peers and environment.

Those feedback loops can produce emergence: a pattern, organization or behavior that no individual participant designed. Yet continual local change need not mean that the whole system flies apart. Chandegra introduces attractors as stable states toward which a system tends to return, using water at room temperature to illustrate recognizable stability despite activity at a smaller scale. The opportunity he sees is this coexistence of local change and persistent organization without a central actor specifying every movement.

Fixed engineering remains appropriate for complicated, predictable work—and, in Chandegra’s assessment, for most engineering problems today. His alternative rests on two forecasts: models become substantially more capable, and engineering runs continuously outside a sandbox in contact with social and physical environments. Under those conditions, a structure chosen once may cease to fit while the work is still underway.

Adaptive engineering designs constraints under which the harness itself emerges, stabilizes and adapts. The harness becomes an ongoing output of the system rather than only an input supplied by its engineer. Capable agents interact in response to a goal or environment; those interactions generate organization that was not fully specified in advance. The bird-to-flock analogy becomes agent-to-harness: relationships among agents form the structure that guides their subsequent work. That structure can then evolve as circumstances change.

Chandegra sketches a hypothetical progression for future agents capable of interacting, learning and changing. Initially, they have the same form and no differentiated roles. Exchanges begin sparsely, then coupling increases. In this hypothetical progression, Chandegra places the appearance of a system at roughly one connection per agent on average. He does not establish that figure as a threshold for useful LLM coordination; the scenario supplies neither graph assumptions nor an experimental result. The engineering lever is the rate of coupling: encourage interactions to form more quickly, or dampen their growth.

Specialization follows when environmental feedback makes interchangeability less useful. Two agents doing the same work in the same place are redundant. A small difference—one arriving first or performing slightly better—can receive positive feedback and grow until the agents occupy different niches. In this proposed mechanism, an agent’s identity is the position, role or capability it develops relative to others and to its environment, rather than a role label assigned at initialization.

Next, connections become less random. Agents that work well together form clusters, and boundaries appear that the engineer did not draw in advance. Repeated local coordination can establish shared norms and protocols, creating decentralized governance. The resulting order persists long enough to coordinate work, but remains provisional: when the environment changes, the organization must be able to restructure. The progression is therefore from interaction to specialization, clustering and conventions—not a one-time discovery of a permanently optimal team.

The engineer remains responsible for the conditions under which this organization develops. Instead of specifying every outcome, the engineer establishes constraints that give agents room to explore, then senses and responds to the resulting structure without stopping the process and rebuilding it from scratch. Chandegra presents fixed and adaptive engineering as a continuum. Neither a perfectly fixed harness nor complete autonomous adaptation is the practical endpoint, and releasing a roleless swarm does not by itself produce useful intelligence. The appropriate balance depends on the work.

Hermes clarifies one axis of that continuum. Its project description includes creating skills from experience and learning through use. Chandegra calls improvement within an individual agent vertical intelligence, and coordination among agents horizontal intelligence. These are orthogonal directions: improving an agent does not automatically improve the organization of a group. His claim that horizontal intelligence offers greater adaptive leverage is a thesis about where to focus engineering effort, not a measured comparison between products.

Pi clarifies the other axis: when adaptation occurs and who directs it. A minimal, extensible harness gives an engineer considerable freedom to shape a tool. Adaptive engineering, as defined here, requires the running system to reorganize itself in response to a changing problem or environment. Chandegra uses Pi to distinguish that self-organization from customization, not to argue that extensibility is unimportant. His target is a self-organizing multi-agent system, a different capability from a malleable agent tool.

Agents must first be able to interact, learn and change; Chandegra expects future model advances to strengthen those prerequisites. The engineer then works with constraints across familiar harness properties, including roles, sequencing and memory. He organizes the available choices around three questions:

• Open or close? Enable more agent behavior, or govern it more tightly with guardrails.
• Wall or goal? Reward coordination toward a shared objective, or impose costs for moving outside a permitted boundary.
• How fast? Adjust the tempo of change, including the rate at which agents form connections.

These controls shape the space in which organization can develop without prescribing every relationship that must appear.

A small TypeScript example makes the distinction concrete. Suppose an engineer permits an agent to propose a new connection only when the peer is eligible and the agent has not exhausted its per-round connection budget:

type CouplingPolicy = {
  eligiblePeerIds: ReadonlySet<string>;
  maxNewConnectionsPerRound: number;
};

function canProposeConnection(
  peerId: string,
  newConnectionsThisRound: number,
  policy: CouplingPolicy,
): boolean {
  return (
    policy.eligiblePeerIds.has(peerId) &&
    newConnectionsThisRound < policy.maxNewConnectionsPerRound
  );
}

const policy: CouplingPolicy = {
  eligiblePeerIds: new Set(["agent-b", "agent-c"]),
  maxNewConnectionsPerRound: 1,
};

const proposalAllowed = canProposeConnection("agent-b", 0, policy);

This teaching example expresses a boundary and a tempo limit. It permits a proposal; it neither creates a connection nor assigns a team structure. Deciding which permitted relationship is useful would require the interaction and feedback mechanisms discussed earlier.

Once a harness takes shape, the engineer senses and responds to it rather than treating the emergent organization as a fixed object to edit directly. The contrast concerns the continuing source of structure:

The adaptive path keeps this adjustment active while the system operates, because its environment does not pause for redesign.

An emergent structure can settle into an attractor that feels stable without being the best arrangement. Stability does not establish usefulness. Chandegra therefore identifies genuine selection pressure as a missing requirement: the environment must provide feedback that favors useful adaptation. In natural and social systems, environmental pressures help determine which behaviors persist. Finding an effective counterpart for adaptive engineering remains an open problem in his proposal. Without it, a changing system can simply drift.

Other risks follow directly from the ingredients that make adaptation possible:

• Monoculture: agents trained on the same data may fail to supply genuine diversity, even when there are many of them.
• Reduced legibility: as structure changes through interactions, explaining why the system behaves as it does becomes harder.
• Reduced advance predictability: a structure that develops during execution cannot offer the same pre-runtime account of behavior as a predetermined process.

These are operational problems the proposal must confront as adaptability increases. The ability to reorganize does not remove the need to understand what the resulting organization is doing.

Chandegra’s closing forecast is that increasingly capable AI will operate in ongoing contact with the physical world, multiple institutions and multiple humans. Engineering in that setting becomes continual production: the system must keep working while the conditions around it change. He expects the limiting factor to shift toward the adaptability of the harness, rather than model strength alone.

The capability he wants to develop is decentralized multi-agent coordination that can change during the engineering process. Adaptability must belong to the running organization, not only to the configuration choices available before launch. When he describes that as intelligence, he narrows the claim to intelligence in the adaptability of the harness: the ability of an organizing structure to keep finding a workable form as its world changes.