Parlant

Guidelineを巨大なSystem Promptへ詰め込まず、会話ごとに必要なルールだけをContextへ入れる

Parlantでは『条件に合うとき何をするか』をGuidelineとしてコードで定義し、各turnでRelevantなものだけをmatching engineが選びます。READMEでは、system promptが複雑化するとinstruction adherenceが崩れやすく、逆に固定的なrouted graphは自然会話の非線形さへ追従しにくいという問題設定を置いています。Parlantはその中間として、会話そのものは柔軟に保ちながら、LLMへ一度に見せるbehavioral rulesを絞るcontext engineeringを行います。

出典：[1]

RelationshipsとJourneysで、競合ルールの優先順位と複数turnのSOPを明示する

Guideline同士にはdependencyやexclusionを設定でき、『初心者向け説明が必要な場合は専門家向けinstructionをcontextから外す』といった競合解決をモデル任せにせず表現できます。Journeysは予約、本人確認、Troubleshooting、OnboardingなどのStandard Operating Procedureを複数turnにまたがるstateとして定義しますが、一本道のwizardではなく、顧客の発言に応じてstateをskipしたり戻ったりできる設計です。業務手順を守りつつ自然な会話を維持したいケースに向きます。

出典：[1]

重要な場面だけStrict compositionへ切り替え、承認済みCanned Responseで出力を固定する

通常はLLMが文章を生成するFluidな応答を使いながら、規制文言、支払い結果、本人確認、policy案内など誤表現を許容しにくい場面だけStrict compositionへ切り替えられます。Canned ResponsesではAgentがdraftした意図に最も適した承認済みtemplateを選択し、contextに存在しないfieldを参照するtemplateは選ばれません。Toolが返した実データとtemplate fieldを結び付けることで、『成功していないtransactionを成功したように答える』種類のhallucinationを構造的に抑える設計です。

出典：[1][2]

数十〜数百の会話ルールを持つSupport・Finance・Insurance・Healthcare系の顧客Agentへ

FAQ botのように自由回答だけできればよい用途より、ブランドトーン、禁止事項、例外処理、エスカレーション条件、業務SOPを継続的に更新するCustomer-facing Agentと相性があります。特に、System Promptが長大化して変更影響を把握しにくくなったチームや、Product/Complianceからのフィードバックをrule単位で素早く反映したいチームに向きます。OpenTelemetryによるlogs・metrics・tracesを前提にdecisionを追えるため、なぜそのGuidelineやToolが使われたかを運用時に検証したい組織にも適しています。

出典：[1]

会話制御を強くするFrameworkであって、LLM自体を決定論的にするものではない

ParlantはLLM providerそのものではなく、OpenAIやGemini、Azure、OpenRouterなどのNLP adapterを組み合わせて使うcontrol layerです。そのため利用するmodel/APIの料金、latency、data handling、availabilityは別途評価が必要です。またGuidelinesやJourneysを詳細に書けば自動的に正しいAgentになるわけではなく、業務ルールのmodeling、競合relationshipの設計、tool resultのvalidation、traceを使った継続的なtestが必要です。

Strict compositionとCanned Responsesを使う箇所では出力を強く制約できますが、Fluid outputでは最終文面は依然としてLLM生成です。高リスク用途では『Frameworkがあるからhallucinationしない』とみなさず、重要なeventをStrict modeへ寄せる、toolの権限と入力を制限する、人間へのhandoffを用意するなど運用側のcontrolも必要です。ライセンスはApache License 2.0です。

出典：[1][3][4]