Fieldnote には 10 人の従業員と約 80 人の専門エージェントがいた。 1 時間ごとに実行されるもの、1 週間に 1 回実行されるもの、人間がタスクを承認した後にのみ実行されるものもあります。彼らはフィードバックを収集し、市場を調査し、統合を維持し、リリースをテストし、ヘルプ コンテンツを草案し、運用上の推奨事項を準備しました。
81人目の労働者は別の工作員ではなかった。それは、Fieldnote の運用責任者、Amara が負っていた目に見えない調整の負担でした。
どのエージェントもどこかに指示がありました。研究エージェントはプロンプトファイルを持っていました。メンテナンス エージェントのコードには再試行ロジックがありました。コンテンツ エージェントはワークスペースでブランド ガイダンスを持っていました。 API が変更されると、3 つのエージェントが同じ障害を別々に検出する可能性があります。製品が定義を変更したとき、下流エージェントの一部がそれを受信しませんでした。アマラさんは、どの成功に古いコンテキストが隠されているかが分からなかったので、朝は成功した実行の概要を読んで過ごしました。
Fieldnote の onemind は、各エージェントを、人間の所有者、プロジェクト メンバーシップ、モデルとアダプターのバージョン、許可されたソース、許可されたアクション、支出制限、スケジュール、キル制御を備えたインテリジェンスとして扱いました。マインドは、すべてのエージェントに共有の会話記憶を与えたわけではありません。ワークフローは、出所と承認状態を含む入力済みの成果物を渡しました。
ある月曜日、フィードバック分析エージェントは、顧客が統合制限を誤解している 18 件のメッセージを発見しました。収集エージェントは、各メッセージを同意、機密性、製品分野、および保持メタデータとともに保存していました。分析エージェントは、匿名化されたテキストと受け入れられたフィードバック分類法を受け取りました。これは、顧客が履歴レコードの同期を期待していたが、統合では新しいレコードのみがサポートされていたという教訓を提案しました。この提案には、証拠、確信、および 2 つの反例が含まれていました。
自動的に何も変更されませんでした。製品所有者は証拠を検討し、教訓を 1 つの統合に絞り込み、それを受け入れました。 onemind の依存関係プレビューでは、ヘルプ ドキュメント、オンボーディング コピー、サポート トラブルシューティング ブランチ、製品バックログ項目という 4 つのダウンストリーム変更が提案されました。それぞれに異なる所有者がいました。
文書エージェントは承認されたタスク パッケージを受け取り、ドラフトを自動的に更新することが許可されました。コンテンツ パッケージには、承認された製品の事実、対象ユーザー、ブランド ルール、ソース参照、および歴史的な同期が計画されていたと主張することの禁止が含まれていました。サポート担当者がトラブルシューティングの説明を受けました。製品計画エージェントはバックログの提案を受け取りましたが、製品の承認がなければ、コミットされたロードマップにそれを追加できませんでした。
その日の午後、メンテナンス エージェントはパートナー API からの既知の 429 エラーに遭遇しました。 onemind パッケージには、指数バックオフ、最大 3 回の再試行、5 ドルの実行バジェット、エスカレーション ルールなど、テスト済みの回復ワークフローが含まれていました。実行時フックは、各再試行の前にこれらの制限を評価しました。
最初の 2 回の再試行は失敗しました。 3 回目では、パートナーが不正な成功応答を返しました。エージェントは続行しようとしましたが、フックは必須フィールドが存在しないことを認識しました。ワークフローを停止し、現在の状態を保存し、パッケージのバージョン、入力アーティファクト、API 応答、コスト、再試行履歴、および関連する失敗したアプローチのエントリを含む例外を開きました。エージェントは、再試行回数を増やすことも、それ自体に対するより広範な API アクセスを要求することもできませんでした。
Amara では、3 回の実行失敗と 40 個の成功メッセージではなく、重大度の高い例外が 1 回発生しました。彼女はそれを統合所有者に割り当てました。さらに 2 人のエージェントが同じ不正な応答に遭遇したとき、onemind はそれらのエージェントを既存のインシデントに重複排除し、影響を受けた数を増やしました。統合所有者は回復パーサーを更新し、テストを追加しました。 onemind はメンテナンス パッケージを再構築し、冪等で失敗したステップのみを再生しました。
1 週間後、構成エラーの後、別の運用エージェントが重複した CRM タスクを作成し始めました。 Amara はプロジェクト レベルのキル スイッチを使用しました。実行可能な操作アクションは停止されましたが、読み取り専用のマインド アクセスと監査データは引き続き利用可能でした。チームは構成を修正し、記録された入力に対してワークフローをシミュレートし、アクションを段階的に復元しました。
2 か月後、Fieldnote では、ほぼすべてのルーチン実行を人間が読む必要がなくなりました。人間はすべての結果的な例外とリスクベースの成功サンプルをレビューしました。測定期間中、見逃された高重大度例外はゼロのままでした。同社はまた、テレメトリとアーティファクトのストレージにも以前より多くの費用を費やしており、アマラはノイズの多いルールを毎週調整する必要がありました。
代理店は自主管理会社になっていませんでした。製品の決定、お金、顧客との約束、ポリシーは依然として指名された人間に属していました。 onemind により、代表団は読みやすくなりました。すべてのエージェントが会社の働き方の関連部分を理解しており、結果として生じるすべてのアクションが制限され、すべての例外が次に何が起こるかを判断するのに十分な履歴とともに到着しました。