Execution architecture¶

English | 日本語

作業に応じた改善と成果の観測¶

軽微な修正は既存の着手判断と delivery gate を使い、追加の計画・観測記録・承認を 要求しません。任意の work-route projection は判断を再現可能にし、不明な情報が ある場合は既存の安全な手順を維持します。詳細は 着手判断の契約 を参照してください。

新しい重要な成果観測計画には v2 を使い、担当者、有限の判定期間、成功・失敗の 基準、証拠が得られない場合の対応を記録します。既存の v1 計画は明示的な改訂まで 元の契約で扱い、検証だけで観測を予約することはありません。 観測計画の正本 が入力と互換性を定義します。

改善の採用・却下・延期は正本の Work Item に記録し、延期には再検討のきっかけを 付けます。再現テストによる機械的な予防が支持されても、運用上の再発や製品成果は 未観測・取得不能のままで構いません。対象イベントがないことを成功とはみなしません。 学習の正本 が三種類の証拠と任意の検証を定義します。別の backlog、常駐監視、公開権限は追加しません。

Current interaction sequence¶

この view は、interactive request または optional Control wake-up から accepted delivery evidence まで、 誰がどの順序で作用するか、という一つの問いへ答えます。

sequenceDiagram
    actor Human
    participant Control as Optional Control
    participant Codex
    participant AIT as AI Teams
    participant GitHub
    participant Provider as Selected provider

    alt Interactive request
        Human->>Codex: work を依頼し authority を供給
    else Trusted orchestrated wake-up
        Control->>Codex: isolated work を開始
    end
    Codex->>AIT: coordination contract を実行
    AIT->>AIT: Goal、constraint、profile、Bet を確立
    opt Bounded independent challenge が justified
        AIT->>Provider: authorized review primitive を一つ要求
        Provider-->>AIT: bounded evidence を返す
    end
    AIT->>GitHub: Work Item と delivery object を記録
    AIT->>Codex: implementation と focused check を実行
    Codex->>GitHub: exact-head candidate を公開
    GitHub-->>AIT: validation と merge evidence を返す
    AIT-->>Human: delivery readback、outcome evidence、Next Bet を報告

coordinator が product/authority decision を行い、Codex/native tool が workspace の edit/test を 行います。connected provider は選択・承認された primitive だけを実行します。AI Teams は provider credential を移送せず、system of record を黙って置換しません。

Adaptive execution topology¶

AI Teams は task を理解してから topology を選びます。agent 数そのものは product goal ではありません。coordination の総コストと、期待する quality、経過時間、independence の 改善を比較します。handoff と context の重複を避けるため、specialist を置かない一人の accountable coordinator が既定です。機械的な事実には、model work を増やす前に deterministic tool を使います。

bounded な独立専門性、context isolation、parallel work、challenge が結果を実質的に 改善するときだけ specialization を選びます。Goal、authority、integration、acceptance の 判断は coordinator が保持し、各 specialist は bounded evidence を coordinator へ返します。 この制約は「agent が多いほど quality が高い」と「永遠に一人の agent だけ」という両方の 解釈を退けます。現在の task に十分な最小 topology を選び、計測した cost または outcome evidence が変われば topology も変えられます。

規範的な budget と delegation limit は execution-economics contractに残します。

Provider resolution¶

accepted capability inventory の operation は host/platform native、installed Plugin、connected Connector/MCP、standard CLI/service、bundled fallback の順に選択します。一つの operation で 各 provider class を最大1回観測します。unknown/unauthorized capability は bounded handoff です。

machine-readable inventory は生成 capability referenceの source です。詳細 semantics は provider-resolution contractに残ります。

社内integrationは、名前空間付きの外部manifestと対象scope専用の許可リストにより、coreを 編集せず追加できます。書き込み経路の選択には、manifestと実際の実装digestに紐づく 適合性結果のレビューも必要です。API実行、認証情報、timeout、receiptは外部integrationが 所有し、選択処理から外部コードを実行しません。型定義、承認、失敗時の扱い、取り消しは 外部providerガイドを参照してください。

任意の外部 Control¶

bounded Control MCP client は独立して配布される Qoo257/ai-teams-control に接続できます。 外部 Control は Issue discovery、scheduling、durable execution-coordination queue/recovery state、worker lifecycle、任意 provider-event integration を所有します。この Plugin は scheduler、 queue、poller、orchestration runtime を所有しません。rebuildable local cache と configured reflection artifact は、それぞれ宣言済みの local owner に残ります。GitHub delivery の正本は GitHub Issue/PR であり、外部 Control は repository acceptance や trust boundary を弱められません。