Cómo Basis crea agentes contables de horizonte largo con Cursor
Basis se creó sobre Cursor desde el primer día. Sus agentes contables completan declaraciones de impuestos de sociedades hasta 6 veces más rápido y cuentan con la confianza del 40 % de las 25 principales firmas contables.
Basis crea agentes de IA pensados específicamente para contadores. Completan de forma autónoma flujos de trabajo contables complejos y de horizonte largo en segundo plano, y entregan resultados listos para revisar, de modo que los equipos de contabilidad puedan centrarse en el criterio profesional y en la atención al cliente.
Estos agentes se hacen cargo de tareas de varias horas y mucho en juego para equipos de contabilidad de primer nivel: cierre de mes, declaraciones de impuestos de empresas y sociedades, planificación de auditorías y trabajo de campo. Basis creó la compañía sobre Cursor desde el primer día. Tratan el contexto que lee el agente (prompts, skills, instrucciones, descripciones de herramientas) con el mismo rigor que el código, y Cursor es donde lo leen y lo revisan.
Trabajo que no puede reducirse a un solo prompt
El horizonte largo no significa únicamente que el agente se ejecute durante varias horas. Significa cientos de decisiones a lo largo de una trayectoria, donde los pasos posteriores suelen depender de los anteriores. El sistema debe preservar el estado relevante, incorporar los resultados de las llamadas a herramientas y recuperarse de los fallos, a veces con más información de la que cabe en una única ventana de contexto. Los errores se acumulan. Un fallo temprano puede afectar a la investigación, los cálculos, las llamadas a herramientas y los artefactos posteriores, mientras que el resultado final puede no revelar dónde se originó el problema.
En contabilidad, esto se complica por tres razones:
- Muchos resultados no admiten una prueba objetiva y barata.
- Los ejemplos de referencia extraídos de trabajo real en producción son costosos de crear y difíciles de escalar.
- Un resultado final puede tardar horas o días en producirse y revisarse.
Incluso un resultado final correcto puede ocultar un proceso poco fiable. Un agente podría llegar a la declaración de impuestos correcta sin respaldo documental, extraer la cifra correcta sin conservar su fuente o generar un libro de trabajo utilizable mediante un proceso que no se podrá generalizar. La evaluación de resultados sigue siendo importante, pero es costosa de ejecutar y no puede explicar cada decisión relevante dentro de una trayectoria larga.
El contexto es una entrada de producción
El resultado final del agente es solo una parte del sistema. Su comportamiento depende del contexto que recibe a lo largo del trabajo: instrucciones, conocimiento del dominio, ejemplos, descripciones de herramientas, skills, memoria y otra información en el entorno de ejecución. Ese contexto está escrito en lenguaje natural, así que los ingenieros tienen que leerlo.
Un programa tradicional interpreta el mismo código válido de la misma manera, sin importar lo ordenados que estén los archivos. Con los modelos de lenguaje, la organización y la redacción del contexto cambian lo que el modelo hace a continuación. Una frase ambigua, una excepción escondida o un ejemplo engañoso pueden alterar el comportamiento en producción. Generar un archivo de contexto y publicarlo sin leerlo es un riesgo para producción.
Las especificaciones de comportamiento hacen explícito el estándar
Una especificación de comportamiento es un archivo Markdown que define la conducta recurrente que se espera de un agente en una situación concreta. Está escrita para las personas y los evaluadores que revisan una trayectoria registrada. No es un prompt y no se le muestra al agente.
Una buena especificación deja claro cuándo se aplica el comportamiento, qué evidencia debe inspeccionar el agente, qué decisión debe tomar, qué acción debe seguir, qué hacer cuando la evidencia es incompleta y en qué consiste un fallo. El objetivo es que el comportamiento se pueda juzgar sin necesidad de guionizar cada paso.
El evaluador recibe la especificación, la trayectoria observable y la evidencia (llamadas a herramientas, artefactos, fuentes recuperadas, registros de decisiones). Devuelve true, false o NA. Eso permite al equipo evaluar determinadas partes del proceso sin contar con una respuesta de referencia completa para toda la tarea.
Cursor es donde revisan al agente
Basis usa Cursor para crear y refinar sus agentes. Un ingeniero tiene abierta una especificación de comportamiento en Markdown. Examina una frase, le pregunta a un modelo si resulta demasiado vaga o demasiado frágil, reescribe el pasaje y previsualiza el documento terminado en la misma ventana. En ese mismo entorno refinan los prompts y el contexto que el agente ve realmente: skills, instrucciones, descripciones de herramientas.
Lo que convierte a Cursor en el lugar idóneo para ese trabajo:
- Un editor de verdad, para poder leer y pulir la redacción del contexto y de las especificaciones.
- Vista previa de Markdown (edición y vista previa en tiempo real a la vez). Mitch Troyanovsky, cofundador de Basis, lo describió como un diferenciador infravalorado a la hora de iterar especificaciones, skills y otros documentos en Markdown.
- Trabajar directamente con un modelo, en el mismo entorno que el texto.
- Cambiar de modelo con facilidad mientras iteras.
- Lado a lado: el archivo y la ventana del agente como un ciclo. Una ventana de agente la tiene cualquiera; la diferencia está en poder inspeccionar y cambiar el contexto.
Cursor es donde inspeccionamos el contexto que moldea al agente y lo revisamos hasta que el comportamiento se sostiene.
El ciclo de desarrollo
Los ingenieros de Basis escriben y refinan especificaciones de comportamiento en Cursor. El agente se ejecuta en el entorno de ejecución de Basis y un evaluador contrasta la trayectoria registrada con la especificación.
- El equipo acuerda un comportamiento recurrente que vale la pena medir.
- Un ingeniero escribe o refina la especificación de comportamiento en Cursor.
- El agente realiza su trabajo en producción y genera una trayectoria registrada.
- Un evaluador contrasta cada comportamiento con la especificación y devuelve true, false o NA.
- Un veredicto false revela una brecha entre el comportamiento previsto y la implementación del entorno de ejecución.
- El equipo actualiza el contexto del entorno de ejecución, las herramientas, los prompts o el framework de ejecución. Esa redacción se revisa en Cursor.
- El equipo vuelve a ejecutar el agente y mide si el comportamiento mejora.
La especificación y el entorno de ejecución se mantienen separados. La especificación es el estándar. La implementación cambia hasta que el agente lo cumple de forma consistente.
El enfoque de especificaciones de comportamiento nació de la experiencia de Basis creando agentes en producción para contabilidad. Basis y Braintrust lo publicaron como un estándar abierto para que otros equipos puedan definir y evaluar el comportamiento de sus agentes con el mismo formato general.
Una respuesta fiscal correcta puede esconder un mal proceso. Quiero saber si el agente consultó la fuente primaria, no solo si el resultado es correcto. La especificación es lo que nos permite juzgarlo.
El trabajo mismo es la prueba
Así se ve ese trabajo en producción.
- Los agentes de Basis realizan más de 5 horas de trabajo sobre un solo entregable.
- En una declaración de sociedad del formulario 1065, un trabajo que puede llevar entre 30 y 40 horas de tiempo humano lo completa un agente de Basis en unas 6 o 7 horas.
- El 40 % de las 25 principales firmas confía en Basis, al igual que firmas contables líderes en general.
La prueba más contundente es el trabajo mismo: agentes que toman muchas decisiones a lo largo de trayectorias extensas y entregan un trabajo que contadores profesionales revisan y usan.
A medida que los agentes asumen tareas más largas y de mayor trascendencia, su contexto se convierte en una entrada de producción. Los ingenieros tienen que inspeccionarlo, entenderlo y revisarlo.
Cursor es donde Basis mantiene ese contexto. Las especificaciones de comportamiento explicitan las expectativas seleccionadas. Braintrust evalúa si esos comportamientos aparecieron en trayectorias reales. Los fallos le indican al equipo qué cambiar en el entorno de ejecución.