대부분의 에이전트 프레임워크는 라이브러리를 건네고 나머지는 알아서 하라고 한다. 이것은 방법론까지 함께 온다. 첫 화면은 기업용 에이전트의 구축과 실행 계층으로 자리매김하며 두 가지 주장을 나란히 둔다. 업무 팀도 개발 팀도 만들고, 플랫폼 팀은 한곳에서 통제한다. 아래쪽 자기 요약은 더 노골적이다. 회사 안에 쌓인 에이전트 구상은 중앙에서 통제 가능한 하나의 플랫폼으로 정리한다.

네 단계: 발견, 구축, 통제, 개선

Discover는 무엇을 자동화할지에 답한다. 수십억 회의 에이전트 실행에서 관찰된 패턴을 티켓, 채팅, 애플리케이션, 프로세스와 맞물려 투입, 가치, 준비도 순으로 정렬한 기회 목록을 낸다. 공유 가능한 시연도 붙어 팀의 순서 합의를 돕는다. Build는 어떻게 만드는지에 답한다. 코드 없는 비주얼 편집기는 Python으로 내보낼 수 있고, 완전한 제어를 위한 코드 우선 인터페이스, 역할로 나눈 에이전트 분업, 결정론적 워크플로가 함께 온다. 회사 설명에 따르면 그 안내는 70만 건의 에이전트 워크플로 패턴에서 나왔다. Govern은 어떻게 통제하는지에 답한다. 통제 계층이 모든 워크플로의 실행 경로에 서서 모델 호출, 도구 호출, 메모리 조회를 실시간으로 추적하고 비용을 계산한다. 여기에 역할 기반 권한과 추가만 가능한 감사 기록, 기업용 신원 관리, 사람 승인 지점, 실행 시점의 민감 정보 마스킹과 정책 검사가 더해진다. Optimise는 어떻게 좋아지는지에 답한다. 모든 운영 실행을 학습 데이터로 바꾸고, 자동과 사람 유도 학습, 실행 중 다중 모델 전환 시험, 외부 평가 서비스에 연결된 채점을 제공한다.

모든 사례에 숫자가 붙는다

고객 사례 구역은 '상황 더하기 지표' 구성이라, 무엇을 세는지에 대해서는 적어도 솔직하다. 한 배달 플랫폼은 잠재 고객 데이터 보강에 써서 월 3천 건이 넘는다. 한 교육 사업자는 과정 설계에 써서 개발 시간을 90% 줄였다. 한 전자서명 업체는 여러 내부 시스템의 리드 데이터를 통합해 첫 접촉을 75% 앞당겼다. 한 고객 응대 현장은 응답 정확도 95%에 도달했다. 한 외식 주문 서비스는 자동 음성 테스트로 품질 검사를 74시간에서 3시간으로 줄였다. 사이트는 또한 포춘 500의 65%가 쓴다고 주장한다. 이런 비율은 고객을 어떻게 세느냐에 달려 있으니 기록해 둘 가치도, 자기 현장에서 한 번 확인할 가치도 있다.

진짜 골격: 에이전트, 플로, 태스크

공식 문서(현행 버전 v1.15.22)는 입문 내용을 세 덩어리로 묶는다. 에이전트는 조합 가능한 도구, 메모리, 지식, 구조화 출력을 지닌 실행 단위다. 플로는 시작, 대기, 라우팅 단계를 엮고 상태를 관리하며 실행을 영속화하고 긴 작업을 중단 지점에서 다시 이어 간다. 태스크와 프로세스는 순차, 계층, 혼합 세 가지 진행 방식을 정의하고 가드레일, 콜백, 사람이 개입하는 지점을 갖는다. 요컨대 누가 하는지는 에이전트가, 어떤 순서로 하고 실패하면 어떻게 할지는 플로와 태스크가 정한다. 트리거 절이 이벤트 기반을 채운다. 메일, 팀 채팅, 고객 관계 시스템에 연결하고 트리거 내용이 crew와 flow로 자동 전달된다. 기업용으로는 배포 자동화, 환경 관리, 동료 초대, 역할 기반 권한이 더해진다. 설치는 가볍다. 명령줄 도구 하나와 인터페이스 키 한 벌이면 시작되고, 새 프로젝트는 JSON을 앞세운 구조를 만들어 에이전트 정의와 crew 단위 설정을 별도 파일로 관리한다. 고전적 구성을 선호하는 이를 위한 레이아웃도 남아 있다.

누구에게 맞는가

세 부류의 팀에 맞는다. 긴 작업 사슬을 여러 전문 역할로 돌려야 하는 개발 팀. 연구자, 필자, 검토자라는 분업은 crew 추상과 그대로 맞물린다. 기업 안에서 컴플라이언스를 지키며 도입해야 하는 플랫폼 팀. 통제, 감사, 승인, 마스킹이 자체 제작 패치가 아니라 제품 기능으로 갖춰져 있다. 그리고 먼저 로컬에서 돌려 보고 통제 계층을 얹을지는 나중에 정하려는 개발자. 프레임워크 본체는 MIT이고, 저장소는 약 58.7k 스타, 8.5k 포크이며, README는 10만 명이 넘는 개발자가 커뮤니티 과정으로 인증을 받았다고 밝힌다.

솔직히 말해 둘 것이 두 가지 있다. 발견과 개선은 플랫폼 규모로 쌓이는 데이터에 기대므로 개인 사용량에서는 가치가 보이지 않는다. 그리고 멀티 에이전트는 구조상 단일 호출보다 토큰을 더 쓴다. 편성을 짜기 전에 어느 단계에 정말 독립된 역할이 필요한지 먼저 따져 보는 편이 좋다.

멀티 에이전트 프레임워크의 진짜 시험은 다섯 에이전트가 모두 말을 할 수 있느냐가 아니다. 일곱 번째로 서로를 기다리기 시작할 때, 어디서 막혔는지 볼 수 있는 곳이 있느냐다.