production-orchestrator

Production Orchestratorは、小規模な刺繍および装飾アパレルショップを対象としたエージェントベースの生産スケジューリングツールです。ハッカソン「Agents for Humans」のプロフェッショナルエージェントトラックへの提出候補として公開されており、ローカルでの検証を経てAmazon Bedrockに対して検証され、Bedrock AgentCore Runtimeにデプロイされています。Strands Agentsフレームワークで構築されており、ショップの状態を検査し、ボトルネックを特定し、根拠に基づいたスケジュールを提案し、重要な決定を人間が承認させ、レビューされた正確なプランのみを適用することを目的としています。 ターゲットとする課題 小規模な生産ショップでは、納期、顧客の承認、資材の可用性、機械の互換性、オペレーターの能力、および顧客とのコミュニケーションを同時に調整する必要があります。急ぎの注文が1件入るだけで、連鎖的に複数の決定を迫られ、一つでも見落とすと、手直しや配送遅延、あるいは回避可能な顧客トラブルにつながります。本プロジェクトの目的は、実際のショップ状態を検査し、決定論的にボトルネックを検出し、バージョン管理された提案を作成し、関連する連絡文を起草し、重要な書き込み処理の前に停止させ、完全な監査チェーンを保持することです。 エージェントの構成 ワークフローモジュールの1つのエージェントが、受付、ショップ情報の読み取り、決定論的な分析、提案の作成、連絡文の起草、およびゲート付きの適用ステップを調整します。8つのツール関数（intake_customer_request, list_active_orders, get_inventory, get_machine_capacity, analyze_shop_blockers, propose_schedule, draft_communications, apply_production_plan）が公開されています。 BeforeToolCallEventフックであるProductionPlanApprovalHookが、実行前にapply_production_planをインターセプトして承認中断（interrupt）を発生させ、レビュー担当者がハッシュアドレス指定された正確な提案を承認または拒否できるようにします。FileSessionManagerがStrandsセッションと保留中の中断を永続化するため、提案から決定までの間にワーカープロセスが終了しても、新しいプロセスがセッションを再構築して正式な中断応答を送信することが可能です。 READMEでは、責任の明確な分離が強調されています。モデルはツールの選択と順序付けを行い、決定論的なコードが抽出されたショップ事実の検証、ボトルネックと数量の計算、承認と正準的な提案内容の紐付け、および書き込みゲートの強制を行います。これにより、モデルに自身の権限を強制させることなく、エージェントの推論を有効に活用することを意図しています。 審査員向けローカルデモ uv sync --locked後、デモコマンドを実行すると127.0.0.1:8765でローカルインターフェースが起動し、8つのツールによる完全なワークフローを実行し、重要な書き込み前のStrands中断で停止します。ページには、記録されたツールトレイルがアクティビティフィードとして、また生産ボードの前後、読み取り可能なメッセージ下書き、および正確な決定結果としてレンダリングされます。「現在のスケジュールを維持」または「調整済みプランを承認」を選択すると、新しいプロセスが永続化されたセッションを再構築し、正式な中断を再開します。 3つの合成シナリオ（設備競合と糸不足を伴う急ぎ注文、2つの小規模ジョブを押し出すチームジャージ注文、資材不足のメタリックモノグラムバッチ）が選択可能です。「Technical proof」の展開では、不変の提案ハッシュ、モデルとプロバイダーの事実、異なる開始および再開プロセスID、および監査チェーンが表示されます。 デモは決定論的なローカルツール呼び出しモデルでワークフローを駆動するため、有料のモデル呼び出しは不要です。READMEには、すべてのショップ事実は依然として実際のツール呼び出しから取得されると記載されています。localhostにのみバインドし、一時的なSQLiteとセッション状態を無視されたdemo-runtimeパスに保存し、連絡事項は未送信の下書きとして準備します。また、本番環境の認証、マルチテナンシー、外部統合は提供していません。 プロバイダーパスとエビデンス 8つのツールによる拒否および承認パスのすべてが、us-east-1のamazon.nova-lite-v1:0モデルを使用したAmazon Bedrockを通じて検証され、レポートがevidenceディレクトリにコミットされています。READMEによると、拒否した場合はリビジョン1が保持されplan-appliedイベントは発生せず、正確に承認した場合はスケジュールと調達タスクがリビジョン2にアトミックに更新され、適用されたハッシュが中断時にレビューされた提案と一致したことが確認されています。 不変の提案は、正準的なコンテンツハッシュによってSQLiteに永続化されます。新プロセスによる拒否および承認の実行は、新しいPythonインタプリタが同じエージェントとセッションを再構築し、保留中の中断を復元して正式な応答を送信できることを証明しています。誤った中断ID、変更されたセッション、提案またはプロバイダーのバインド、古い状態、およびリプレイは、すべて「fail closed（安全に失敗）」することが報告されています。 同じワークフローがAmazon Bedrock AgentCore Runtimeにproduction_orchestrator-3S24euH1Czとしてデプロイされています。エンドポイントに対するライブの開始および決定のペアは、個別のコンテナプロセス内で両方の結果を再現し、拒否時はプランが適用されず、承認時はレビューされた正確なハッシュが一度だけ適用されることが述べられています。 ローカルモデルのパスは、ガバナンス層がプロバイダーに依存しないことを示すために存在します。中断、ハッシュバインド、チェックポイント検証、およびfail-closed再開は、すべてのプロバイダーで共通のコードです。READMEでは、このパスがOllama経由で単一のNVIDIA RTX 3060上で動作するgemma4:e4bモデルで検証され、必要な順序ですべてのツールを呼び出し、新プロセスで永続化された中断を再開したことが報告されています。これらの実行は審査対象のプロバイダー証明ではなく、開発エビデンスとして明示的にラベル付けされており、2つのレイテンシ観察結果は制御されたベンチマークではなく2つのデータポイントとして記述されています。Ollamaホストはチェックポイントの信頼されたプロバイダー構成の一部として扱われるため、異なるホストで再開しようとすると、AWSプロファイルを入れ替えた場合と同様にfail closedとなります。 開発とツール 前提条件として、Python 3.11+、uv、フォールバック再現用のツール対応ローカルモデル、および審査パス用の明示的なリージョンとBedrockモデルアクセス権を持つ最小権限のAWSプロファイルが挙げられています。初期セットアップにはuv sync、pytest、ruff checkを使用します。個別のCLIエントリポイントが、完全な受付ワークフローと、より限定的な2フェーズの再起動証明（開始、その後決定による再開）を駆動します。READMEでは、決定ごとに未使用のランタイムディレクトリを使用することを推奨しており、ランタイムデータベースとセッションファイルは無視され、AWS資格情報、顧客情報、ランタイム状態をgitに含めてはならないとしています。 ドキュメントとガバナンス 参照ドキュメントには、システムおよびプロセス間承認図を含むアーキテクチャドキュメント、各保証を証明するテストまたはコミット済みエビデンスのマッピングテーブル、ショットバイショットのビデオスクリプト、デプロイされたRuntimeコントラクト、プロセス境界モデル、および制限を記述したAgentCoreデプロイメントランブック、および実装とコンテストの境界を定義する開発コントラクトが含まれています。 READMEには、コンテスト期間および先行研究の開示が含まれています。チームは以前にApache-2.0の刺繍ショップ管理アプリケーションを研究していましたが、その経験はドメイン研究としてのみ使用し、ソースコード、プロンプト、UI、アセット、スキーマ、顧客データ、フィクスチャ、または実装は一切組み込んでいません。提出されたすべての製品コード、ツール、エージェントの動作、インターフェース、合成データ、テスト、ドキュメント、およびデモ資料は、提出期間中に作成されたものであると明記されています。プロジェクトはApache License 2.0の下でライセンスされており、通知およびサードパーティ通知ファイルが付属しています。 ステータスの注意点 リポジトリは自身を提出候補として記述しています。その枠組みによる制限があり、ローカルデモでは本番環境の認証、マルチテナンシー、外部統合が省略されており、連絡文の起草は未送信の下書きで停止します。ローカルモデルの結果は開発エビデンスとしてのみ提示され、Bedrockでの実行が審査対象のプロバイダーエビデンスとなります。