For a while, we thought the problem was prompt engineering. If the model failed, we tried to write a better instruction. Then the conversation moved to context: retrieval, memory, RAG, long context windows, dynamic prompts. Then came agents: systems where the model no longer only answers, but inspects files, calls tools, runs commands, edits code, and verifies results.

Now the word is harness.

At first, it sounds like another fashion term. A harness can look like a collection of tricks around the model: better prompts, better instructions, better tools, better workflows. But I think the idea is deeper than that. Harness engineering is not just prompt engineering with a new name. It is the discipline of building the environment that turns a probabilistic language model into a system that can act.

A model predicts. A harness constrains, verifies, remembers, and decides when the work is done.

That distinction matters. A language model is still fundamentally autoregressive: it produces the next token from the previous tokens. But an agent cannot survive by continuation alone. It needs an objective, a budget, tools, permissions, tests, memory, and stop conditions. It needs to know what to inspect, what to change, what to preserve, and when to stop.

Prompt engineering asks: “How do I phrase the instruction?”

Harness engineering asks: “What environment produces reliable behavior?”

That is a different discipline.

A prompt can tell an agent to be careful. A harness can define what “careful” means in a specific project. A prompt can say “run the tests.” A harness can decide which tests matter, trigger them after changes, and prevent the agent from claiming success if they fail. A prompt can say “avoid dangerous actions.” A harness can block destructive commands before they run.

This is where the old vocabulary becomes insufficient. We are no longer only writing instructions. We are designing control flow around a probabilistic actor.

And strangely, the more sophisticated these agents become, the more we return to primitive instructions: observe, plan, act, verify, remember, stop. These are not impressive ideas. They are basic control primitives. But that is exactly why they matter. They are the behavioral assembly language of agents.

The missing layer is experience.

A model can know a lot about code in general, but it does not know the local history of your project. It does not know which migration caused an incident six months ago, which directory is generated and should not be edited, which internal convention your team never violates, or which test is flaky for historical reasons.

Humans learn these things through experience. Over time, experience becomes intuition. A senior engineer does not reason from scratch every time. They carry reflexes: reproduce the bug before patching it, check the invariant before fixing the symptom, avoid widening scope during a hotfix, never remove a failing test just to make the suite pass.

Agents need something similar. Since that experience is not reliably inside the model weights, it has to be externalized.

This is the part that interests me most. The real value of a harness is not merely that it gives instructions to the agent. The real value is that it can turn past agent experience into future operational memory.

Every coding session with an AI agent contains traces of learning: what failed, what worked, which files mattered, what assumptions were wrong, which commands were useful, which project rules were rediscovered, and which mistakes should not happen again. But most of that experience disappears. It remains buried in transcripts, JSONL logs, chat histories, scattered notes, or bloated instruction files that nobody wants to maintain.

This is the problem I built Insight Forge to explore.

Insight Forge is based on a simple idea: your AI sessions already contain more knowledge than you think. They contain the raw material for a better harness. The problem is that this knowledge is not structured, not validated, and not reusable.

So instead of treating every agent session as disposable, Insight Forge treats it as evidence. It reads past sessions, extracts signals, identifies useful lessons, and proposes improvements to files like CLAUDE.md or AGENTS.md. It does not try to magically retrain the model. It tries to improve the environment around the model.

That is the key distinction.

The goal is not to make the model universally smarter. The goal is to make the agent locally more competent.

This is exactly what experience does for humans. Experience does not make us omniscient. It makes us better adapted to a specific environment. We learn the shape of a codebase, the traps in a process, the habits of a team, the bugs that tend to come back, the shortcuts that are dangerous, and the checks that are worth running.

A good harness should do the same for agents.

Files like AGENTS.md and CLAUDE.md are early forms of this externalized intuition. They put local working knowledge beside the code itself: conventions, constraints, test expectations, forbidden patterns, stop conditions. At one level, they are just Markdown files. At another level, they are primitive memory systems for agents.

But Markdown alone is not enough. A file can suggest behavior; a hook can enforce it.

A hook can block a dangerous command, run tests after a file change, reject premature completion, or preserve execution traces. If instructions are memory, hooks are reflexes.

Skills add another layer. Instead of putting every rule into one giant prompt, we can package procedures: regression debugging, API review, migration safety, security-sensitive changes, documentation updates, harness review. A skill is not just knowledge. It is a reusable routine.

This is where I think harness engineering becomes genuinely interesting. It is not about collecting “AI tips.” It is about building a system where the agent’s environment accumulates experience over time.

That is why Insight Forge belongs directly in this discussion. It is not a side project next to the harness idea. It is an attempt to implement one part of it: the conversion of agent traces into operational memory.

The workflow is deliberately conservative. Not every sentence from a past session should become a rule. Not every model claim should be trusted. A useful harness needs evidence, not vibes. The important question is not “Did the model say something?” but “Was this lesson confirmed by the session? Did it affect the outcome? Is it reusable? Should it become a project rule, a warning, a skill, or a hook?”

That is where the next layer of agent engineering may live.

Not only in larger models.

Not only in longer context windows.

Not only in more tools.

But in the ability to preserve, filter, and reuse experience.

There is a paradox here. At first, AI progress looks like giving models more freedom: larger models, more autonomy, more tools, more context, more flexible workflows. But the more we use agents for real work, the more reliability brings us back to constraints.

Budgets matter. Stop conditions matter. Verification matters. Permissions matter. Logs matter. Tool boundaries matter. Reproducible workflows matter.

This does not mean agents are a failure. It means agents are becoming software. And software needs architecture.

The harness is that architecture around the model. It decides what should remain flexible and what should be enforced, what can be left to model judgment and what must be checked by code, what should be remembered and what should be discarded, what counts as success and what counts as unsafe action.

We are no longer simply learning how to talk to models. We are learning how to build external nervous systems around them.

The model provides generative intelligence. The harness provides procedural continuity. The model can propose, but the harness can constrain. The model can forget, but the harness can remember. The model can continue, but the harness can decide when to stop.

That is why harnesses matter. They are not just a trend or a collection of tricks. They are the emerging layer between probabilistic language generation and durable operational intelligence.

And this is also why I think tools like Insight Forge point in the right direction. The future of agent engineering will not belong only to raw intelligence. It will belong to systems that can turn experience into memory, memory into procedure, and procedure into reliable action.

https://github.com/bacoco/insight-forge/tree/main

Ingénierie du harness : transformer l’expérience des agents IA en mémoire opérationnelle

Pendant un moment, nous avons cru que le problème était le prompt engineering. Si le modèle échouait, nous essayions d’écrire une meilleure instruction. Puis la conversation s’est déplacée vers le contexte : retrieval, mémoire, RAG, longues fenêtres de contexte, prompts dynamiques. Ensuite sont venus les agents : des systèmes où le modèle ne se contente plus de répondre, mais inspecte des fichiers, appelle des outils, lance des commandes, modifie du code et vérifie des résultats.

Maintenant, le mot est harness.

À première vue, cela ressemble à un terme de mode supplémentaire. Un harness peut passer pour une collection d’astuces autour du modèle : meilleurs prompts, meilleures instructions, meilleurs outils, meilleurs workflows. Mais je pense que l’idée est plus profonde que cela. L’ingénierie du harness n’est pas simplement du prompt engineering avec un nouveau nom. C’est la discipline qui consiste à construire l’environnement qui transforme un modèle de langage probabiliste en système capable d’agir.

Un modèle prédit. Un harness contraint, vérifie, mémorise et décide quand le travail est terminé.

Cette distinction compte. Un modèle de langage reste fondamentalement autorégressif : il produit le prochain token à partir des tokens précédents. Mais un agent ne peut pas survivre par simple continuation. Il lui faut un objectif, un budget, des outils, des permissions, des tests, une mémoire et des conditions d’arrêt. Il doit savoir quoi inspecter, quoi changer, quoi préserver et quand s’arrêter.

Le prompt engineering demande : « Comment formuler l’instruction ? »

L’ingénierie du harness demande : « Quel environnement produit un comportement fiable ? »

C’est une discipline différente.

Un prompt peut dire à un agent d’être prudent. Un harness peut définir ce que “prudent” signifie dans un projet spécifique. Un prompt peut dire « lance les tests ». Un harness peut décider quels tests comptent, les déclencher après les changements et empêcher l’agent d’affirmer que le travail est terminé s’ils échouent. Un prompt peut dire « évite les actions dangereuses ». Un harness peut bloquer les commandes destructrices avant leur exécution.

C’est là que l’ancien vocabulaire devient insuffisant. Nous n’écrivons plus seulement des instructions. Nous concevons du contrôle de flux autour d’un acteur probabiliste.

Et, curieusement, plus ces agents deviennent sophistiqués, plus nous revenons à des instructions primitives : observer, planifier, agir, vérifier, mémoriser, s’arrêter. Ce ne sont pas des idées impressionnantes. Ce sont des primitives de contrôle. Mais c’est précisément pour cela qu’elles comptent. Elles sont l’assembleur comportemental des agents.

La couche manquante est l’expérience.

Un modèle peut savoir beaucoup de choses sur le code en général, mais il ne connaît pas l’histoire locale de votre projet. Il ne sait pas quelle migration a causé un incident il y a six mois, quel dossier est généré et ne doit pas être modifié, quelle convention interne votre équipe ne viole jamais, ou quel test est flaky pour des raisons historiques.

Les humains apprennent ces choses par l’expérience. Avec le temps, l’expérience devient intuition. Un ingénieur senior ne raisonne pas à partir de zéro à chaque fois. Il porte des réflexes : reproduire le bug avant de le corriger, vérifier l’invariant avant de traiter le symptôme, éviter d’élargir le périmètre pendant un hotfix, ne jamais supprimer un test en échec simplement pour faire passer la suite.

Les agents ont besoin de quelque chose de similaire. Comme cette expérience n’est pas présente de manière fiable dans les poids du modèle, elle doit être externalisée.

C’est la partie qui m’intéresse le plus. La vraie valeur d’un harness n’est pas seulement de donner des instructions à l’agent. Sa vraie valeur est de transformer l’expérience passée de l’agent en mémoire opérationnelle future.

Chaque session de coding avec un agent IA contient des traces d’apprentissage : ce qui a échoué, ce qui a fonctionné, quels fichiers comptaient, quelles hypothèses étaient fausses, quelles commandes étaient utiles, quelles règles du projet ont été redécouvertes, et quelles erreurs ne devraient plus se reproduire. Mais la plupart de cette expérience disparaît. Elle reste enterrée dans des transcripts, des logs JSONL, des historiques de conversation, des notes dispersées ou des fichiers d’instructions devenus trop gros pour être maintenus.

C’est le problème que j’ai voulu explorer avec Insight Forge.

Insight Forge repose sur une idée simple : vos sessions IA contiennent déjà plus de connaissance que vous ne le pensez. Elles contiennent la matière première d’un meilleur harness. Le problème est que cette connaissance n’est pas structurée, pas validée et pas réutilisable.

Au lieu de traiter chaque session agentique comme jetable, Insight Forge la traite comme une preuve. Il lit les sessions passées, extrait des signaux, identifie des leçons utiles et propose des améliorations pour des fichiers comme CLAUDE.md ou AGENTS.md. Il n’essaie pas de réentraîner magiquement le modèle. Il essaie d’améliorer l’environnement autour du modèle.

C’est la distinction essentielle.

Le but n’est pas de rendre le modèle universellement plus intelligent. Le but est de rendre l’agent localement plus compétent.

C’est exactement ce que l’expérience fait pour les humains. L’expérience ne nous rend pas omniscients. Elle nous rend mieux adaptés à un environnement spécifique. Nous apprenons la forme d’une codebase, les pièges d’un processus, les habitudes d’une équipe, les bugs qui ont tendance à revenir, les raccourcis dangereux et les vérifications qui valent la peine d’être lancées.

Un bon harness devrait faire la même chose pour les agents.

Des fichiers comme AGENTS.md et CLAUDE.md sont des formes précoces de cette intuition externalisée. Ils placent le savoir local de travail à côté du code lui-même : conventions, contraintes, attentes de test, patterns interdits, conditions d’arrêt. À un niveau, ce ne sont que des fichiers Markdown. À un autre niveau, ce sont des systèmes de mémoire primitifs pour agents.

Mais Markdown seul ne suffit pas. Un fichier peut suggérer un comportement ; un hook peut l’imposer.

Un hook peut bloquer une commande dangereuse, lancer des tests après une modification de fichier, rejeter une fin prématurée ou préserver des traces d’exécution. Si les instructions sont de la mémoire, les hooks sont des réflexes.

Les skills ajoutent encore une couche. Au lieu de placer toutes les règles dans un prompt géant, on peut empaqueter des procédures : débogage de régression, revue d’API, sécurité des migrations, changements sensibles à la sécurité, mise à jour de documentation, revue de harness. Un skill n’est pas seulement de la connaissance. C’est une routine réutilisable.

C’est là que l’ingénierie du harness devient réellement intéressante. Il ne s’agit pas de collectionner des “astuces IA”. Il s’agit de construire un système dans lequel l’environnement de l’agent accumule de l’expérience au fil du temps.

C’est pourquoi Insight Forge appartient directement à cette discussion. Ce n’est pas un projet annexe à côté de l’idée de harness. C’est une tentative d’en implémenter une partie : la conversion des traces agentiques en mémoire opérationnelle.

Le workflow est volontairement conservateur. Toutes les phrases d’une ancienne session ne doivent pas devenir des règles. Toutes les affirmations du modèle ne doivent pas être crues. Un harness utile a besoin de preuves, pas d’impressions. La question importante n’est pas : « Est-ce que le modèle a dit quelque chose ? » mais plutôt : « Est-ce que cette leçon a été confirmée par la session ? Est-ce qu’elle a changé le résultat ? Est-ce qu’elle est réutilisable ? Doit-elle devenir une règle de projet, un avertissement, un skill ou un hook ? »

C’est peut-être là que se trouve la prochaine couche de l’ingénierie des agents.

Pas seulement dans des modèles plus grands.

Pas seulement dans des fenêtres de contexte plus longues.

Pas seulement dans davantage d’outils.

Mais dans la capacité à préserver, filtrer et réutiliser l’expérience.

Il y a ici un paradoxe. Au début, le progrès en IA ressemble à plus de liberté donnée aux modèles : modèles plus grands, plus d’autonomie, plus d’outils, plus de contexte, workflows plus flexibles. Mais plus nous utilisons les agents pour du travail réel, plus la fiabilité nous ramène vers les contraintes.

Les budgets comptent. Les conditions d’arrêt comptent. La vérification compte. Les permissions comptent. Les logs comptent. Les frontières d’outils comptent. Les workflows reproductibles comptent.

Cela ne veut pas dire que les agents sont un échec. Cela veut dire que les agents deviennent du logiciel. Et le logiciel a besoin d’architecture.

Le harness est cette architecture autour du modèle. Il décide ce qui doit rester flexible et ce qui doit être imposé, ce qui peut être laissé au jugement du modèle et ce qui doit être vérifié par du code, ce qui doit être mémorisé et ce qui doit être jeté, ce qui compte comme succès et ce qui compte comme action dangereuse.

Nous ne sommes plus simplement en train d’apprendre à parler aux modèles. Nous sommes en train d’apprendre à construire autour d’eux des systèmes nerveux externes.

Le modèle fournit l’intelligence générative. Le harness fournit la continuité procédurale. Le modèle peut proposer, mais le harness peut contraindre. Le modèle peut oublier, mais le harness peut mémoriser. Le modèle peut continuer, mais le harness peut décider quand s’arrêter.

C’est pourquoi les harnesses comptent. Ce ne sont pas seulement une tendance ou une collection d’astuces. Ils sont la couche émergente entre la génération probabiliste du langage et l’intelligence opérationnelle durable.

Et c’est aussi pour cela que je pense que des outils comme Insight Forge vont dans la bonne direction. L’avenir de l’ingénierie des agents n’appartiendra pas seulement à l’intelligence brute. Il appartiendra aux systèmes capables de transformer l’expérience en mémoire, la mémoire en procédure, et la procédure en action fiable.