production-orchestrator

Production Orchestrator는 소규모 자수 및 의류 장식 샵을 겨냥한 에이전트 기반 생산 일정 관리 도구입니다. 이 프로젝트는 "Agents for Humans" 해커톤의 전문 에이전트 트랙 제출 후보로 공개되었으며, 로컬 검증 및 Amazon Bedrock을 통한 검증을 거쳐 Bedrock AgentCore Runtime에 배포되었습니다. Strands Agents 프레임워크로 구축된 이 도구는 샵의 상태를 점검하고, 병목 구간을 식별하며, 근거 기반의 일정을 제안하고, 중요한 결정 사항에 대해 인간의 승인을 받은 후 검토된 계획만을 정확히 적용하도록 설계되었습니다. 해결하려는 문제 소규모 생산 샵은 마감일, 고객 승인, 자재 가용성, 기계 호환성, 작업자 역량 및 고객 커뮤니케이션을 동시에 조정해야 합니다. 단 하나의 긴급 주문만으로도 여러 연쇄적인 결정이 필요하며, 하나라도 놓칠 경우 재작업, 배송 지연 또는 고객 불만으로 이어질 수 있습니다. 본 프로젝트의 목표는 실제 샵 상태를 점검하여 결정론적으로 병목 구간을 감지하고, 버전 관리되는 제안서를 생성하며, 관련 커뮤니케이션 초안을 작성하고, 중요한 쓰기 작업 전 단계에서 멈춰 완전한 감사 체인을 유지하는 것입니다. 에이전트 구성 방식 워크플로우 모듈의 단일 에이전트가 접수, 샵 상태 읽기, 결정론적 분석, 제안 생성, 커뮤니케이션 초안 작성 및 게이트 적용 단계를 조정합니다. 총 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 실행 전 이를 가로채 승인 인터럽트를 발생시키며, 이를 통해 검토자는 해시 주소가 지정된 정확한 제안을 수락하거나 거부할 수 있습니다. FileSessionManager는 Strands 세션과 보류 중인 인터럽트를 유지하여, 제안과 결정 사이에 작업 프로세스가 종료되더라도 새로운 프로세스가 세션을 재구성하여 공식 인터럽트 응답을 제출할 수 있게 합니다. README에서는 책임의 의도적인 분리를 강조합니다. 모델은 도구를 선택하고 순서를 정하며, 결정론적 코드는 추출된 모든 샵 팩트를 검증하고 병목 구간과 수량을 계산하며, 승인을 정준 제안 내용에 바인딩하고 쓰기 게이트를 강제합니다. 이는 모델에게 스스로 권한을 강제하도록 요청하지 않으면서 에이전트의 추론 능력을 유용하게 활용하기 위함입니다. 심사위원용 로컬 데모 'uv sync --locked' 후 데모 명령을 실행하면 127.0.0.1:8765에서 로컬 인터페이스가 시작됩니다. 여기서는 8개 도구의 전체 워크플로우를 실행하고 중요한 쓰기 작업 전 Strands 인터럽트에서 멈추는 과정을 시연합니다. 페이지에는 기록된 도구 추적 활동 피드, 생산 보드의 전/후 비교, 읽기 가능한 메시지 초안 및 정확한 결정 결과가 렌더링됩니다. "현재 일정 유지" 또는 "조정된 계획 승인"을 선택하면 새로운 프로세스가 유지된 세션을 재구성하여 공식 인터럽트를 재개합니다. 세 가지 가상 시나리오를 선택할 수 있습니다: 설비 충돌 및 실 부족이 있는 긴급 주문, 두 개의 작은 작업을 밀어내는 팀 저지 주문, 자재 부족이 있는 메탈릭 모노그램 배치 주문입니다. "기술 증명(Technical proof)" 확장 탭에서는 불변의 제안 해시, 모델 및 제공자 정보, 서로 다른 시작/재개 프로세스 ID 및 감사 체인을 보여줍니다. 데모는 결정론적인 로컬 도구 호출 모델로 워크플로우를 구동하므로 유료 모델 호출이 필요 없으며, 모든 샵 팩트는 실제 도구 호출에서 가져옵니다. localhost에만 바인딩되고, 일시적인 SQLite 및 세션 상태는 무시된 demo-runtime 경로에 저장되며, 커뮤니케이션은 전송되지 않은 초안으로 준비됩니다. 또한 프로덕션 인증, 멀티테넌시 또는 외부 통합은 제공하지 않습니다. 제공자 경로 및 증거 8개 도구의 거부 및 승인 전체 경로는 us-east-1 지역의 Amazon Bedrock(amazon.nova-lite-v1:0 모델)을 통해 실행되었으며, 보고서는 evidence 디렉토리에 커밋되었습니다. README에 따르면, 거부 시에는 plan-applied 이벤트 없이 리비전 1이 유지되었고, 정확한 승인 시에는 일정과 조달 작업이 리비전 2로 원자적으로 업데이트되었으며, 적용된 해시가 인터럽트에서 검토된 제안과 일치했습니다. 불변의 제안은 정준 콘텐츠 해시에 의해 SQLite에 저장됩니다. 새로운 프로세스를 통한 거부 및 승인 실행은 새로운 Python 인터프리터가 동일한 에이전트와 세션을 재구성하고, 보류 중인 인터럽트를 복원하며, 공식 응답을 제출할 수 있음을 증명합니다. 잘못된 인터럽트 ID, 변경된 세션, 제안 또는 제공자 바인딩, 오래된 상태 및 리플레이 시도는 모두 'fail-closed'(안전하게 종료) 처리됩니다. 동일한 워크플로우가 Amazon Bedrock AgentCore Runtime에 production_orchestrator-3S24euH1Cz로 배포되었습니다. 엔드포인트에 대한 라이브 시작 및 결정 쌍은 서로 다른 컨테이너 프로세스에서 두 가지 결과(거부 시 계획 적용 0건, 승인 시 검토된 해시 1건 적용)를 재현합니다. 거버넌스 레이어가 제공자 독립적임을 보여주기 위해 로컬 모델 경로가 존재합니다. 인터럽트, 해시 바인딩, 체크포인트 검증 및 fail-closed 재개는 모든 제공자에 대해 동일한 코드를 사용합니다. README에 따르면 이 경로는 Ollama를 통해 단일 NVIDIA RTX 3060에서 실행되는 gemma4:e4b 모델로 검증되었으며, 8개 도구를 순서대로 호출하고 새 프로세스에서 유지된 인터럽트를 재개했습니다. 이러한 실행은 심사 대상 제공자 증명이 아닌 개발 증거로 명시되었으며, 지연 시간 관찰 결과는 제어된 벤치마크가 아닌 두 개의 데이터 포인트로 설명됩니다. 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 실행 결과가 심사 대상 제공자 증거입니다.