中心的な考えは役割の専門化です。フロントエンド開発者はインターフェースの実装とパフォーマンスに集中し、バックエンドアーキテクトはAPIとシステム設計に注力し、セキュリティエンジニアはリスクを検討し、リアリティチェッカーは弱いアイデアが本番に達する前に前提を検証します。他の部門も同様のパターンをマーケティング、プロジェクト管理、ファイナンス、カスタマーサポート、戦略的計画に拡張しています。

これらの役割は新たな基礎モデルの知能を生み出すわけではありません。ホストモデルがタスクに取り組む方法を、責任範囲を狭め、品質期待を明確にすることで形作ります。これによりより焦点を絞った応答が得られますが、結果は選択されたモデル、利用可能なプロジェクトコンテキスト、ツールの権限、エージェント定義の品質に依存します。

Agency Agentsは多数のコーディング環境向けの変換およびインストールスクリプトを含みます。対象に応じて、エージェントはMarkdown定義、Cursorルール、Aider規約ファイル、Geminiスキル、Codexカスタムエージェント設定になることがあります。ユーザーは完全なコレクション、個別の部門、または選択した専門家のみをインストールできます。

この移植性はプロジェクトの最も強力な実用的利点の一つです。チームはカスタマイズした役割をバージョン管理し、開発者が異なるアシスタントを使っても広く一貫した期待を維持できます。プラットフォームの機能は依然として異なるため、同じ定義がすべての場所で同一の動作、コンテキストアクセス、ツール実行を生むとは限りません。

数百の専門家をインストールしても自動的に生産的なワークフローができるわけではありません。より良い方法は、小規模なプロジェクトチームを選び、明確な段階を割り当てることです。製品タスクはプロダクトマネージャーからUXリサーチャーへ、次にフロントエンドとバックエンドの専門家へ、続いてセキュリティ、テスト、リアリティチェッカーのレビューへと移動します。

各引き継ぎには元の目的、関連ファイル、既に決定された事項、未解決の質問、受け入れ基準を含めるべきです。構造化された引き継ぎは専門家が異なる問題のバージョンを解決するのを防ぎます。アーキテクチャ、セキュリティ、範囲、リリースのチェックポイントでは人間の承認が依然として重要です。

詳細な役割はモデルを集中させますが、専門知識、事実の正確性、生産準備が整った作業を保証するものではありません。専門家は同じ誤った前提を継承したり、努力を重複させたり、矛盾する推奨を出すことがあります。エージェントの名簿が大きくなるとコンテキスト消費が増え、最終結果に影響を与えた指示を理解しにくくなります。

したがって、Agency Agentsはプロフェッショナルな責任の代替ではなく、ワークフローデザインのリソースとして採用すべきです。チームはコードベースやビジネスルールに合わせて役割をカスタマイズし、ツールの権限を制限し、外部コンテンツをレビューし、生成された変更をテストし、各専門家が単純な汎用アシスタントと比較して成果を改善しているかを測定すべきです。