起動の契機と仕事、担当する主体、道具や技能・ワークフローを分ける設計論を公開しました。記憶の蓄積とセッションの状態も区別しています。 定期実行を新しいエージェントとして増やす前に責任の置き場所を決めます。判断の余地と固定手順を業務に合わせて選ぶことが焦点です。 似た機能を別名で作り直す問題へ対応 AWSは11月6日、Amazon Quickの開発で整理したエージェントの構成要素を公開しました。仕事を、いつ始めるか、何をするか、誰が担うか、どう行うかの四つの問いへ分けます。回答から実行へ機能が広がる中で、同じ概念が異なる名称で作り直される問題があったと説明しています。定期的な要約を頼んだとき、それが新しいエージェントなのか、既存の主体への予約なのかを明確にする狙いです。新たな製品機能の一斉提供ではなく、開発者が共通の言葉で設計するための解説です。利用画面の複雑さを抑えることも背景にあります。 起動と主体と能力を切り分ける 仕事を始める契機には、人の依頼、他のエージェントからの委任、時刻、外部イベントがあります。それらが仕事の内容も運び、継続した主体であるエージェントが引き受けます。主体は指示、使える能力、学んだ文脈を持つと定義しています。基礎のモデルは交換可能な要素で、会話履歴はセッションごとの状態と区別します。能力では、道具は型を持つ小さな操作、スキルは判断の余地を残す手引き、ワークフローは順序や分岐を固定した調整です。対象は業務エージェントの開発者と、実行の責任を設計する担当者と見られます。毎朝の通知を作るために主体を増やすのか、既存の主体へ起動条件を追加するのかで、記憶と設定の管理が変わるという整理です。 判断を任せる場所と固定する場所を選ぶ 原文は、モデルが進歩しても、技能には組織の知識を共有する価値があり、ワークフローには監査や順序を確定する価値が残ると述べています。実務では、毎回同じ順番が必要な承認と、状況に応じた調査を分けることが論点です。手順が安定した技能を固定化したり、例外が多い処理を判断中心へ戻したりする可能性も示しています。導入時は名称をそろえるだけでなく、失敗時にどの主体が状態を持ち、再実行を誰が決めるかを確認することが考えられます。学習する文脈と一回限りの履歴を混ぜると、意図しない再利用につながる可能性があります。今回の記事は連載の最初で、背景学習などの詳細は今後の説明としています。未公開の仕組みを既存の確定仕様として扱わないことが焦点です。 実行を増やす前に責任の所在を決める 同じ主体を定期的に動かす設計では、過去に覚えた文脈が次回へどう伝わるかが重要になると見られます。次の判断点は、予定を止めた場合に何が止まり、主体の記憶がどこに残るかです。道具の追加と、固定した手順の変更も分けて管理することが考えられます。共通の用語は出発点ですが、担当者が実行履歴と設定を結び付けて説明できる必要があります。小さな定期業務で構成要素を確かめてから展開することが焦点です。状態の保管先も設計の確認対象です。