責任トポロジーは、エージェント時代のソフトウェアエンジニアリング：Trustworthy Change から人間–エージェント・ソフトウェア組織へ で提案された組織の分類である。これは、組織において現に有効なガバナンス規則のもとで、ソフトウェアのベースラインに対する残余リスクを受け入れる、または拒否する権限がどのように分布しているかを記述する。その単位は責任アンカー（responsibility anchor）である。責任アンカーとは、自然人または制度上の役割にまで遡ることができ、ベースラインまたは主要な責任領域について残余リスクを受け入れる、あるいは拒否する正式な権限を持つノードであり、たとえばプロダクト、セキュリティ、アーキテクチャのオーナーやリリース権限者がこれにあたる。同論文のモデルでは、エージェントは運用上の権限を与えられ、監査可能な実行者として記録されることはありうるが、残余リスクの受け入れは特定可能な人間または制度上の主体にとどまる。
用法
同論文は 2 つの基本形を定義している。組織が単一センター型（single-center）であるのは、1 つの最終アンカーが現在のベースラインについて残余リスクを受け入れる、または拒否することができ、ガバナンス規則を変更することなく他の参加者のエンジニアリング上の権限を取り消したり覆したりできる場合である。一人会社がよくある例として挙げられているが、この形は人数によって定義されるものではない。組織がマルチアンカー型（multi-anchor）であるのは、ベースラインに少なくとも 2 つのアンカーがあり、それぞれが主要な領域に対する受け入れ権を持ち、その権利を通常のガバナンスのもとで他のアンカーが一方的に取り消せない場合である。そうした領域を複数またぐ変更は、必要なアンカーのすべてが受け入れた場合にのみ受け入れられる。
同論文の中心的な主張は、この分類が、組織に属する人間、エージェント、あるいは ヒューマン・エージェント・セル の単位の数とは独立しているというものである。創業者が 1 つのコーディングエージェントから 20 の同時稼働エージェントへ移行しても、実行グラフは変わるが、最終的なリスク受け入れがどこにあるかは変わらない。契約者、レビュアー、専門家を加えても、それだけで新たな責任センターが生まれるわけではない。そして 2 人のエンジニアでも、それぞれが独立した取り消し不能な受け入れ権を持つならマルチアンカー型の組織を形成しうる。同論文は、この区別がエンジニアリング上の振る舞いを変えると論じている。単一センターのもとでは、相反するエビデンスは最終的に 1 つのアンカーによって決着をつけられるが、複数のアンカーのもとでは、どの参加者も影響を受けるすべての領域を単独で閉じることはできない。そのため組織は、どの事実が権威あるものか、どの変更が他の作業を無効にするか、ある変更にどのアンカーが必要かを明示しなければならない。また同論文は、実行が終わっても責任が閉じていないことがありうるとしている。すべてのエージェントタスクが完了していても、必要なアンカーのうち 1 つがまだ受け入れていない、という状態である。
同論文によれば、このトポロジーは職名、リポジトリへの書き込み権限、誰が最も多くの変更をマージしているかからは読み取れない。同論文は、これを 3 つの情報源を併せて特定することを提案している。すなわち、形式上の（法律上の）ガバナンス、CODEOWNERS、ブランチ保護、デプロイ権限といった技術的な強制、そして事実上の慣行である。これらが食い違う場合、その食い違いは 1 つにまとめてしまうのではなく記録すべきだとされる。同論文は、役割マトリクス、変更承認委員会、CODEOWNERS、職務分掌の規則を、代替物ではなく隣接する先行概念として扱っている。承認のステップが複数あっても、それらがすべて 1 つの最終的な責任センターのもとに置かれていることがありうるからである。
適用される場面
この分類は、実行能力は伸縮自在になったがリスクの受け入れはそうなっていない、エージェント型のソフトウェア組織を対象として提案されている。同論文は、マルチアンカー型に至る 2 つの経路を区別している。1 つは、規制、専門資格、職務分掌、あるいは独立した安全性・セキュリティ・コンプライアンス上の受け入れといった、それを直接義務づけるハードなガバナンス上の契機である。もう 1 つは経済的な圧力であり、この場合、新たなアンカーが魅力的になるのは、単一センターにかかる検証キュー、注意の負荷、継続性のリスクが、独立に責任を負う領域を正当化するほどになったときに限られる。同論文は、機械的なレビュー能力の不足だけであれば、トポロジーを変えずにエージェントやレビュアーを追加することで対応できると注意を促している。この構成概念は 1 つの研究グループによる提案である。同論文が扱うのは単一センター型とマルチアンカー型のみであり、階層型、連合型、プラットフォームを介した責任の形態は主張の対象外としている。また、チームの規模とリスクを統制した後ではトポロジーが説明力を何も加えない可能性があることを、反証可能な命題として述べている。さらに、「責任トポロジー（responsibility topology）」という語句は、それ以前のある設計ノートで、異なる、より広い意味で使われていたことにも触れている。