ナレッジと連携
Codeer が業務につながる方法は大きく二つあります。
- Agent がうまく答えるために使う knowledge
- チームや product が workflow を動かすために使う integration
データをつなぐことで、Agent は丁寧な一般論ではなく、実際の業務ルールに基づいて答えられるようになります。
Consultation Desk なら、たとえば次のような資料です。
- consultation 種別と service definition
- routing rule と escalation boundary
- intake で押さえるべき情報
- 一貫して守るべき policy や handoff detail
この章で決めること
ここでの判断は大きく二つです。
- source material をどこに置くか
- hosted channel だけではなく integration が必要になるのはいつか
前者は Knowledge Base 側の仕事です。後者は、それを Instructions、Attachments、Knowledge Base tool、あるいは API 駆動の flow のどこで使うかという設計です。
まずナレッジ、その次に連携
Knowledge Base には二つの役割があります。
Folders: Agent が使う可能性のあるファイルを整理するConnections: 外部アカウントや接続元を確認する
実務では、operator が最もよく触るのは Folders です。
product や backend integration では、役割はこう分かれます。
- API Access: どの workspace を使うかを決め、key を発行する
- API Reference: engineering team が request flow を実装する
Operator 向けの実用ルール
接続する前に、まず次を考えてください。
- 毎ターン必ず従うべき内容か
- 一部の会話でだけ必要か
- source は Agent が読むのに十分きれいか
その答えで置き場はほぼ決まります。
| 情報の性質 | 向いている場所 |
|---|---|
| 毎ターン必須 | Instructions または Attachments |
| 大きめの参照資料で必要時だけ使う | Knowledge Base tool |
| まだノイズが多く整理不足 | 先に整えてから接続する |
| 自分たちの product や backend が実行すべきもの | API Access と API Reference |
データは管理された snapshot と考える
接続したファイルは、自動で何でも同期される live source ではなく、管理された copy と考える方が安全です。
元ファイルが変わったら、接続済みの version も更新すべきか確認してください。