Basis crée des agents IA conçus spécifiquement pour les comptables. Ils mènent à bien de façon autonome des workflows comptables complexes et à long horizon en arrière-plan, puis restituent des sorties prêtes à être examinées, afin que les équipes comptables puissent se concentrer sur l’analyse et le service client.

Ces agents prennent en charge des travaux critiques de plusieurs heures pour des équipes comptables de premier plan : clôture mensuelle, déclarations fiscales des sociétés et des sociétés de personnes, planification et travaux d’audit. Basis a bâti son entreprise sur Cursor dès le premier jour. L’équipe traite le contexte que lit l’agent (requêtes, skills, instructions, descriptions d’outils) avec la même rigueur que du code, et c’est dans Cursor qu’elle le lit et le révise.

#Un travail qui ne se réduit pas à une seule requête

Le travail à long horizon ne signifie pas seulement que l'agent s'exécute pendant plusieurs heures. Il s'agit de centaines de décisions réparties sur une trajectoire, où les étapes ultérieures dépendent souvent des précédentes. Le système doit conserver l'état pertinent, intégrer les résultats des appels d'outils et se remettre des échecs, parfois sur un volume d'informations supérieur à ce que peut contenir une seule fenêtre de contexte. Les erreurs peuvent s'accumuler. Une erreur initiale peut fausser les recherches, les calculs, les appels d'outils et les artefacts qui suivent, sans que le résultat final ne révèle où le problème a commencé.

La comptabilité complique encore les choses, pour trois raisons :

1. De nombreux résultats ne se prêtent pas à un test objectif et peu coûteux.
2. Les exemples de référence issus de véritables travaux de production sont coûteux à créer et difficiles à passer à l'échelle.
3. Un résultat final peut demander des heures, voire des jours, à produire et à examiner.

Même un résultat final correct peut masquer un processus peu fiable. Un agent peut aboutir à la bonne déclaration fiscale sans s'appuyer sur une source faisant autorité, extraire le bon chiffre sans en conserver la source, ou produire un classeur exploitable au terme d'un processus qui ne se généralisera pas. L'évaluation des résultats reste importante, mais elle est coûteuse à mener et ne peut pas expliquer chaque décision déterminante au sein d'une longue trajectoire.

#Le contexte est une entrée de production

La sortie finale de l'agent n'est qu'une partie du système. Son comportement dépend du contexte qu'il reçoit tout au long du travail : instructions, connaissances du domaine, exemples, descriptions d'outils, skills, mémoire et autres informations d'exécution. Ce contexte est rédigé en langage naturel : les ingénieurs doivent donc le lire.

Un programme traditionnel interprète un même code valide de la même façon, quel que soit le soin apporté à l'organisation des fichiers. Avec les modèles de langage, l'organisation et la formulation du contexte modifient ce que le modèle fera ensuite. Une phrase vague, une exception noyée dans le texte ou un exemple trompeur peuvent changer le comportement en production. Générer un fichier de contexte et le livrer sans l'avoir lu constitue un risque en production.

#Les spécifications de comportement rendent la norme explicite

Une spécification de comportement est un fichier Markdown qui définit la conduite récurrente attendue d'un agent dans une situation précise. Elle est rédigée pour les personnes et les juges qui examinent une trajectoire enregistrée. Ce n'est pas une requête, et elle n'est jamais présentée à l'agent.

Une bonne spécification précise quand le comportement s'applique, quelles preuves l'agent doit inspecter, quelle décision il doit prendre, quelle action doit en découler, que faire lorsque les preuves sont incomplètes et à quoi ressemble un échec. L'objectif est de rendre le comportement évaluable sans scripter chaque étape.

Le juge reçoit la spécification, la trajectoire observable et les preuves (appels d'outils, artefacts, sources récupérées, enregistrements de décisions). Il renvoie true, false ou NA. L'équipe peut ainsi évaluer certaines parties du processus sans disposer d'une réponse de référence complète pour l'ensemble de la tâche.

#Cursor, c'est là qu'ils révisent l'agent

Basis utilise Cursor pour créer et affiner ses agents. Un ingénieur ouvre une spécification de comportement en Markdown. Il examine une phrase, demande à un modèle si elle est trop vague ou trop fragile, révise le passage, puis prévisualise le document final dans la même fenêtre. Il se sert du même environnement pour affiner les requêtes et le contexte que l'agent voit réellement : skills, instructions, descriptions d'outils.

Ce qui fait de Cursor l'endroit idéal pour ce travail :

• Un véritable éditeur, qui permet de lire et de réviser la formulation du contexte et des spécifications.
• L'aperçu Markdown (édition et live preview côte à côte). Mitch Troyanovsky, cofondateur de Basis, y voit un facteur de différenciation sous-estimé pour itérer sur les spécifications, les skills et les autres documents Markdown.
• Le travail direct avec un modèle, dans le même environnement que le texte.
• Le changement de modèle en toute simplicité au fil des itérations.
• Côte à côte : le fichier et la fenêtre de l'agent forment une boucle. Tout le monde dispose d'une fenêtre d'agent. La différence, c'est de pouvoir inspecter et changer le contexte.

#La boucle de développement

Les ingénieurs de Basis rédigent et affinent des spécifications de comportement dans Cursor. L'agent s'exécute dans le runtime Basis, et un juge évalue la trajectoire enregistrée au regard de la spécification.

1. L'équipe s'accorde sur un comportement récurrent qui mérite d'être mesuré.
2. Un ingénieur rédige ou affine la spécification de comportement dans Cursor.
3. L'agent réalise sa tâche en production, produisant une trajectoire enregistrée.
4. Un juge évalue chaque comportement au regard de la spécification et renvoie vrai, faux ou NA.
5. Un verdict faux révèle un écart entre le comportement attendu et l'implémentation dans le runtime.
6. L'équipe met à jour le contexte du runtime, les outils, les requêtes ou le framework d'exécution. Ces formulations sont révisées dans Cursor.
7. L'équipe exécute de nouveau l'agent et mesure si le comportement s'améliore.

La spécification et le runtime restent distincts. La spécification fait référence. C'est l'implémentation qui évolue, jusqu'à ce que l'agent s'y conforme de manière constante.

L'approche par spécification de comportement est née de l'expérience de Basis dans la création d'agents en production pour la comptabilité. Basis et Braintrust l'ont publiée comme un standard ouvert afin que d'autres équipes puissent définir et évaluer le comportement de leurs agents avec le même format général.

#Le travail lui-même en est la preuve

Voici à quoi ressemble ce travail en production.

• Les agents de Basis effectuent plus de 5 heures de travail sur un seul livrable.
• Sur une déclaration de société de personnes Form 1065, un travail qui peut demander environ 30 à 40 heures à un humain peut être réalisé par un agent Basis en 6 à 7 heures environ.
• 40 % des 25 plus grands cabinets font confiance à Basis, tout comme, plus largement, les grands cabinets comptables.

La preuve la plus solide, c'est le travail lui-même : des agents qui prennent de nombreuses décisions sur de longues trajectoires et produisent un travail que des comptables professionnels examinent et utilisent.

À mesure que les agents prennent en charge des tâches plus longues et plus lourdes de conséquences, leur contexte devient une entrée de production. Les ingénieurs doivent l'inspecter, le comprendre et le réviser.

C'est dans Cursor que Basis maintient ce contexte. Les spécifications de comportement explicitent les attentes retenues. Braintrust évalue si ces comportements se sont bien manifestés dans des trajectoires réelles. Les échecs indiquent à l'équipe ce qu'il faut changer dans le runtime.