프로토타입은 쉽습니다. 하지만 프로덕션 에이전트는 쉽지 않습니다.

더 나은 모델과 더 긴 컨텍스트 창이 에이전트가 프로덕션에서 실제로 마주하는 문제인 환각을 해결하지는 못합니다. 환각은 모델 실패가 아니라 검색 실패입니다. 더 똑똑한 모델이라도 행동해야 할 때 신뢰할 수 있는 최신 데이터 중 필요한 부분에 접근할 수 없다면 여전히 환각을 일으킬 수 있습니다.

이는 대개 신뢰성 문제처럼 보이는 지속성 문제입니다. 상태(단일 실행이 생성하는 것)와 메모리(실행 간에 에이전트가 유지하는 것)는 수명 주기가 다르므로 이를 하나로 취급하면 '신뢰할 수 없음'으로 이어집니다. 중단 후에도 문제없이 복구할 수 있는 것은 프로덕션 에이전트의 기본 요구 사항이므로, 메모리는 확장 가능하고 높은 성능을 유지하면서 지속적으로 보존되어야 합니다.

메모리, 거버넌스, 평가, 오케스트레이션은 워크플로 엔진에 덧붙이는 기능이 아니라 별도의 제품 범주입니다. 이 모든 것을 사내에서 구축하려면 상당한 엔지니어링 노력이 필요합니다. 실용적인 접근 방식은 비즈니스에 특화된 부분은 직접 구축하고, 그 아래에서 이를 뒷받침하는 기술 범주는 구매하는 것입니다.

이는 보안상의 공백으로 나타나는 조율 문제입니다. 공유된 도구 레지스트리가 없으면 배포하는 모든 새 에이전트가 엔지니어링 작업의 중복, 추가적인 보안 노출, 기술 부채 증가를 초래합니다. 해결 방법은 팀마다 일회성으로 문제를 해결하는 것이 아니라, 어떤 도구가 있는지, 누가 소유하고 있는지, 무엇이 검토되었는지를 중앙에서 한눈에 파악할 수 있도록 하는 것입니다.

적합한 데이터베이스를 사용하면 그렇지 않습니다. 에이전트 코딩은 반복적입니다. 작은 변경 사항이 있을 때마다 작업을 멈추고 마이그레이션 스크립트를 작성할 필요가 없어야 합니다. MongoDB의 document model을 사용하면 코드에 맞춰 스키마를 조정할 수 있으므로, 스키마에 맞춰 코드를 조정할 필요가 없습니다. 전체 스택에도 마찬가지입니다. 트랜잭션, 검색, 분석 및 벡터를 하나의 플랫폼에서 제공하면 에이전트와 사람의 작업 속도를 늦추는 복잡한 도구 환경을 방지할 수 있습니다.