Exécutable, inspectable, à état, gouverné : et gardé.

Un survey de champ vient de cartographier le « code as agent harness » : le code non plus comme artefact généré, mais comme milieu d'action des agents (« Code as Agent Harness », arXiv 2605.18747, équipes affichées Meta, Stanford, UIUC). Disons-le d'emblée : un survey décrit un paysage, il ne valide pas un produit. Ce qu'il fait, en revanche, c'est nommer le terrain. Et il ferme sur une phrase que nous aurions pu écrire : les systèmes qui compteront combineront quatre propriétés, executable, inspectable, stateful, governed.

Quatre propriétés, côté livraison

Les harnesses que le papier étudie sont des runtimes : ils planifient, exécutent, observent, réparent, pendant que l'agent tourne. runward n'est pas un runtime et ne le sera jamais. C'est la couche livraison au-dessus : elle enregistre des décisions et juge des preuves au repos, elle n'exécute rien du travail de l'agent. Les quatre propriétés s'y incarnent pourtant, une commande et un ADR chacune :

• Executable. Le verdict s'exécute : runward check --json, codes de sortie fixés, même dépôt, même verdict, rejouable en CI. La conformité aux règles déclarées s'impose à la porte, pas dans la prose (ADR-0001).
• Inspectable. Le référentiel est une surface machine : runward rules --json liste le jeu de règles effectif, runward explain imprime le contrat de chaque règle et sa raison d'être, en ligne (ADR-0024).
• Stateful. runward status rapporte la position réelle dans le cycle de vie, réouvertures comprises : l'état de la mission est un artefact sur disque, pas un souvenir de session (ADR-0033).
• Governed. La passation est une phase gardée : elle ne se franchit que sur preuve vérifiée, et la chaîne décision, ADR, manifeste débouche sur un mapping OSCAL citable via runward compliance (ADR-0026).

Même grammaire que le papier, autre étage. Le survey recommande des « deterministic sensors and human-review gates » pour gouverner les transitions d'état du runtime ; runward applique la même discipline à la seule transition que le runtime ne voit jamais : celle qui décide si le système a le droit d'être livré.

La case vide

Le mot « gate » revient une cinquantaine de fois dans le papier. Les portes humaines y existent bel et bien : gates HITL au runtime, tiers de permissions, approbations tracées comme transitions auditables. Soyons précis, donc, sur ce que le corpus n'a pas : aucun des systèmes recensés ne décrit une porte humaine déterministe de livraison. Un verdict rejouable à l'octet, zéro LLM dans le chemin du verdict, que l'humain franchit sur preuve et non sur confiance. C'est une case étroite ; c'est la nôtre, et le survey de champ n'y recense personne d'autre.

Là où nous divergeons, et pourquoi c'est une bonne nouvelle

Une confrontation qui ne trouverait que des convergences ne prouverait rien. La voici : le papier rapporte que la simulation d'exécution par LLM atteint « 98%+ precision and recall » et recommande un harness mature qui prendrait « linguistic reasoning as the fast path », l'exécution en oracle de vérification pour les seuls cas qui l'exigent (§3.4). Sur son terrain, l'économie de la boucle de réparation au runtime, nous n'avons rien à y redire. Dans le chemin du verdict, runward le refuse par décision datée : la vérification LLM est consultative, jamais la porte (ADR-0007). Le même papier exige ailleurs des signaux « that cannot hallucinate » ; il porte cette tension en lui, nous avons choisi un côté et nous l'avons verrouillé.

Quatre propriétés que le champ converge à nommer, une case que personne d'autre n'occupe, une divergence assumée par écrit. C'est notre lecture du papier ; le papier, lui, n'a pas d'avis sur nous, et c'est très bien ainsi.

---

Commencer : npx runward init

Le papier sur arXiv · Le dépôt sur GitHub · Toutes les nouveautés

← Toutes les nouveautés