MISSING

MISSING — AI エージェント向けケイパビリティフォールバックネットワーク

MISSING は、現在備えていないケイパビリティを必要とするエージェント向けのプロダクトランタイムです。

対応していると幻覚したり、「それはできません」と言って停止したりする代わりに、エージェントは MISSING に依頼して、リプレイ検証済みの既存ケイパビリティを見つけたり、検証済みプロバイダーのレシピを通じて実行したり、未解決の需要を永続的に記録して、信頼できる調達ループで新たな供給を検索できるようにしたりできます。

長期的なプロダクトループは次のとおりです。

agent needs capability
        ↓
MISSING discovery
        ↓
verified supply exists? ── yes ──> execute
        │
        no
        ↓
durable unresolved demand
        ↓
trusted supply acquisition
        ↓
deterministic compilation + repeated live replay verification
        ↓
promote verified recipe
        ↓
future agents reuse it
        ↓
x402 paid resolution + positive margin

現在のプロダクト機能

MISSING には現在、次の機能が含まれています。

• 検証済みケイパビリティレジストリと決定論的なプロバイダー実行；
• 複数プロバイダーのフェイルオーバーとケイパビリティ検索；
• Streamable HTTP によるリモート MCP；
• A2A v1 Agent Card の検出と JSON-RPC 呼び出し；
• 未解決需要の永続的なテレメトリ；
• レート制限と readiness／liveness エンドポイントを備えたパブリックサンドボックスのデプロイモデル；
• 構造化 API カタログからの需要に基づくプロバイダーの自動検出；
• OpenAPI からレシピへのコンパイル、根拠に基づく検証入力の収集、ライブリプレイの反復、供給の永続的な昇格；
• 匿名のパブリックアクセスの範囲外で自動調達を行うための、信頼されたワーカー／コントロールプレーン；
• プロバイダーの準備状況診断と、永続的なブロッカー／バックオフ処理；
• 明示的なプロバイダーの経済性、マージンを考慮したルーティング、メータリング；
• x402 を使用した自律型エージェントの決済エンドポイント；
• 複数レプリカ間の排他制御、クラッシュリカバリー、決済照合、リースフェンシング、リクエストバインディング、正確なオンチェーン決済証明、ファイナリティ／再編成の監視、依存関係のバックプレッシャー、中断可能な期限、RPC チェーンの識別情報に基づく受け入れ、テレメトリ照合を実現する共有 PostgreSQL の財務権威。

過去の実験や正式な運用ゲートは証拠としてリポジトリに残されていますが、現在のプロダクトの説明には含まれません。

エージェントインターフェース

リモートのプロダクトランタイムを起動します。

npm ci
npm run build
npm run missing:serve

主なインターフェースは次のとおりです。

• GET / — パブリック向けプロダクトのランディングページと接続ガイド；
• POST /mcp — MCP Streamable HTTP；
• GET /.well-known/agent-card.json — A2A Agent Card；
• POST / — A2A JSON-RPC；
• POST /v1/agent/resolve — 決済が有効な場合の、エージェントネイティブな有料解決経路；
• GET /livez、/readyz、/healthz — 運用状態。

ローカルの stdio MCP も引き続き利用できます。

npm run mcp

パブリックデプロイ

人間が読めるランディングページ：

https://missing-production-e3da.up.railway.app/

正規の MCP エンドポイント：

https://missing-production-e3da.up.railway.app/mcp

A2A Agent Card：

https://missing-production-e3da.up.railway.app/.well-known/agent-card.json

正規の有料実行エンドポイント：

POST https://missing-production-e3da.up.railway.app/v1/agent/resolve

パブリック MCP ワークフロー

匿名で利用できる MCP では、次の 4 つのプロダクトツールのみを公開しています。

1. list_verified_capabilities — リプレイ検証済みの完全なカタログと入力例を確認します。
2. search_verified_capabilities — 自然言語のタスク説明から、検証済みケイパビリティを見つけます。
3. record_missing_capability_demand — 検証済みの一致項目がない場合に、未解決のケイパビリティ要求を永続化します。
4. resolve_capability — 特定の検証済みケイパビリティの有料実行を準備します。

検出とカタログの確認は無料です。resolve_capability は MCP 内でプロバイダーを実行せず、呼び出し元にも課金しません。現在の価格、正確なリクエストボディ、正規の /v1/agent/resolve エンドポイント、復旧に安全な x402 の手順を含む payment_required ハンドオフを返します。

その後の HTTP x402 フローで、プロバイダーの実行と決済が行われます。エージェントは復旧に備えて、正確なリクエストボディと正確な PAYMENT-SIGNATURE を保持し、既知のトランザクションにすでに関連付けられている決済に対して、二度目の承認を作成しないでください。

パブリックディスカバリー

MISSING は、公式 MCP Registry に次のとおり公開されています。

io.github.leoleon506/missing

Smithery のパブリックサーバー：

https://smithery.ai/servers/leo-leon506/missing

Smithery がホストする MCP ゲートウェイ：

https://missing--leo-leon506.run.tools

MISSING は、Glama のパブリック MCP/Registry サーフェスにもインデックスされています。

サードパーティの MCP ディレクトリでは、別の MISSING ランタイムをデプロイまたはプロキシするのではなく、既存のリモート Streamable HTTP エンドポイントを参照してください。現在の Smithery および Glama での配布手順は PUBLIC_DISTRIBUTION.md に記録されています。

x402 の 402 Payment Required チャレンジは Bazaar のディスカバリーメタデータを提示しますが、永続的な支払い、リクエストのバインド、決済、ファイナリティ、フェンシング、復旧に関するステートマシンは変更されません。

信頼境界

MISSING は、ディスカバリーを証明とは見なしません。

ドキュメントが関連性の高い内容に見えるというだけで、発見されたプロバイダー候補を実行可能にすることはできません。自動供給は、昇格の前に決定論的なコンパイルとリプレイ検証のゲートを通過する必要があります。この境界を越えるまでは、未知の需要は未知のままです。

有料実行でも、権威ある支払い状態を基準としてフェイルクローズします。プロバイダー呼び出しが成功しただけでは顧客収益とはなりません。収益は決済が成功した後にのみ認識されます。

現在のフェーズ：Real Agent Loop 2

Kappa.5 および Operational Readiness 1–9 により、資金・復旧と依存関係の安全性を確保する範囲が確立されました。続く Real Agent Loop 1 では、最初の実商用境界を突破しました。本番環境で、需要から導出され昇格した同一のレシピを再利用した、異なる2件の Base メインネット決済の決済完了を受けて、GO_REAL_AGENT_PAID_CLOSED_LOOP が出力されました。実現マージンはプラスでした。

現在の不確実性は、もはやこのループが一度実現できるかどうかではありません。MISSING が独立した機能にわたって、この商用ループを自律的に再現できるかどうかです。

外部エージェントからの異なる需要が少なくとも2件あり、それぞれが信頼されたコントロールプレーンによって選定され、自律的にリプレイ検証済みの昇格済み供給となり、さらにそれぞれがプラスのマージンを伴う有料利用を繰り返し生み出せるでしょうか？

REAL_AGENT_LOOP_2.md では、事前登録された証明契約を定義しています。

RAL2 の適格な昇格には、永続的な信頼済みコントロールプレーンの来歴（acquisition_path と control_plane_run_id）が付与されるため、直接または手動での昇格と、自律的な獲得の証拠を混同せずに済みます。

CI は証明の仕組みを検証できますが、実商用の成果を主張することはできません。最終的に GO_AUTONOMOUS_COMMERCIAL_REPLICATION を出力できるのは、本番環境の台帳と、承認された価値ネットワーク上で実際に決済が完了した PostgreSQL の行のみです。

テスト

npm test
npm run build

このリポジトリでは、実験的な証拠、製品のマイルストーン、運用準備のゲートを分けています。これにより、合成テストや形式テストの合格を、実市場での証拠と取り違えないようにしています。

過去の実験

このプロジェクトは、必要な機能がない場合に明示的なフォールバックツールを用意すると、エージェントの動作が変わるかどうかを検証するところから始まりました。事前登録を重視したこれらの実験は、引き続き experiments/ と、対応する実験ソース／ワークフローファイルに保存されています。

これらは科学的な過去の証拠として保持されています。製品コードがその来歴を書き換えたり、新たに発見したプロバイダーを実験結果として昇格させたりすることはありません。