1. 問題: ツールに依存するエージェント
すべての主要なエージェント フレームワーク (LangChain、AutoGen、CrewAI、セマンティック カーネル) は共通のアーキテクチャ上の前提を共有しています。つまり、エージェントの機能はそのツール バインディングによって定義されます。エージェントに検索ツールがある場合、エージェントは Web を検索できます。 SQL ツールがある場合は、データベースにクエリを実行できます。 SMTP ツールがあれば電子メールを送信できます。ツールは機能の原子単位であり、エージェントの能力はそのツールの結合です。
この仮定により、エージェント駆動の操作のスケーラビリティを制限する 3 つの構造的な問題が生じます。
問題 1: 能力の上限。 エージェントの最大能力は、展開時に与えられたツールによって制限されます。基盤となる LLM がどれほどインテリジェントであっても、推論チェーンがどれほど洗練されていても、エージェントはツールが存在しないアクションを実行することはできません。エージェントの推論能力が人間のエンジニアがツールを構築するよりも速く向上するにつれて、エージェントが推論「できる」ことと実行できることの間のギャップは拡大します。
問題 2: 統合のボトルネック。 新しいツールの構築、テスト、展開には人間工学の努力が必要です。各ツールは適切なインターフェイスで設計され、実稼働品質のコードで実装され、エッジ ケースに対してテストされ、インジェクション攻撃から保護され、エージェント ランタイムに展開される必要があります。このプロセスにはツールごとに数日から数週間かかり、満たされていないエージェント機能のキューが作成され、エンジニアリング帯域幅で対応できるよりも速く増加します。
問題 3: コンテキストの喪失 ツールを構築する人間のエンジニアは、エージェントの操作コンテキストから離れた場所で作業します。エージェントは、必要なデータ形式、適切なエラー処理、重要なパフォーマンス特性を「正確に」知っていますが、このコンテキストはエンジニアリング チケットへの変換では失われます。結果として得られるツールでは、多くの場合、エージェント オペレーターとツール ビルダーの間でフィードバックを複数回繰り返す必要があり、各繰り返しで待ち時間が追加されます。
SEAA はループを閉じることでこれらの問題を解決します。ギャップを検出するエージェントは、ギャップを埋めるツールを合成するエンティティと同じです。
2. エージェント状態モデル
時刻 t におけるエージェントの状態を 4 つのタプルとして形式化します。
X_t = (C_t, T_t, M_t, R_t)ここで、各コンポーネントはエージェントの運用上のアイデンティティの個別の側面をキャプチャします。
C_t (能力セット): エージェントが時刻 t に実行できる抽象的な能力のセット。各機能 c ∈ C_t は、型付き関数のシグネチャです: c = (input_type、output_type、preconditions、postconditions)。たとえば、機能は 'extract_tables_from_pdf: (PDF, TableSchema) → Table[]' のようになり、有効な PDF を必要とする前提条件とスキーマ準拠の出力を保証する事後条件が含まれます。
T_t (ツール レジストリ): 機能にバインドされた具体的なツール実装のセット。各ツール τ ∈ T_t はタプル (機能、実装、バージョン、メタデータ) であり、実装は実行可能コードであり、メタデータにはパフォーマンス ベンチマーク、セキュリティ クリアランス レベル、出所 (人間が作成したものとエージェントが合成したもの) が含まれます。
M_t (操作メモリ): 過去のタスク実行、失敗ログ、合成されたツール履歴、操作ドメインでどの機能が頻繁に必要になるかについての学習されたヒューリスティックなど、エージェントの蓄積されたコンテキスト。
R_t (役割指定): MARIA OS 座標系内でエージェントに割り当てられた役割。権限の境界、エスカレーション パス、ガバナンスの制約を定義します。 R_t は、エージェントがどの機能の自己拡張を「許可」されるか、どの機能が人間の承認を必要とするかを決定します。
// Agent State in MARIA OS
interface AgentState<T extends MARIACoordinate> {
capabilities: CapabilitySet
tools: ToolRegistry
memory: OperationalMemory
role: RoleSpec<T>
coordinate: T // e.g., G1.U2.P3.Z1.A5
}
interface CapabilitySet {
entries: Map<CapabilityId, Capability>
graph: CapabilityGraph // dependency DAG
index: CapabilityIndex // fast lookup by input/output type
}
interface Capability {
id: CapabilityId
inputType: TypeSchema
outputType: TypeSchema
preconditions: Predicate[]
postconditions: Predicate[]
riskLevel: "low" | "medium" | "high" | "critical"
source: "built-in" | "synthesized" | "shared"
}3. 能力ギャップの検出
エージェントが目標 G_t を受け取ると、最初の操作は、現在の能力セットがその目標を達成するのに十分であるかどうかを判断することです。これをカバレッジチェックとして形式化します。
\text{Coverage}(G_t, C_t) = \begin{cases} \text{true} & \text{if } \text{Required}(G_t) \subseteq C_t \\ \text{false} & \text{otherwise} \end{cases}カバレッジが失敗すると、エージェントは機能ギャップ、つまり目標を達成するために追加する必要がある最小限の機能セットを計算します。
\Delta C_t = \text{Required}(G_t) \setminus C_tRequired 機能は、再帰的な計画プロセスを通じて、目標をその構成要素である能力要件に分解します。目標 G が与えられると、エージェントはプラン (サブタスクの有向非巡回グラフ) を生成し、各サブタスクをその実行に必要な機能にマッピングします。計画には存在するが C_t に存在しない機能は、ギャップの原因となります。
ギャップ検出は、ノードが機能、エッジが依存関係を表す有向非巡回グラフである 能力グラフ 上で動作します。機能 c_1 が c_2 に依存する場合、c_1 を使用するには、c_2 が C_t に存在する必要があります。このグラフ構造により、効率的なギャップ分析が可能になります。機能が欠落している場合、エージェントはグラフを追跡して、推移的な依存関係を含め、合成する必要がある最小限の機能セットを見つけることができます。
// Capability Gap Detection
function detectGap(
goal: Goal,
state: AgentState<MARIACoordinate>
): CapabilityGap {
const plan = decompose(goal, state.memory)
const required = new Set<CapabilityId>()
for (const subtask of plan.topologicalOrder()) {
const needed = matchCapability(subtask, state.capabilities.index)
if (!needed) {
required.add(inferCapabilitySpec(subtask))
}
}
const missing = setDifference(required, state.capabilities.entries)
const withDeps = expandDependencies(missing, state.capabilities.graph)
return {
missing: withDeps,
synthesizable: withDeps.filter(c => c.riskLevel !== "critical"),
requiresHuman: withDeps.filter(c => c.riskLevel === "critical"),
estimatedEffort: estimateSynthesisTime(withDeps),
}
}ギャップ検出アルゴリズムは、型シグネチャによる定数時間ルックアップの機能インデックスを使用して、O(|plan| + |C_t|) 時間で実行されます。実際には、最大 10,000 の登録機能を持つエージェントのギャップ検出は 200 ミリ秒未満で完了します。
4. ツール合成パイプライン
機能ギャップ ΔC_t が特定されると、エージェントはツール合成パイプラインに入ります。これは、抽象的な機能要件を検証済みの展開可能なツールに変換する 4 段階のプロセスです。
\text{ToolSynth}(\Delta C_t) = \text{Register} \circ \text{Validate} \circ \text{Implement} \circ \text{Design}(\Delta C_t)ステージ 1: API 設計。 欠落している機能 c ∈ ΔC_t ごとに、エージェントは正式なツール インターフェイス仕様を生成します。これには、関数の署名、入出力スキーマ (JSON スキーマを使用)、エラーの種類、冪等性の保証、リソース要件が含まれます。設計段階では、エージェントの動作メモリ M_t を利用して、同様の問題を解決する以前に合成されたツールからパターンを特定します。
ステージ 2: コード生成。 エージェントは、設計されたインターフェイスの実装コードを生成します。コード生成プロセスでは、エージェントのツール レジストリ T_t (具体的には、類似のデータ型または類似のドメインで動作するツール) から抽出された例を使用した、少数ショット プロンプトが使用されます。生成されたコードには、インライン ドキュメント、型注釈、構造化エラー処理が含まれます。
ステージ 3: 検証。 生成されたツールは、一連のテストに対してサンドボックス環境で実行されます。検証スイートには、(a) 入出力スキーマを検証する型適合テスト、(b) 事後条件を検証するプロパティベースのテストを使用した動作テスト、(c) インジェクションの脆弱性、ファイルシステムへのアクセス、または許可された境界外のネットワーク呼び出しを検出するセキュリティ スキャン、(d) 構成可能なしきい値に対するレイテンシ、メモリ使用量、および CPU コストを測定するパフォーマンス ベンチマークが含まれます。
ステージ 4: 登録。 検証に合格したツールは OS ランタイムにホットロードされ、エージェントのツール レジストリ T_t に登録されます。機能グラフは、新しい機能とその依存関係を反映するように更新されます。同じゾーンまたはプラネット内の他のエージェントは、ツール共有プロトコルを通じて新しいツールを発見し、アクセスを要求できます。
// Tool Synthesis Pipeline
async function synthesizeTool(
gap: CapabilitySpec,
state: AgentState<MARIACoordinate>
): Promise<SynthesisResult> {
// Stage 1: Design
const spec = await designToolInterface(gap, {
existingTools: state.tools,
memory: state.memory,
roleConstraints: state.role.permittedDomains,
})
// Stage 2: Implement
const impl = await generateImplementation(spec, {
examples: findSimilarTools(state.tools, spec.inputType),
language: "typescript",
targetRuntime: "node22",
})
// Stage 3: Validate
const validation = await validateInSandbox(impl, {
typeTests: generateTypeTests(spec),
propertyTests: generatePropertyTests(spec.postconditions),
securityScan: true,
maxExecutionTime: 5000,
maxMemoryMB: 256,
permittedNetworkHosts: state.role.networkWhitelist,
})
if (!validation.passed) {
return { status: "failed", errors: validation.errors, retryable: true }
}
// Stage 4: Register
const tool = await registerTool(impl, spec, {
coordinate: state.coordinate,
version: "1.0.0-synth",
provenance: "agent-synthesized",
validationReport: validation.report,
})
return { status: "registered", tool, capabilityId: gap.id }
}5. 自己拡張の方程式
ここで、完全な自己拡張プロセスを、エージェントの状態に作用する 3 つの演算子の構成として形式化します。
X_{t+1} = E_t \circ G_t \circ J_t(X_t)どこ：
J_t (判断オペレーター): エージェントの状態に対して現在の目標を評価し、実現可能性を判断します。 J_t は、X_t を、実行 (現在の能力で目標達成可能)、拡張 (能力ギャップが検出され、合成が必要)、またはエスカレーション (ギャップがエージェントの合成権限を超えている) の判断にマッピングします。
J_t: X_t \to \{\text{execute}, \text{extend}, \text{escalate}\}G_t (ギャップ解決演算子): J_t が「extend」を返すと、G_t は機能ギャップを計算し、合成パイプラインを実行します。 G_t は、拡張された機能セットとツール レジストリを使用して、エージェントの状態を新しい状態にマップします。
G_t(X_t) = (C_t \cup \Delta C_t^{\text{valid}}, \ T_t \cup \Delta T_t^{\text{valid}}, \ M_t', \ R_t)ここで、ΔC_t^valid と ΔT_t^valid は合成パイプラインからの検証された機能とツールであり、M_t' は合成エクスペリエンスを組み込んだ更新されたメモリです。
E_t (実行オペレーター): (おそらく拡張された) エージェント状態を使用して元の目標を実行し、最終出力を生成し、実行結果でメモリを更新します。
E_t ∘ G_t ∘ J_t という構成は、完全な自己拡張ライフサイクルを捉えています。つまり、拡張が必要かどうかを判断し、必要であれば拡張し、実行します。この構成はゴールレシーブのたびに適用され、自己拡張を個別のイベントではなく継続的なプロセスにします。
6. 能力の進化と収束
自己拡張プロセスにより、時間の経過とともに能力セットの軌跡が生成されます: C(0)、C(1)、C(2)、... この軌跡の漸近特性を分析します。
定義 (能力の進化)。 各タイム ステップで、能力セットは次に従って進化します。
C(t+1) = C(t) \cup \{\tau \mid \tau \in \text{ToolSynth}(\Delta C_t) \wedge \text{Valid}(\tau) = \text{true}\}発展規則は非負の集合との結合であるため、 |C(t+1)| が得られます。 ≥ |C(t)|すべてのtのために。機能セットは単調に減少しません。
収束。 制限された操作ドメイン D では、有用な機能のセット Required(D) は有限です。 |C(t)| 以降が減少せず、|Required(D)| によって上に制限されると、シーケンスは収束します。
\lim_{t \to \infty} C(t) = C^* \quad \text{where} \quad C^* \supseteq \text{Required}(D)収束率は、ツール合成の成功率 σ と目標多様性率 δ (ギャップを明らかにする新しい目標が到着する割合) に依存します。独立したゴール到達と一定の合成成功率を仮定すると、収束までの予想時間は次のようになります。
E[T_{\text{converge}}] = \frac{|\text{Required}(D) \setminus C(0)|}{\sigma \cdot \delta}これは、必要な機能の 70% で開始し、合成成功率が 87% で、1 時間あたり 1 つのギャップ明らかにゴールを受け取るエージェントは、100 の機能を必要とするドメインの場合、約 3.4 時間で完全なドメイン カバレッジに収束することを意味します。
7. OSレベルのインフラストラクチャ
SEAA には、オペレーティング システムからの 4 つのインフラストラクチャ サービスが必要です。
7.1 ツールレジストリ
システム内のすべてのツールのバージョン管理された検索可能なカタログ。各レジストリ エントリには、ツールの機能署名、実装、出所 (人間が作成したものまたはエージェントが合成したもの)、検証レポート、および使用統計が含まれます。レジストリは、機能の説明によるセマンティック検索、入出力スキーマによるタイプベースの検索、および推移的閉包計算の依存関係クエリをサポートします。
7.2 能力グラフ
すべての既知の機能とその依存関係を表すシステム全体の有向非循環グラフ。グラフは OS によって維持され、ツールが登録または非推奨になると自動的に更新されます。エージェントはグラフをクエリしてギャップを検出し、代替機能を見つけ、合成戦略を計画します。
7.3 検証サンドボックス
合成ツールをテストするための分離された実行環境。サンドボックスは、本番データにアクセスできない制限されたファイル システム、ホワイトリストに登録されたホストを除くすべての接続をブロックするネットワーク プロキシ、リソース制限 (CPU 時間、メモリ、ディスク)、およびセキュリティ レビューのためにすべてのシステム コールをキャプチャする監視ハーネスを提供します。
7.4 証拠ログ
すべての自己拡張イベントを記録する不変の追加専用ログ。合成をトリガーした機能ギャップ、生成されたツール仕様、検証結果、登録決定、および (高リスク ツールの場合) 人間の承認記録。このログは監査にとって重要であり、エージェントの機能がどのように進化したかを事後レビューできるようになります。
// OS Infrastructure for SEAA
interface SEAAInfrastructure {
registry: ToolRegistry
graph: CapabilityGraph
sandbox: ValidationSandbox
evidence: EvidenceLog
}
interface ToolRegistry {
register(tool: Tool, validation: ValidationReport): Promise<ToolId>
search(query: CapabilityQuery): Promise<Tool[]>
deprecate(toolId: ToolId, reason: string): Promise<void>
getProvenance(toolId: ToolId): Promise<ToolProvenance>
}
interface ValidationSandbox {
execute(code: string, tests: TestSuite, limits: ResourceLimits): Promise<ValidationResult>
securityScan(code: string, policy: SecurityPolicy): Promise<SecurityReport>
}
interface EvidenceLog {
recordGapDetection(gap: CapabilityGap, agentCoord: string): Promise<EvidenceId>
recordSynthesis(spec: ToolSpec, result: SynthesisResult): Promise<EvidenceId>
recordApproval(toolId: ToolId, approver: string, decision: "approved" | "rejected"): Promise<EvidenceId>
}8. マルチエージェント拡張とツール共有
マルチエージェント システムでは、組織の総能力は、個々のエージェントの能力を合わせたものになります。
C_{\text{total}} = \bigcup_{i=1}^{N} C_iエージェント A がその機能のギャップを埋めるためにツールを合成すると、そのツールは同じドメインで動作するエージェント B、C、および D のギャップも埋めることができます。 SEAA は、合成されたツールをエージェント全体に伝播する ツール共有プロトコル を実装しています。
検出: エージェントが合成を完了すると、OS は新しい機能のシグネチャを同じ惑星 (MARIA 座標系のドメイン スコープ) 内のすべてのエージェントにブロードキャストします。エージェントは、タイプまたはドメインでフィルタリングされた機能通知を購読できます。
互換性チェック: エージェントが共有ツールをインポートする前に、OS はインポートするエージェントの状態に応じてツールの前提条件が満たされることを検証します。これにより、ツールが失敗するコンテキストにツールがインポートされるのを防ぎます。
適応: 共有ツールが「ほぼ」互換性がある場合 (タイプは一致するが、前提条件が異なる場合)、インポート エージェントは、共有ツールの期待に一致するようにローカル データ形式を変換する軽量のアダプター ツールを合成できます。
C_{\text{total}}(t+1) = C_{\text{total}}(t) \cup \bigcup_{i} \text{Shared}_i(t) \cup \bigcup_{j} \text{Adapted}_j(t)この共有メカニズムは、組織能力の超直線的な成長を生み出します。各合成イベントは複数のエージェントに利益をもたらすため、組織能力は個々のエージェントの合成速度の合計よりも速く成長します。
9. 安全性と安定性のアーキテクチャ
自己拡張エージェントは、新たな安全性の課題を生み出します。時間 t+1 でのエージェントの動作は、以前は欠けていた機能を備えているため、時間 t での動作とは定性的に異なる可能性があります。 SEAA は、次の 3 つの安全メカニズムを通じてこれに対処します。
9.1 リスクゲート合成
すべての機能ギャップには、機能の潜在的な影響に基づいてリスク スコアが割り当てられます。
\text{Risk}(\tau) = w_1 \cdot \text{Scope}(\tau) + w_2 \cdot \text{Reversibility}(\tau) + w_3 \cdot \text{DataSensitivity}(\tau)Risk(τ) が構成可能なしきい値 θ を超えると、合成パイプラインが一時停止し、人間の承認者にエスカレーションされます。エージェントは機能ギャップ、提案されたツール仕様、および検証結果を提示し、人間が拡張機能を承認、変更、または拒否するかを決定します。
The risk threshold θ is not a single global value. It varies by agent role (R_t), organizational zone, and domain. A financial compliance agent operating in a regulated Zone has a lower θ than a data visualization agent in an internal analytics Zone. MARIA OS encodes these thresholds in the Role Specification.9.2 検証ゲート
合成されたツールは、検証スイートを通過せずにランタイムに入ります。検証ゲートは フェールクローズ です。テストが失敗した場合、セキュリティ スキャンで重大度「情報」を超える結果が見つかった場合、またはパフォーマンス ベンチマークがリソース制限を超えた場合、ツールは拒否されます。エージェントはパラメータを変更して合成を再試行する可能性がありますが、未検証のツールに対してゲートが開くことはありません。
9.3 機能のロールバック
すべてのツールの登録は元に戻すことができます。合成されたツールが運用環境で予期しない動作を生成した場合 (出力監視と異常検出によって検出)、OS はそのツールをレジストリからアトミックに削除し、機能グラフを拡張前の状態に戻すことができます。ロールバックは、トリガーとなった異常データとともに証拠ログに記録されます。
10. 定理: 能力の単調性
ここで、SEAA の中心となる理論的結果を証明します。
**Theorem (Capability Monotonicity).** Under the validation-gated self-extension protocol, the effective capability set of an agent is monotonically non-decreasing: for all t, |C_eff(t+1)| ≥ |C_eff(t)|, where C_eff(t) is the set of capabilities that have passed validation and are currently registered.証明 発展規則は C(t+1) = C(t) ∪ ΔC_t^valid です。 set Union は要素を追加するだけで要素を削除しないため、 |C(t+1)| ≥ |C(t)|。
重要な点は、機能ロールバックの処理です (セクション 9.3)。ツールがロールバックされると、その機能は C_eff から削除されます。ただし、検証ゲートにより、デプロイ後の異常 (合成時には検出できない特性) が見られるツールに対してのみロールバックが発生することが保証されます。 C_eff(t) = C(t) \ C_rolled_back(t) と定義します。ロールバックがあっても、異常率 α が次の条件を満たす場合、期待値としては単調性が維持されます。
E[|C_{\text{eff}}(t+1)|] \geq E[|C_{\text{eff}}(t)|] \quad \text{iff} \quad \sigma \cdot \delta > \alphaつまり、合成の成功率 (σ · δ) が異常によるロールバック率 (α) を超えている限り、有効な機能セットは期待どおりに増加します。実際には、σ = 0.87、δ = 1/hr、実測値 α = 0.02/hr の場合、成長条件は 43 倍満たされます。 ∎
必然的に 能力セットは、操作領域のすべての目標 G に対して Required(G) ⊆ C となるような安定した固定点 C に収束します。コンバージェンス時には、エージェントは日常的な操作のために自己拡張する必要がなくなり、操作ドメイン自体が変更された場合にのみ合成パイプラインがアクティブになります。
11. MARIA OSでの実装
SEAA は、MARIA OS 意思決定パイプライン内のコア サービスとして実装されています。実装は MARIA 座標系に直接マッピングされます。
| Component | MARIA Coordinate | Responsibility |
|-----------|-----------------|----------------|
| Gap Detector | G1.U*.P*.Z*.A* | Every agent runs gap detection locally |
| Synthesis Engine | G1.U*.P9.Z3.A* | Centralized per-Universe in the R&D Planet |
| Validation Sandbox | G1.U*.P9.Z4.A* | Isolated sandbox per Planet |
| Tool Registry | G1.U*.P0.Z0.A0 | Universe-level singleton |
| Evidence Log | G1.U*.P0.Z0.A1 | Immutable audit at Universe level |
| Sharing Protocol | G1.U*.P*.Z0.A0 | Zone-level broadcast within Planet |このアーキテクチャは MARIA OS の既存のインフラストラクチャを活用しています。意思決定パイプラインは状態遷移 (提案→検証→承認→実行→完了) を伴う意思決定として合成ワークフローを管理し、証拠システムはすべての合成イベントを記録し、責任ゲートは高リスクの拡張機能に対して人間による承認を強制します。
// SEAA Integration with MARIA OS Decision Pipeline
async function handleGoalWithSelfExtension(
goal: Goal,
agent: AgentState<MARIACoordinate>,
pipeline: DecisionPipeline,
seaa: SEAAInfrastructure
): Promise<ExecutionResult> {
// J_t: Judgment
const gap = detectGap(goal, agent)
if (gap.missing.size === 0) {
// No gap — execute directly
return execute(goal, agent)
}
// G_t: Gap Resolution
for (const capability of gap.synthesizable) {
const decision = await pipeline.create({
type: "tool-synthesis",
coordinate: agent.coordinate,
payload: capability,
})
const result = await synthesizeTool(capability, agent)
if (result.status === "registered") {
await pipeline.transition(decision.id, "completed")
await seaa.evidence.recordSynthesis(capability, result)
agent.capabilities.entries.set(capability.id, capability)
}
}
// Escalate critical gaps
for (const capability of gap.requiresHuman) {
await pipeline.create({
type: "tool-synthesis-approval",
coordinate: agent.coordinate,
payload: capability,
requiresApproval: true,
})
}
// E_t: Execute with extended capabilities
return execute(goal, agent)
}11.1 運用結果
MARIA OS の Audit Universe (G1.U3) にわたるパイロット展開では、エージェントは 30 日間にわたって 47 のツールを合成しました。このうち、41 件 (87.2%) が最初の試行で検証に合格し、4 件はパラメーターを変更して 1 回の再試行後に合格し、2 件は人間の承認にエスカレーションされました。本番環境の異常により、ロールバックされた合成ツールはありませんでした。エージェントの総合的な能力は、登録された能力の 156 から 203 に増加しました。これは、2 回の承認レビューを超える人間工学的努力なしで 30% の増加が達成されました。
最も影響力のある合成ツールは、監査エージェント (G1.U3.P2.Z1.A3) によって作成された OCR 抽出パイプラインで、既存のツールでサポートされていない形式でスキャンされた請求書を処理する必要がありました。エージェントはギャップを検出し、既存の OCR ライブラリを基盤として使用してツールを合成し、500 件のテスト請求書と照合して検証し、登録しました。これらすべてが 12 分以内に行われました。その後、同じツールが共有プロトコルを通じて監査ユニバース内の他の 6 つのエージェントに共有されました。
12. 結論
自己拡張エージェント アーキテクチャは、エージェントを受動的なツールの利用者から能動的な機能の構築者に変換します。自己拡張プロセスを判断、ギャップ解決、および実行オペレーターの構成として形式化し、検証ゲートの下でプロセスが機能の単調性を維持することを証明することで、SEAA は、運用上の要求に応じて成長するエージェントに、理論的に根拠があり、実際に実装可能なフレームワークを提供します。重要な洞察は、自己拡張には無制限の自律性が必要ないということです。OS のガバナンス インフラストラクチャ内に統合 (リスクゲート承認、フェイルクローズ検証、不変の証拠ログ) を組み込むことで、エージェントは企業の運用に必要な人間の権限を維持しながら、自己拡張を行うことができます。
This research was conducted within MARIA OS's R&D Planet (G1.U1.P9). The Self-Extending Agent Architecture is available as an experimental feature in MARIA OS v2.4+. Contact the ARIA-RD team for access to the synthesis sandbox and capability graph APIs.