Conception d’un agent harness : choisir le bon modèle

Le routage de modèles est un contrôle opérationnel, pas un concours de benchmarks. Confidentialité et résidence définissent d’abord le pool admissible ; réussite de la tâche et qualité sélectionnent les routes viables ; tokens, latence et coût ne s’optimisent qu’ensuite. Les modèles locaux exigent souvent davantage de décomposition, de retrieval et de vérification déterministe.

Le harness est l’unité productive

Un agent d’entreprise est un harness : intake, assemblage du contexte, policy gates, modèle, outils, état, vérification, reprises, observabilité et escalade. Le modèle n’en est qu’un composant remplaçable. Un benchmark isolé prédit mal les performances sur les formats, droits, vocabulaires et workflows réels.

Nous ne choisissons donc pas « le meilleur modèle », mais un chemin d’exécution admissible qui atteint un état métier vérifié. Une couche d’opérations IA organisée par threads maintient routage, état, autorisation et preuve quand l’exécuteur change.

Gate un : confidentialité, résidence et admissibilité contractuelle

Chaque classe de tâches possède un profil couvrant classification des données, régions de traitement et stockage, rétention et usage d’entraînement, sous-traitants, chiffrement, identité, audit, droits de production et sortie éventuelle des documents retrouvés. Une route non conforme est exclue avant tout test de qualité.

La résidence concerne tout le chemin : fichiers temporaires, index, traces, files de revue et sauvegardes, pas seulement l’endpoint d’inférence. Une redaction doit être testée sur les formats réels ; retirer un nom en conservant un identifiant unique n’est pas anonymiser. Ce gate produit des routes permises, sans encore les classer.

Gate deux : réussite de la tâche, puis qualité

Réussir signifie atteindre l’état attendu : réponse étayée et citations résolubles, enregistrement conforme au schéma et relié aux sources, ou action approuvée avec readback. Une prose élégante avec outil interdit, source absente ou format invalide reste un échec.

Le jeu d’évaluation comprend cas fréquents, limites de politique, données manquantes ou contradictoires, pannes d’outils, injections, escalades obligatoires et variations de langue ou format. Schéma, autorisation, preuve et abstention sont évalués avant le style. Les skills d’agents spécialisés stabilisent procédures et contrôles.

Gate trois : tokens, latence et coût

Nous mesurons le coût par tâche vérifiée, pas le prix par token. Reprises, revue et correction peuvent rendre un modèle bon marché plus coûteux ; une première réponse rapide peut masquer une mauvaise latence de bout en bout.

Dimension	Mesure au niveau du harness
Réussite	achèvements vérifiés par tentative admissible
Qualité	acceptation initiale, gravité et taux d’échappement
Tokens	entrée, cache, sortie et reprises par achèvement
Latence	médiane et queue du déclencheur à l’état vérifié
Coût	inférence, retrieval, outils, revue et retouche
Stabilité	variation dans le temps, les formats et les classes

La route actuelle vaut Baseline = 100 pour coût ajusté de la qualité et latence. Un indice inférieur n’a de valeur que si réussite, charge d’exceptions et temps de revue restent dans leurs limites.

Router les tâches, pas les utilisateurs

Une personne peut demander résumé public, comparaison confidentielle, rapprochement et écriture en production. Nous routons une enveloppe explicite :

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Classe, résidence et autorité restent déterministes ; en cas d’incertitude, le router choisit la voie plus sûre. Le reçu conserve versions de policy, modèle, prompt ou skill, preuves, appels d’outils, vérifications et état final.

Pourquoi les modèles locaux demandent un autre harness

Ils offrent contrôle des données, coût marginal prévisible et fonctionnement hors ligne, mais peuvent être moins réguliers sur instructions, outils, long contexte ou langues.

Décomposer davantage

Séparer sélection, extraction, classement, rédaction et vérification. Chaque étape possède un contrat étroit et un checkpoint déterministe.

Récupérer moins, mais mieux

Un dépôt entier dans le contexte n’est pas du retrieval. Index structurés, filtres, fraîcheur et courts paquets de preuves réduisent le bruit. Les pratiques d’un assistant IA local avec retrieval et recherche web montrent l’importance de cette couche.

Vérifier de façon déterministe

Schémas, parsers, allow-lists, contraintes de base, calculs, moteurs de règles et readback vérifient champs, identifiants, totaux, droits et état final. Une grille indépendante couvre le sémantique ; le même appel ne doit pas générer, noter et approuver.

Cascades, fallbacks et abstention

Une cascade commence par la route qualifiée la moins coûteuse et escalade sur des signaux observables : schéma invalide, preuve manquante, conflit de sources, outil indisponible, policy gate ou échec du verifier. Un fallback ne peut contourner résidence ou autorité, ni prétendre qu’une action a eu lieu. Refuser ou escalader correctement compte comme réussite lorsque le contrat l’exige.

État, versions et reproductibilité

Nous versionnons tâche et policy, fournisseur et région, modèle, prompt, skill, schémas d’outils, requête de retrieval, sources et fraîcheur, paramètres, verifiers, reprises, revue, action et readback. La reproductibilité vient des entrées, configurations, actions et preuves, pas du stockage illimité d’une chaîne de pensée. Le réglage d’un agent propre à un projet rappelle que les workspaces persistants ne valent que si changements et erreurs restent observables.

Un processus de sélection pratique

1. Définir les classes de tâches.
2. Appliquer les gates d’admissibilité.
3. Construire un jeu représentatif, limite et hostile.
4. Tester dans le vrai harness avec outils et verifiers.
5. Éliminer les violations dures.
6. Noter réussite et qualité, y compris les défauts graves.
7. Mesurer tokens, latence, revue, reprises et retouche.
8. Piloter en shadow ou dry-run.
9. Approuver par classe avec limites et fallback.
10. Réévaluer lors de changements ou de dérive.

Le résultat est une policy de routage versionnée et étayée, pas un classement permanent.

La règle de décision

Confidentialité, résidence et contrat déterminent ce qui est permis. Réussite vérifiée et qualité déterminent ce qui est capable. Tokens, latence et coût total déterminent ce qui est efficient parmi les routes restantes. Le bon choix est le plus petit système admissible qui termine la tâche dans la limite de qualité et en apporte la preuve.

Insights associés

• Architecture de référence pour une couche d’opérations IA par threads — routage, état, autorisation et vérification
• Skills d’agents pour workflows spécialisés — procédures et contrôles métier externalisés
• Assistant IA local avec recherche web et retrieval — modèle pratique d’inférence locale, de preuve et d’outils