Julep AI

Julepのエージェントはユーザーについて学んだことを保存し、後の会話で取り戻す。基盤はそれをプロンプトに詰め込まず、専用の記憶ストアに置く。会話が長くなると、ここが効いてくる。サポートボットなら、二度言われなくても直近の問題を覚えている。

ワークフローを一連のステップとして記述すると、Julepがその中の判断、ループ、並列分岐を扱う。タスクは二つのステップで終わることも、データパイプラインのように広がることもある。これが普通のプロンプト連鎖との分かれ目だ。多くのツールはプロンプト一つで止まる。これは止まらない。

セッションはエージェントとユーザーの一組の会話履歴と文脈を保ち、必要なときにいつでも一時停止し再開できる。だからメッセージの間が長く空いても、エージェントがすでに知っていることを捨てずに済む。ユーザーが一週間後に戻ってきても、冷たい状態から始めず、前回の続きから動く。

Julepには一連のツールが付属し、外部APIもつなげられる。エージェントは何かを調べ、それに基づいて動き、同じタスクの中で続けられる。接続の配管をいちいち手で組む必要はない。これで実際の手間が減る。そうでなければ、触れるサービスごとに新しい処理を書くことになる。

失敗したステップは自分で再試行し、長時間のタスクはクラッシュしても位置を失わない。Julepはそのために裏でワークフローエンジンに頼っている。ここでは信頼性がすべてだ。何時間も動くエージェントでは、デモと本番で任せられるものとを分ける。それがなければ、長いタスクはすべて見守り作業になる。

基盤にはRAG用のドキュメントストアが含まれる。RAGは、エージェントが推測ではなく自分の資料から答えるための手法だ。自分の文書を読み込むと、エージェントは答えるときに該当する箇所を引き出す。だから知識アシスタントを作るチームは、別のベクトルデータベースを足さずにこれを得られる。

基盤全体がオープンソースなので、データをベンダーに預けず自分のサーバーで動かせる。厳しいデータ規則を持つチームや、囲い込みを避けたいチームに響く。エージェントに関するあらゆるものがネットワークの外に出ないからだ。代償は何か。構えは自分の責任になる。専任の運用支援がない小規模チームでは、保守がすぐに膨らむ。