Basis описала в Cursor контроль многочасовых бухгалтерских AI-агентов

Long-horizon — это цепочка зависимых решений

Basis разрабатывает AI-агентов для бухгалтерских процессов: month-end close, корпоративных и партнёрских налоговых деклараций, audit planning и fieldwork. Эти системы работают в фоне много часов и возвращают результат, который должен быть готов к профессиональной проверке.

В описании Basis термин long-horizon означает не просто длительный запуск. Агент принимает сотни связанных решений, сохраняет промежуточное состояние, учитывает tool calls и восстанавливается после сбоев, иногда работая с объёмом информации больше одного context window. Ошибка на раннем этапе способна повлиять на последующие расчёты, поиск и итоговый artifact.

Для бухгалтерии проблема усиливается высокой ценой ground truth. Проверенный production-пример дорог, полный результат может готовиться и оцениваться часы или дни, а у многих промежуточных решений нет дешёвого объективного теста. Поэтому финальный правильный ответ ещё не доказывает надёжность пути, которым агент к нему пришёл.

Контекст рассматривается как production input

Basis относит prompts, skills, instructions, tool descriptions, memory и domain knowledge к производственным входным данным. Поскольку они написаны естественным языком, изменение формулировки или расположения исключения может изменить следующее действие модели. Команда использует Cursor как среду, где этот контекст читают и редактируют с той же внимательностью, что и код.

Такой подход противостоит практике, при которой контекст генерируется автоматически и сразу отправляется в production. Basis подчёркивает: расплывчатая фраза, спрятанное исключение или неудачный пример способны изменить реальное поведение агента, поэтому инженер должен видеть завершённый документ и понимать его целиком.

Cursor в этом процессе даёт обычный редактор, Markdown preview, работу с моделью рядом с текстом, переключение моделей и side-by-side цикл между файлом и agent window. Это не заменяет runtime Basis: среда используется для ревизии текста, который затем управляет отдельной агентной системой.

Behavior spec отделён от prompt

Behavior spec у Basis — это Markdown-документ с ожидаемым повторяемым поведением в определённой ситуации. Он написан для людей и judges, которые проверяют записанную траекторию, не показывается агенту и не является его prompt. Документ задаёт условия применения, требуемые evidence, ожидаемое решение и действие, работу при неполных данных и признаки провала.

Judge получает spec, наблюдаемую траекторию и evidence — tool calls, artifacts, найденные источники и decision records. Результат проверки имеет три значения: true, false или NA. Так команда может оценивать важные фрагменты процесса без полного эталонного ответа для многочасовой задачи.

Разделение spec и implementation уменьшает риск подгонки инструкции под саму проверку. Spec фиксирует стандарт поведения, а runtime меняется до тех пор, пока агент не выполняет его стабильно. При этом качество spec тоже требует ревизии: слишком расплывчатый критерий невозможно судить, а слишком жёсткий может закрепить один путь вместо требуемого результата.

Ошибка возвращается в измеримый цикл разработки

Процесс начинается с выбора повторяемого поведения, которое стоит измерять. Инженер формулирует или уточняет behavior spec в Cursor, агент выполняет работу в runtime Basis, а judge сверяет записанную траекторию со стандартом. Verdict false указывает на разрыв между ожидаемым поведением и текущей реализацией.

После провала команда меняет runtime context, tools, prompts или execution framework, снова запускает агента и измеряет, улучшилось ли поведение. В этой схеме правка естественного языка становится обычным production-изменением: у неё есть критерий, наблюдаемый прогон и результат повторной оценки.

Basis и Braintrust опубликовали behavior-spec approach как открытый стандарт. Его принцип полезен шире бухгалтерии: итоговый artifact оценивает результат, а траектория показывает, были ли проверены первичные основания, сохранены источники чисел и соблюдены обязательные контрольные точки.

Заявленные результаты и границы кейса

По данным кейса Cursor, агенты Basis выполняют более пяти часов работы над одним deliverable. Для партнёрской декларации Form 1065 задача, которая занимает у человека примерно 30–40 часов, выполняется агентом приблизительно за 6–7 часов. Cursor также сообщает, что Basis доверяют 40% из 25 крупнейших бухгалтерских фирм.

Это показатели из совместного customer story, а не независимый аудит точности налоговых деклараций. Они показывают масштаб заявленного внедрения и выигрыш по времени, но не раскрывают частоту исправлений, сложность дел, стоимость human review или долю работ, дошедших до подачи без существенных изменений.

Главный переносимый результат кейса — не конкретный коэффициент ускорения, а архитектура контроля. Для многочасового агента нужно отдельно хранить стандарт поведения, полную наблюдаемую траекторию и runtime-контекст, а затем связывать verdict с конкретной правкой. Без этой цепочки правильный финальный файл может скрыть неповторяемый или рискованный процесс.