## Les évaluations sont des fonctionnalités, pas des produits Je suis à cette rencontre de codage d'agents ce soir avec OAI, Any, GDM, Cursor, Factory, Delphi, Exa, @theo, etc. La conclusion surprenante de ce panel, si je peux me permettre de paraphraser, était que theo a dit qu'il y avait trop de startups d'évaluations et que thariq, nate et romain ont tous étonnamment convenu que oui, vous devriez continuer à construire plus d'agents, ne vous inquiétez pas des agents de biglab, ce sont aussi essentiellement de petites startups internes de toute façon, et vous aurez probablement une perspective différente et le monde a besoin de le voir. ALORS et seulement alors vous construirez de bonnes évaluations.

il y a plein d'opinions sur l'ingénierie des agents qui disent "keep it simple, stupid" et qui réduisent cela à "agent = llm + outils + boucle + objectif" c'est un agent minimal viable, et c'est super ! mais la raison pour laquelle cette définition est trop minimaliste pour être utile, c'est qu'elle vous fait oublier tout ce qui rend les agents BON : - planification - mémoire - confiance/auth - évaluations* en février, j'ai sondé toutes les réponses aux demandes de définitions de Simon et je les ai déjà regroupées pour vous. avec un acronyme bonus pour ARRÊTER D'OUBLIER LA MÉMOIRE, LA PLANIFICATION ET LES FLUX D'AUTH "agent = llm + Intent + Mémoire + Planification + Auth/confiance + Flux de contrôle + Utilisation d'outils" *aha ! vous pensiez que j'étais contre les évaluations ? parce que vous ne pensez qu'en binaire ?

c'est un peu ironique que nous ayons résolu le problème MxN -> M+N avec MCP et ensuite, la prochaine chose que tout le monde fait maintenant, c'est de lancer ses propres registres MCP (je compte au moins 6 en ce moment) babel a pleuré