すべての企業が Slack、メール、ドキュメント、会議をひとつの頭脳に接続し、社員全員が会社の知るすべてにアクセスできるようにしようとしている。
だが、実際にそれを望んでいる人は誰もいない。
全体会議で「ロードマップはガムテープでくっつけてるようなものだ」と冗談を言えば、会場は笑いに包まれる。8 か月後、新入社員がその頭脳に「ロードマップは予定どおりですか」と尋ねると、笑いの部分だけが抜け落ちたあなたの言葉がそのまま返ってくる。
顧客がオンボーディングのせいで解約しそうになったことを、アカウントエグゼクティブあてのプライベートメールで伝える。プロダクトチームはそれを知る必要があるが、受信トレイごと渡したいと思う人はいない。
あるエージェントがマットの書いた 3 つの提案書を読み、「彼はモノリスを好んでいる」と結論づける。それは正しいかもしれない。しかし、だからといってエージェントが「マットはモノリスを使うべきだと言っていた」と誰かに伝える資格を得るわけではない。彼はそんなことを言っていないのだから。
今日の標準的な権限モデルはシンプルだ。Slack のメッセージが見えるなら、エージェントにも見える。ソースをミラーリングし、その権限を継承し、完了だ。ソフトウェアがソースを返す範囲では、これで機能する。
カンパニーブレインは別のことをする。会議から決定を抽出し、メールと組み合わせ、結果をメモリとして保存し、別の誰かにルーティングし、後日カスタマー対応をするエージェントに渡す。その時点で、情報は元々それを含んでいたオブジェクトをはるかに超えて移動しており、権限モデルもそれに合わせて移動しなければならない。
権限の単位はもはやファイルではない。それはクレームだ。つまり、頭脳が前方へ運ぶあらゆるコンテキストの断片のことだ。「Acme は 9 月までに SSO を必要としている」「リードエンジニアが不在のため、移行は遅れる可能性が高い」。クレームは誰かが直接述べたものかもしれないし、頭脳が 5 つのソースから組み立てたものかもしれない。いずれにせよ、それはもはやどのファイルの外側にも存在し、ファイルの権限ではそれを記述できない。
ソース権限は下限である
ソース権限は依然として必要だ。誰かが Slack チャンネルや Drive フォルダにアクセスできないなら、その人のエージェントが突然閲覧できるようになるべきではない。間違っているのは、情報が変換された後も、ソースの ACL が知る必要のあるすべてを教えてくれると仮定することだ。
ソース権限が答えるのは、ひとつの狭い問いだけだ。このオブジェクトを開けるのは誰か？ カンパニーブレインはもっと難しい問いに答えなければならない。新しく入った営業担当者のエージェントが、CEO が取締役会に伝えたレイオフのスケジュールを知るべきか？ 1on1 での率直な発言が永続的なメモリになるべきか？ 「解約する」と顧客が実際に言ったのか、それとも頭脳が推測したのか？ エージェントはその推測に基づいて行動できるのか？
これらの問いが生じるのは、カンパニーブレインが単なる検索以上のことをするからだ。それは統合（シンセサイズ）を行い、統合が権限の問題を変える。
知識がソースより遠くまで伝わるべきときもある
営業担当者が顧客とのプライベートメールで重要なことを学ぶ。顧客がなぜ購入したのか、なぜ競合他社を選ばなかったのかを説明する。6 か月後、プロダクトチームが同じ問題について議論している。
プロダクトチームが必要なのは教訓であって、受信トレイではない。
今日、この 2 つは結びついている。ソースにアクセスできるか、できないかのどちらかだ。カンパニーブレインはこれらを分離できる。教訓を抽出し、機微な詳細を除去し、証拠に遡れるレシート（参照元）を保持し、必要な人に教訓をルーティングする。受信トレイはプライベートのまま、知識は組織のものになる。
同じことはエンジニアリングでも起こる。制限されたチャンネルであるニッチな回避策を発見した人がいるとする。3 か月後、別のエンジニアが同じバグに遭遇する。2 人目のエンジニアは、そのチャンネルのすべての会話へのアクセス権を継承することなく、1 人目の発見の恩恵を受けるべきだ。
会社は、個々の社員が見える以上のことを知っている。頭脳は、周囲のすべてを公開せずに、役立つ部分だけを移動できるべきだ。
知識がソースほど遠くまで伝わるべきでないときもある
会議の録画が全社に共有される。最初の 5 分間は雑談だ。誰かが週末の話をし、誰かが同僚について冗談を言い、誰かが間違っていると思う決定について不満を漏らす。その後、会議が始まり、グループは重要なプロダクトの決定をする。
全員が正当に録画にアクセスできるかもしれない。だからといって、すべての文が永続的な会社のメモリになるべきだということではない。
人間はこれを自然に理解している。私たちは常に、その場にいる人にとっては適切でも、永続的な組織知識としては不適切なことを言う。6 人の同僚に個人的なことを話しても、1 年後に新入社員がそれを検索できるようにしたいわけではない。半分しか固まっていない意見を口にしても、それを自分の確定見解として扱われたいわけではない。冗談は、トーンと聴衆から切り離され、数か月後にエージェントによって表面化されると、まったく別の受け取られ方をする。
ソースの ACL はこれを一切表現できない。頭脳はコンテンツの意味を理解しなければならない。会議の一部は永続的なメモリになるべきであり、一部は録画内でのみ利用可能にすべきであり、一部は組織メモリから完全に消えるべきだ。
人々は会議レコーダーが参加すると、すでにより慎重になる。すべての会話が自動的に永続的で検索可能な会社メモリに蒸留される世界を想像してみてほしい。人々は冗談を減らし、半端なアイデアを口にしなくなり、個人的な文脈を仕事の会話に持ち込まなくなるだろう。会社はより多くの言葉を獲得し、より少なく理解する。
選択的忘却は優れたカンパニーブレインの一部だ。すべてを覚える頭脳は、いずれ理解しようとしている人々の行動を変えてしまう。
エージェントのトレースは新しい会議録画である
エージェント自体が、数年前にはほとんど存在しなかった会社のコンテキストのソースになりつつある。
エンジニアがコーディングエージェントと 3 時間作業するかもしれない。最後に会社が得るのはプルリクエストだ。しかし PR は最終的な成果物にすぎない。その過程で、エージェントはファイルを検査し、ツールを呼び出し、アプローチを却下し、制約を発見し、エンジニアから修正を受け、コードがどうあるべきかについて決定を下している。そのコンテキストのほとんどは消えてしまう。
私たちは、決定に至る会話の中に有用な情報が含まれているからこそ、会議を記録する価値があると判断した。エージェントのトレースは会議録画に相当する。最終成果物は何が変わったかを教える。トレースはなぜを教える。ある設計が却下された理由、コードベースのどこにもない制約、エンジニアが会話に貼り付けた顧客要件、来月また重要になる修正が含まれているかもしれない。
エージェントがより多くの作業を行うようになるにつれて、会社の推論のより多くがこれらのインタラクションの中で行われるようになる。トレースを捨てることは、組織的知識の増え続けるシェアを捨てることだ。
それはすべてのトークンを永遠に保存するという意味ではない。生のトレースにはノイズ、失敗した試み、機密、個人的なプロンプトが含まれている。有用なオブジェクトは決定履歴だ。何が起こったかを再構築するのに十分な証拠に加えて、永続的なメモリになる価値のある部分が含まれている。
これは新たな所有権の問題を生み出す。ジェシカが会社を辞めたら、彼女のコーディングエージェントが学んだすべてのことも去るべきだろうか？
おそらくそうではない。エージェントは、移行がなぜ失敗したのか、顧客の例外がどう機能するのか、どの設計がすでに 2 回却下されたのかを学んでいたかもしれない。その知識は会社に属する。しかし、同じエージェントには、ジェシカが誰かのパフォーマンスレビューを準備したり、同僚との衝突について話し合ったりした会話が含まれているかもしれない。それは共有された組織的メモリになるべきではない。
システムは、コンテキストが作成されている間にこの 2 つを分離する必要がある。退職処理のときでは遅すぎるからだ。
帰属は権限の一部である
カンパニーブレインは、誰も書き留めなかった情報も作成する。
システムがマットの書いた 3 つの提案書を読み、彼が特定のアーキテクチャを好むと結論づけたとする。それは有用なコンテキストになり得る。しかし、システムはこう言うべきではない：
マットはこのアーキテクチャを使うべきだと言った
マットはそんなことを言っていない。頭脳が推測したのだ。
この区別が重要なのは、「マットが X と言った」という発言は「システムがマットの仕事から X を推測した」という発言よりも重みがあるからだ。前者の発言にはレシートが必要だ。マットが実際にそう言ったメール、トランスクリプト、またはドキュメントの該当箇所。そうでなければ、システムは自分の声で語らなければならない：
マットが書いた 3 つの提案書から推測
すべての重要なクレームには来歴が必要だ。それはどこから来たのか？ 明言されたのか、推測されたのか、不明なのか？ どの程度新しいのか？ システムはどの程度自信を持つべきか？
そしてその履歴は、変換後も生き残らなければならない。プライベートメールは、エージェントが要約したからといって無制限にはならない。推測は、3 回繰り返されたからといって引用にはならない。信頼できるカンパニーブレインは、そのチェーンを保存しなければならない。
要約は権限を洗浄する。推測は帰属を洗浄する。
権限には時計がある
システムが今日誰が知るべきかを知っていたとしても、その答えは明日変わることがある。
チームが新しい従業員特典を開始することに決めたとする。開始を準備する人々はすぐに知るべきだ。顧客は知るべきではない。他の社員は金曜日の全体会議で知るかもしれない。発表後、その情報は採用、営業、マーケティングに流れていく。
根本的な事実は何も変わっていない。だが、適切なオーディエンスは変わった。
この種の意図は、めったにどこにもエンコードされない。「これを自分で発表したい」と思っていても、エンバーゴフラグを設定する人はいない。顧客は、自分のストーリーが営業担当者の役に立つのは嬉しいが、LinkedIn の投稿に変えられるのは居心地が悪い。創業者は「エンバーゴ」という言葉を口にせずに、今後の製品についてカジュアルに話す。
人間は多くの権限ポリシーを頭の中で抱えている。時にはシステムが尋ねなければならない：
あなたは今、大きなプロダクト決定を下しました。これを会社と共有しますか？
難しいのは、いつ割り込むかを知ることだ。5 分ごとに許可を求めるシステムは、人々がそれを無視するように訓練してしまう。人間の判断は、答えが本当に曖昧で、結果を取り消すのが難しいケースのために取っておくべきだ。内部の観察を 1 人のチームメイトと共有するのは元に戻せる。外部に公開すること、顧客メールを送信すること、または取り消し不可能なアクションを取ることは、はるかに高いハードルに値する。
システムは日常的なケースを自動的に解決し、レシートを残し、判断が重要なわずかな決定のために人間の注意を取っておくべきだ。
単一企業は簡単なケースである
ほとんどの権限システムは、1 つの組織と 1 つの管理者を想定している。エージェントはその想定を壊すだろう。
購入者側のエージェントは販売者側のエージェントと話すだろう。会社のエージェントは従業員の個人エージェントと連携するだろう。サポートエージェントは内部知識を外部の回答に変えるだろう。やがてカンパニーブレインは他のカンパニーブレインと直接コンテキストを交換するようになり、両側を制御する単一の権限システムは存在しなくなる。
そして「内部」対「外部」という区分は単純すぎる。顧客との署名済み契約は、内部 CRM フィールドよりも権威があるかもしれない。別の会社のエージェントによって推測されたクレームは、調査には有用かもしれないが、取り消し不可能なアクションを引き起こすほど信頼できるとはほど遠い。
コンテキストは、その権威を携帯する必要がある。ある情報は、読むには安全、推奨に使うには安全、アクションの唯一の根拠として使うには安全でないかもしれない。この違いは、エージェントが質問に答える以上のことができるようになると、決定的に重要になる。
個人所有のエージェントは、その境界をさらに難しくする。彼らのメモリは仕事をまたがるかもしれない。個人は自分のプライベートな履歴を保持し、雇用主は会社が費用を負担して生み出した仕事の知識を保持すべきだ。機密の会社コンテキストが次の会社に漏れてはならず、個人コンテキストが前の会社に吸収されてもならず、その境界はメモリ自体の中に存在しなければならない。
権限モデルは知識とともに移動する
これらの次元は独立している。ある会社は厳格なソース境界と強力なコンテンツフィルタリングを持つことができる。別の会社は、生の会話をほとんど保持せずに、有用な知識をチーム間で積極的に移動させることができる。エージェントが作成したコンテキストはまた別のソースだ。人間の判断はエスカレーションメカニズムである。帰属、タイミング、オーディエンス、アクション権限は、それらのすべてに横断する。共通のプリミティブはクレームだ。
カンパニーブレイン内のすべての永続的なクレームは、独自のポリシーを携帯すべきだ。少なくとも、頭脳は以下を知る必要がある：
- クレームがどこから来たのか、明言されたのか推測されたのか
- 誰がそれを受け取れるのか
- 何に使用できるのか
- メモリにどのくらい残すべきか
- オーディエンスがいつ変わり得るのか
- エージェントがそれに基づいてどのようなアクションを取れるのか
- いつ人間が決定を下す必要があるのか
ソース権限は出発点だ。その後、ポリシーは、要約され、結合され、記憶され、共有されるコンテキストとともに移動する。伝統的な権限はオブジェクトを統治するが、カンパニーブレインは移動する情報を統治しなければならない。
これは後付けで解決できる問題ではない。無差別な頭脳を 1 年間稼働させた会社は、1 年間分の取り消し不可能なメモリを書き込んだことになる。冗談、不満、半端な意見、引用として提示された推測。さらに悪いことに、その 1 年間で、社員に「頭脳が自分の発言をどう扱うか」を教えてしまっている。従業員がすべてが永続的で検索可能になることを学ぶと、彼らは違う話し方になり、後で権限モデルを修正しても、率直さは戻ってこない。
理解は複利で増幅する。不信も同様だ。最初から権限モデルを正しく設計した企業は、社員が実際に前で話す頭脳を持つだろう。
権限はインテリジェンスの一部である
Hyperspell では、カンパニーブレインを構築している。メッセージ、ドキュメント、会議、システム、エージェントを横断して、会社が何を知っているかを継続的に更新するモデルだ。
コネクタはセンサーレイヤーだ。より難しい作業は、そのすべてのコンテキストが相互作用し始めた後に始まる。頭脳は、どのソースを信頼するか、何がメモリになる価値があるか、結論がどこから来たのか、誰がそれを受け取るべきか、エージェントがそれで何をすることを許されるかを決定しなければならない。
有用な知識は、周囲のすべてを公開せずに、それを必要とする人々とエージェントに届くべきだ。カジュアルな会話はカジュアルなままでいられ、推測は推測のままであり、会社の知識は、周囲の個人的なものをすべて吸収することなく、従業員の入れ替わりを生き残るべきだ。時には頭脳は、発言する前に尋ねることを知るべきだ。
これは Hyperspell で私たちが解決している中核的な問題のひとつだ。本当の権限モデルを備えたカンパニーブレインがどのようなものかを見たいなら、15 分でお見せできる。
役立つカンパニーブレインは、会社が何を知っているかを知っている。
信頼できるカンパニーブレインは、いつ黙るべきかも知っている。
