Basis는 회계사를 위한 AI 에이전트를 만듭니다. 이 에이전트는 길고 복잡한 회계 워크플로우를 백그라운드에서 자율적으로 처리하고 바로 검토할 수 있는 결과물을 내놓아, 회계 팀이 판단과 고객 서비스에 집중할 수 있게 합니다.

이 에이전트들은 선도적인 회계 팀을 대신해 월 마감, 법인 및 파트너십 세무 신고, 감사 계획과 현장 실사처럼 몇 시간씩 걸리는 중대한 업무를 맡습니다. Basis는 창업 첫날부터 Cursor 위에서 회사를 키워 왔습니다. 이들은 에이전트가 읽는 컨텍스트(프롬프트, 스킬, 지침, 도구 설명)를 코드만큼 엄격하게 다루며, 그 작업을 읽고 다듬는 공간이 바로 Cursor입니다.

#단일 프롬프트로 환원할 수 없는 저작물

장기라는 말은 단순히 에이전트가 몇 시간 동안 실행된다는 뜻이 아닙니다. 하나의 트래젝터리에 걸쳐 수백 번의 결정이 이루어지고, 뒤이은 단계가 앞선 단계에 좌우되는 경우가 많다는 의미입니다. 시스템은 관련 상태를 보존하고, tool call의 결과를 반영하며, 실패에서 복구해야 합니다. 때로는 단일 context window에 담기지 않는 분량의 정보를 다루면서 말입니다. 오류는 쌓여 갑니다. 초기의 실수 하나가 이후의 조사, 계산, tool call, artifact 전반에 영향을 미칠 수 있지만, 정작 최종 결과만 봐서는 문제가 어디서 시작되었는지 알 수 없습니다.

회계 업무에서는 세 가지 이유로 이 문제가 더 까다로워집니다:

1. 많은 결과에는 저렴하고 객관적인 test가 존재하지 않습니다.
2. 실제 프로덕션 업무에서 가져온 정답 예시는 만드는 데 비용이 많이 들고 규모를 키우기 어렵습니다.
3. 최종 결과를 산출하고 review하는 데 몇 시간에서 며칠이 걸릴 수 있습니다.

최종 결과가 정확하더라도 그 이면에는 신뢰할 수 없는 과정이 숨어 있을 수 있습니다. 에이전트가 조사 근거 없이 올바른 세금 신고서에 도달하거나, 출처를 남기지 않은 채 올바른 수치를 추출하거나, 일반화되지 않는 과정을 거쳐 쓸 만한 워크북을 만들어낼 수도 있습니다. 결과 evaluation은 여전히 중요하지만, 실행 비용이 크고 긴 트래젝터리 안에서 이루어진 모든 중대한 결정을 설명해주지는 못합니다.

#컨텍스트는 프로덕션 입력이다

에이전트의 최종 출력은 시스템의 일부일 뿐입니다. 에이전트의 동작은 작업 전반에 걸쳐 전달받는 컨텍스트, 즉 지침, 도메인 지식, 예시, 도구 설명, 스킬, 메모리를 비롯한 런타임 정보에 따라 달라집니다. 이 컨텍스트는 자연어로 작성되므로 엔지니어가 직접 읽어야 합니다.

전통적인 프로그램은 파일이 얼마나 잘 정리되어 있는지와 관계없이 동일한 유효 코드를 항상 동일하게 해석합니다. 반면 언어 모델에서는 컨텍스트의 구성과 표현이 모델의 다음 행동을 바꿉니다. 모호한 문장 하나, 눈에 띄지 않게 묻힌 예외 조건 하나, 오해를 부르는 예시 하나가 프로덕션 동작을 바꿀 수 있습니다. 컨텍스트 파일을 생성한 뒤 읽어보지도 않고 배포하는 것은 프로덕션 리스크입니다.

#동작 명세는 기준을 명시적으로 드러낸다

동작 명세는 특정 상황에서 에이전트에게 기대되는 반복적인 행동을 정의한 Markdown 파일입니다. 기록된 트래젝터리를 검토하는 사람과 judge를 위해 작성되며, 프롬프트가 아니고 에이전트에게 노출되지도 않습니다.

잘 작성된 명세는 해당 동작이 언제 적용되는지, 에이전트가 어떤 증거를 확인해야 하는지, 어떤 결정을 내려야 하는지, 뒤이어 어떤 동작이 따라야 하는지, 증거가 불완전할 때는 어떻게 해야 하는지, 그리고 실패가 어떤 모습인지를 분명히 밝힙니다. 목표는 모든 단계를 일일이 스크립트로 규정하지 않고도 동작을 판정할 수 있게 만드는 것입니다.

judge는 명세, 관찰 가능한 트래젝터리, 그리고 증거(tool call, artifact, 가져온 source, 결정 기록)를 받아 true, false, NA 중 하나를 반환합니다. 덕분에 팀은 작업 전체에 대한 완전한 정답이 없어도 과정의 특정 부분만 선별해 평가할 수 있습니다.

#Cursor는 이들이 에이전트를 다듬는 곳입니다

Basis는 Cursor로 에이전트를 만들고 다듬습니다. 엔지니어는 Markdown으로 작성된 동작 명세를 열어 둡니다. 문장을 하나하나 살펴보며 너무 모호하거나 취약하지는 않은지 모델에게 묻고, 해당 문단을 고친 뒤 완성된 문서를 같은 창에서 미리 봅니다. 에이전트가 실제로 보게 되는 프롬프트와 컨텍스트, 즉 스킬과 지침, 도구 설명을 다듬을 때도 같은 환경을 사용합니다.

이런 작업에 Cursor가 적합한 이유는 다음과 같습니다.

• 제대로 된 에디터가 있어 컨텍스트와 명세의 문구를 읽고 고칠 수 있습니다.
• Markdown 미리 보기(수정과 라이브 프리뷰를 한자리에서). Basis의 공동 창업자 Mitch Troyanovsky는 이를 명세와 스킬, 그 밖의 Markdown 문서를 반복해서 다듬는 데 있어 과소평가된 차별점이라고 말했습니다.
• 텍스트와 같은 환경에서 모델과 직접 작업할 수 있습니다.
• 반복 작업 중에도 모델을 손쉽게 전환할 수 있습니다.
• 나란히 놓고 보기: 파일과 에이전트 창이 하나의 루프를 이룹니다. 에이전트 창은 누구나 가지고 있습니다. 차이는 컨텍스트를 들여다보고 바꿀 수 있느냐입니다.

#개발 루프

Basis 엔지니어는 Cursor에서 동작 명세을 작성하고 다듬습니다. 에이전트는 Basis 런타임에서 실행되고, judge가 기록된 트래젝터리를 spec에 비추어 평가합니다.

1. 팀이 측정할 가치가 있는 반복적 동작에 합의합니다.
2. 엔지니어가 Cursor에서 동작 명세을 작성하거나 다듬습니다.
3. 에이전트가 프로덕션에서 작업을 수행하며 트래젝터리를 기록으로 남깁니다.
4. judge가 각 동작를 spec에 비추어 평가하고 true, false, NA 중 하나를 반환합니다.
5. false 판정은 의도한 동작와 런타임 구현 사이의 갭을 드러냅니다.
6. 팀이 런타임 컨텍스트, 도구, 프롬프트 또는 실행 프레임워크를 업데이트하고, 관련 문구는 Cursor에서 수정합니다.
7. 팀이 에이전트를 다시 실행해 동작가 개선되었는지 측정합니다.

spec과 런타임은 서로 분리되어 있습니다. spec이 기준이며, 에이전트가 그 기준을 일관되게 충족할 때까지 구현을 바꿔 나갑니다.

동작 명세 방식은 Basis가 회계 분야의 프로덕션 에이전트를 만들며 쌓은 경험에서 비롯되었습니다. Basis와 Braintrust는 다른 팀도 동일한 범용 포맷으로 에이전트 동작를 정의하고 평가할 수 있도록 이를 오픈 스탠다드로 공개했습니다.

#결과물 자체가 곧 증거입니다

프로덕션에서 그 결과물이 어떤 모습인지 살펴보겠습니다.

• Basis 에이전트는 하나의 산출물에 5시간 이상 작업을 수행합니다.
• 폼 1065 파트너십 신고서의 경우, 사람이 하면 대략 3040시간이 걸리는 작업을 Basis 에이전트는 약 67시간 만에 완료할 수 있습니다.
• Basis는 상위 25개 회계법인 중 40%를 비롯해 여러 선도적인 회계법인의 신뢰를 받고 있습니다.

가장 확실한 증거는 결과물 그 자체입니다. 에이전트는 긴 트래젝터리에 걸쳐 수많은 판단을 내리며, 전문 회계사가 직접 검토하고 사용하는 결과물을 만들어냅니다.

에이전트가 더 길고 더 중대한 업무를 맡게 되면서, 에이전트의 컨텍스트는 프로덕션 입력이 됩니다. 엔지니어는 이를 점검하고, 이해하고, 수정할 수 있어야 합니다.

Basis는 Cursor에서 그 컨텍스트를 관리합니다. 동작 명세는 선별된 기대 사항을 명시적으로 드러냅니다. Braintrust는 그러한 동작이 실제 트래젝터리에서 나타났는지 평가합니다. 실패 사례는 런타임에서 무엇을 바꿔야 하는지를 팀에 알려줍니다.