agently

Agently

リクエストが Agently API ではなく製品の振る舞いとして表現されている場合は、ここから始めてください。ファイルやメカニズムを選ぶ前に、最小のネイティブなオーナーを選びます。リクエストに Agently への言及は必要ありません。

Agently の開発者がモデルノードの役割を理解したり、実行効果を調整したり、データフローや冗長なコンテキストを確認したり、モデル/Host のオーナーシップを判断したりする必要がある場合は、「Prompt review」というフレーズを待たずに協調レビューを使用してください。ハイライトされたフローとハンドオフについては agently-design を経由し、可読性と依存関係でグループ化された関連 Prompt テーブルについては agently-request を経由してください。無関係な機械的な作業は、このレビュー手法の外に置いてください。

複数ラウンドの設計、Prompt の改訂、または実験の評価では、各実質的なラウンドを左にステータス、右に項目を配置したテーブルと、タイムスタンプ付きでバージョン管理された変更ログテーブルから始めてください。協調記録のガイダンスに従ってください。

ワークフロー

1. リクエストをゴール、入力、出力、副作用、エビデンス、ライフサイクル要件に還元します。
2. モデルが所有する意味的な決定と、ホストが所有する検証、認可、ID 結合、算術、副作用を分離します。
3. 各決定、状態、副作用を、既存の 1 つのオーナーに割り当てます。
4. 自明でないフローでは、ノード、値/イベントのエッジ、不変条件、および要求される各フィールドとステージの生成上の必要性をマッピングします。
5. 呼び出し側が非同期境界を所有する場合は async ファーストで実装し、決定論的なコントラクトはモデルが所有する品質とは別に検証します。
6. 必要な不変条件を担えるネイティブなオーナーが存在しない場合は、フレームワークのギャップを報告します。そのギャップをビジネス固有のグルーコードやパススルー facade の背後に隠さないでください。

オーナー別のルーティング

• 単一のリクエストファミリー（プロバイダー設定、prompt、構造化出力、LongContent、auto_continue、TTS/STT 音声、結果の再利用、セッションメモリ、embeddings、retrieval）は agently-request を使用します。
• AgentExecution プラグイン、final policies、Actions、Shell、MCP、ExecutionResource、TaskWorkspace、RecordStore、サービス公開、RuntimeEvent、DevTools は agently-runtime を使用します。
• プロセスローカルなタスクのライフタイム、sync/async のブリッジ、ループ中立なハンドル、決済、リプレイチャネル、ローカルリスナーは agently-stage を使用します。
• オーナーをまたぐアーキテクチャ、リクエスト/値/イベントのトポロジー、エビデンスと ID の境界、ライフサイクル、プレッシャー、情報損失の監査は agently-design を使用します。
• 開発者が所有する進行、分岐、並行性、承認、待機/再開、リトライ、再起動に安全なオーケストレーションは agently-triggerflow を使用します。
• LangChain、LangGraph、LlamaIndex、CrewAI など類似システムからの移行は agently-migration を使用します。
• モデルが生成した、またはアプリケーションが送信した明示的な非巡回 DAG データは、低頻度の上級ケースです。これはここに置いて references/task-dag.md を読んでください。通常の Agent やワークフローの作業に TaskDAG を導入しないでください。

必要に応じた読み込み

• 条件付きのプロジェクト構成とフルスタックのリファレンス資産: references/project-framework.md。
• TaskContext、ContextReader、TaskWorkspace、RecordStore、SkillLibrary、および SkillsExecutor 互換 facade: references/context-and-skills.md。
• 送信された TaskDAG データと DynamicTask コンビニエンス facade: references/task-dag.md。
• シミュレーションファーストと実モデルの検証: references/model-quality-validation.md。
• クロスレイヤーのトポロジー監査手法は agently-design にあり、特にその ../agently-design/references/execution-topology-validation.md にあります。

コア所有権ルール

• ModelRequest は 1 回のモデルインタラクションとそのプロンプト/出力契約を所有します。
• AgentExecution は 1 回の Agent 実行と、その選択されたプロデューサー、コントロール、 結果およびストリームを所有します。4.1.4.8 では、request、plan、long_content、 long_task はプラグインです。ランタイム Skill の 実行契約をお読みください。
• agent.create_task(...) は long-task AgentExecution のドラフトを返します。その プロデューサーはプランニング、エビデンス、再プランを所有し、リリース済みの AgentTask インポート は引き続き互換性があります。
• AudioModelRequest は独立した TTS/STT ドライバーを所有します。Agent の音声呼び出しと 音声依存の Execution プラグインには、明示的な音声バインディングが必要です。
• ActionRuntime はモデルから呼び出し可能な操作を所有し、ExecutionResource はライブ 依存関係のライフタイムを所有します。
• TriggerFlow はアプリケーションから可視のオーケストレーションとランタイムシグナルを所有します。
• TaskContext はタスク情報を所有し、コンシューマーにバインドされたリーダーを作成します。 TaskWorkspace はファイルを所有し、RecordStore は永続レコードとリカバリーを所有し、 SkillLibrary は不変のインストール済み Skill リビジョンを所有します。
• Agently.skills_executor は管理/コンテキストの互換性のみです。削除された汎用の Workspace、ContextBuilder、SkillsManager、Skills ルート/ストラテジー、skill_activation、 または workspace_operation の所有者を再作成しないでください。

ModelRequest の境界

下流のインターフェースを満たす必要がある出力の場合：

• ランタイムのファクトは .input(...) に入れます。
• 権威あるスキーマ、シグネチャ、ソースファクトは .info(...) に入れます。
• 変換および呼び出しのルールは .instruct(...) に入れます。
• 実際に消費される形状は .output(...) に入れます。

消費されるすべてのフィールドについて、型、セマンティクス、必須性、enum/フォーマット/範囲、 null 許容性、およびフィールド間の制約を宣言してください。構造化された ModelRequest に、散文から導出される意図、ルーティング、プランニング、関連性、または品質 判断を所有させ、ホストコードに境界付きの enum/キーの検証とエフェクトの実行を任せてください。

隠れた思考連鎖（chain-of-thought）を要求しないでください。境界付きのプロセスフィールドは、 名前付きの役割、境界、コンシューマー、保持ルール、および失敗時の振る舞いがある場合にのみ正当化されます。

プロジェクトと検証ゲート

単一リクエストのアプリケーションは、コンポジション、設定、プロンプト契約、 テストから始めてください。ワークフロー、サービス、Actions、ローカル Skills、ユーティリティ、または リソースは、現在の所有者とコンシューマーが存在する場合にのみ追加してください。論理ノードは 自動的にファイルやクラスになるわけではありません。

決定論的テストは、スキーマ、アイデンティティ、ライフサイクル、アカウンティング、ファイルまたは レコードのエフェクト、および安全性を証明します。セマンティックな品質には、宣言された基準と、 構造化されたコーディングエージェント、モデル、または人間によるレビューが必要です。重要度 （ハードゲートまたはソフトターゲット）は、評価方法（決定論的または セマンティック）とは別に分類してください。

実モデルに関する主張については、まず基準を定義し、シミュレーションを正直にラベル付けし、 認可された最小の代表的な実行を使用し、生のファクトを判断とは別に記録してください。実際の トレースは、シミュレーションによる期待を上書きします。

アンチパターン

• ネイティブの所有者を確認する前に、カスタムパーサー、リトライマネージャー、状態ストア、またはスケジューラーを使用すること。
• キーワード、サブストリング、regex、トークナイゼーション、または手書きのスコアテーブルを セマンティックの所有者とすること。
• 消費されない出力フィールド、リクエストステージ、ラッパー、またはプロジェクトディレクトリ。
• 依存関係の分析なしに、すべてをシリアル化する複雑なフロー。
• 完全なソース、アイデンティティの多いレコード、または生のメタデータをすべての プロンプトにコピーすること。
• フレームワークの機能の証拠として提示される、定型の回答、隠された期待回答フィクスチャ、または テスト専用の本番ブランチ。