Julep AI

Julep 에이전트는 사용자에 대해 배운 것을 저장하고 이후 대화에서 다시 끌어온다. 플랫폼은 그것을 프롬프트에 몰아넣지 않고 전용 기억 저장소에 둔다. 대화가 길어지면 이 점이 중요해진다. 지원 봇이라면 두 번 말하지 않아도 직전 문제를 기억한다.

워크플로를 일련의 단계로 서술하면 Julep이 그 안의 결정, 루프, 병렬 분기를 처리한다. 작업은 두 단계로 끝날 수도 있고 데이터 파이프라인처럼 넓게 퍼질 수도 있다. 이것이 평범한 프롬프트 사슬과 갈리는 지점이다. 대부분의 도구는 프롬프트 하나에서 멈춘다. 이건 멈추지 않는다.

세션은 에이전트와 사용자 한 쌍의 대화 기록과 맥락을 담고, 필요할 때 언제든 멈추고 다시 이어갈 수 있다. 그래서 메시지 사이의 긴 공백이 에이전트가 이미 아는 것을 버리지 않는다. 사용자가 일주일 뒤에 돌아와도 에이전트는 차갑게 시작하지 않고 멈춘 곳에서 이어간다.

Julep은 여러 도구를 갖추고 있고 외부 API도 연결하게 해준다. 에이전트는 무언가를 조회하고 그에 따라 행동하며 같은 작업 안에서 계속 나아갈 수 있다. 연결 배관을 일일이 손으로 짤 필요가 없다. 이는 실제 수고를 덜어준다. 그렇지 않으면 건드리는 서비스마다 새 처리기를 써야 한다.

실패한 단계는 스스로 재시도하고, 오래 도는 작업은 충돌해도 자기 자리를 잃지 않는다. Julep은 이를 위해 밑에서 워크플로 엔진에 기댄다. 여기서 신뢰성은 전부다. 몇 시간 도는 에이전트에서 그것은 데모와 운영에 맡길 만한 것을 가른다. 이것이 없으면 모든 긴 작업이 지켜보기 일이 된다.

플랫폼에는 RAG용 문서 저장소가 들어 있다. RAG는 에이전트가 추측 대신 자신의 자료에서 답하게 하는 기법이다. 자기 문서를 올리면 에이전트는 답할 때 관련 구절을 끌어온다. 그래서 지식 비서를 만드는 팀은 별도의 벡터 데이터베이스를 덧대지 않고도 이걸 얻는다.

플랫폼 전체가 오픈소스라, 데이터를 벤더에 맡기는 대신 자기 서버에서 돌릴 수 있다. 엄격한 데이터 규칙을 가진 팀이나 종속을 피하고 싶은 팀에 어필한다. 에이전트에 관한 어떤 것도 네트워크를 떠나지 않기 때문이다. 대가는 무엇인가. 구축은 내 몫이다. 전담 운영 지원이 없는 작은 팀에는 유지보수가 금방 불어날 수 있다.