エージェントプリミティブとは、AI エージェントに特定の能力やルールを 1 つ提供する、シンプルで再利用可能なファイルまたはモジュールである。この用語は エージェントプリミティブとコンテキストエンジニアリングで信頼性の高い AI ワークフローを構築する方法 で、3 層フレームワークの中間層として提案されている。その下には Markdown によるプロンプトエンジニアリング、上にはコンテキストエンジニアリングがあり、このフレームワークの目的は場当たり的なプロンプティングを再現可能な実践へと変えることだとされている。プリミティブはごく普通の Markdown ファイルであり、それに付随する主張は、タスクごとに完璧なプロンプトを手で書くことは持続不可能であるから、プロンプトを機能させる技法をファイルとしてコミットしておくべきだ、というものである。
情報源が挙げるのは 6 種類のファイルで、それぞれ固有の接尾辞と適用範囲を持つ。対象範囲を絞ったモジュール式のガイダンスのための .instructions.md、モードが使用できる MCP ツールによって範囲が定まるロールベースの専門性のための .chatmode.md、検証が組み込まれた再利用可能なワークフローのための .prompt.md、すぐに実装に移れる設計図のための .spec.md、セッションをまたいで保持される知識のための .memory.md、そして情報の取得を速めるヘルパーのための .context.md である。情報源によれば、VS Code がネイティブにサポートしているのは最初の 3 つであり、残りの 3 つは同フレームワークが追加するパターンとして提示されている。
用法
プリミティブは 1 つずつ使うのではなく、組み合わせて使うことを想定している。情報源の実例では、安全なユーザー認証を実装するというリクエストが一連のプリミティブ全体を通して処理される。まず backend-dev チャットモードが選択され、それが applyTo: "auth/**" パターンによって security.instructions.md を自動的に発動させる。次に .memory.md のセクションと .context.md ファイルからコンテキストを読み込み、構造化されたテンプレートから user-auth.spec.md を生成し、検証ゲートを備えた implement-from-spec.prompt.md ワークフローを実行する。このように複数のプリミティブを調整する .prompt.md ファイルを、情報源はエージェント型ワークフローと呼んでおり、これらは IDE、ターミナル、CI パイプラインのいずれでも同様に実行できるよう設計されていると述べている。
この構成で重みの大半を担っているのは 2 つの設計上の慣例である。1 つ目として、指示は 1 つの大きなファイルに集約するのではなくモジュール化して保たれ、applyTo フロントマターのパターンによって、ファイルは一致するパスに対してのみ有効になる。情報源はこれを コンテキストエンジニアリング の施策として位置づけ、作業そのもののためにコンテキストの空間を確保するものだとしている。2 つ目として、チャットモードには、その領域に必要な MCP ツールだけが与えられる。情報源はこれを集中のための施策であると同時にセキュリティ境界でもあるとし、専門職の資格制度になぞらえている。建築家は計画を立てるが、建てはしない、というわけである。名前が挙げられているモードはアーキテクト、フロントエンドエンジニア、バックエンドエンジニア、テクニカルライターであり、それぞれに何ができて何ができないかが明示されている。
情報源は、指示、チャットモード、再利用可能なプロンプト、仕様テンプレートという決まった順序でこれらを構築することを推奨しており、期待される見返りを蓄積として説明している。すなわち、失敗は .memory.md に記録され、うまくいくパターンは .instructions.md に文書化され、ワークフローは .prompt.md で洗練されていく。情報源はこれを複利的な知性（compound intelligence）と呼んでいる。
適用される場面
この実践が当てはまるのは、同じ種類の AI 支援タスクが十分に頻繁に繰り返され、毎回プロンプトを導き直すのが無駄になる場合であり、また複数の人がエージェントから同じ振る舞いを必要とする場合である。前提として、そもそもリポジトリから指示ファイルを読み込むエージェントが必要となる。情報源の例は VS Code の GitHub Copilot 向けに書かれており、ファイルは .github/instructions/、.github/chatmodes/、.github/prompts/ 配下に置かれる。さらに、フレームワークのうちスケーリングに関する半分については、エディタの外でプロンプトファイルを実行できるエージェント CLI ランタイムが前提となる。
どのように失敗するかは間接的に、つまり第 3 層が解決するために存在する問題として述べられている。優れたプリミティブであっても、無関係なコンテキストがモデルの限られた注意を奪い合うと失敗する。だからこそ情報源は、ファイルだけで十分だとはせず、セッションの分割、範囲を絞った指示、モードの境界とこれらを組み合わせている。指示ファイルがあらゆる場所に適用されるのを防いでいるのは applyTo の仕組みであり、情報源が直接名指ししている誤用は、情報源が警告している 1 つの巨大な指示ファイルである。
この実践がどの程度確立されているかについて言えば、これは 2025 年 10 月に GitHub のブログで公開された一人の著者による提案であり、情報源はその評価を何も報告していない。6 種類のファイルのうち 3 種類は、VS Code がネイティブに認識するフォーマットではなく、著者のフレームワークが導入する慣例である。また、情報源がそれらを配布するために提案しているツール、APM（Agent Package Manager） は同じ著者のプロジェクトである。同様のニーズに取り組む他のファイルベースの慣例については、AGENTS.md と Agent Skills を参照のこと。
関連用語
- コンテキストエンジニアリング — 上位の層であり、情報源がこれらと組み合わせているもの
- プロンプトエンジニアリング — 下位の層であり、これらが体系化するとされるもの
- Agent Skills — エージェントの能力をパッケージ化するための、もう 1 つのファイルベースの慣例
- AGENTS.md — 常設の指示のためのファイルベースの慣例
- アウターループ — この情報源の実行環境としての意味で、これらのファイルがエディタの外で実行される場。そのページには、同じ用語のもう 1 つの無関係な意味も記録されている