production-orchestrator

Production Orchestrator is an agent-based production scheduling tool aimed at small embroidery and decorated-apparel shops. It is published as a submission candidate for a hackathon "Agents for Humans" professional agents track, validated locally, against Amazon Bedrock, and deployed to Bedrock AgentCore Runtime. It is built with the Strands Agents framework and is intended to inspect shop state, identify blockers, propose an evidence-backed schedule, surface consequential decisions for human approval, and apply only the exact plan a person reviewed. Problem it targets Small production shops coordinate due dates, customer approvals, material availability, machine compatibility, operator capacity and customer communication simultaneously. A single rush order can force several connected decisions, and the cost of missing one is rework, a late delivery, or an avoidable customer escalation. The project's stated objective is to inspect real shop state, detect blockers deterministically, produce a versioned proposal, draft the related communications, stop before a consequential write, and preserve a complete audit chain. How the agent is assembled One agent in the workflow module coordinates intake, shop reads, deterministic analysis, proposal creation, communication drafting and the gated application step. Eight tool functions are exposed: intake_customer_request, list_active_orders, get_inventory, get_machine_capacity, analyze_shop_blockers, propose_schedule, draft_communications, and apply_production_plan. A BeforeToolCallEvent hook, ProductionPlanApprovalHook, intercepts apply_production_plan before execution and raises the approval interrupt, so the reviewer accepts or rejects the exact hash-addressed proposal. A FileSessionManager persists the Strands session and the pending interrupt, allowing the worker process to die between proposal and decision; a fresh process reconstructs the session and submits the official interrupt response. The README stresses a deliberate division of responsibility: the model chooses and sequences tools, while deterministic code validates all extracted shop facts, calculates blockers and quantities, binds approval to canonical proposal content, and enforces the write gate. The stated intent is to keep agent reasoning useful without asking the model to enforce its own permissions. Judge-facing local demo After uv sync --locked, running the demo command starts a local interface at 127.0.0.1:8765 that exercises the complete eight-tool workflow and stops at a real Strands interrupt before the consequential write. The page renders the recorded tool trail as an activity feed, a before/after production board, readable message drafts, and the exact decision consequences. Choosing "Keep current schedule" or "Approve coordinated plan" causes a fresh process to reconstruct the persisted session and resume the official interrupt. Three synthetic scenarios are selectable: a rush order with a capacity conflict and thread shortage, a team-jersey order that displaces two smaller jobs, and a metallic monogram batch with a material shortage. A "Technical proof" expansion shows the immutable proposal hash, model and provider facts, distinct start and resume process IDs, and the audit chain. The demo drives the workflow with a deterministic local tool-calling model, so it requires no paid model call; the README states that every shop fact still comes from a real tool call. It binds only to localhost, stores transient SQLite and session state under an ignored demo-runtime path, prepares communications as unsent drafts, and does not provide production authentication, multi-tenancy or external integrations. Provider paths and evidence The full eight-tool rejection and approval paths were exercised through Amazon Bedrock with the amazon.nova-lite-v1:0 model in us-east-1, with reports committed under an evidence directory. According to the README, rejection preserved revision 1 with no plan-applied event, while exact approval atomically advanced the schedule and procurement task to revision 2, with the sole applied hash matching the proposal reviewed at the interrupt. Immutable proposals are persisted in SQLite by canonical content hash. Fresh-process rejection and approval runs are described as proving that a new Python interpreter can reconstruct the same agent and session, restore the pending interrupt, and submit the official interrupt response. Wrong interrupt IDs, altered session, proposal or provider bindings, stale state, and replay are reported to fail closed. The same workflow is deployed to Amazon Bedrock AgentCore Runtime as production_orchestrator-3S24euH1Cz. Live start and decide pairs against the endpoint are said to reproduce both outcomes in distinct in-container processes, with rejection applying zero plans and approval applying the exact reviewed hash once. A local-model path exists to show that the governance layer is provider-independent: the interrupt, hash binding, checkpoint verification and fail-closed resume are the same code for every provider. The README reports that this path was exercised with a gemma4:e4b model running fully on a single NVIDIA RTX 3060 through Ollama, invoking all eight tools in the required order and resuming a persisted interrupt in a new process. It explicitly labels these runs as development evidence rather than judged-provider proof, and describes the two latency observations as two data points rather than a controlled benchmark, noting that the decisions and response lengths differ and that provider latency excludes tool execution and operator delay. The Ollama host is treated as part of the checkpoint's trusted provider configuration, so resuming against a different host fails closed just like a swapped AWS profile. Development and tooling Prerequisites listed are Python 3.11+, uv, a tool-capable local model for fallback reproduction, and a named least-privilege AWS profile with explicit region and Bedrock model access for the judged path. Initial setup uses uv sync, pytest and ruff check. Separate CLI entry points drive the full intake workflow and a narrower two-phase restart proof (start, then resume with a decision). The README advises using an unused runtime directory per decision, and states that runtime databases and session files are ignored, and that no AWS credentials, customer information or runtime state belong in git. Documentation and governance Referenced documentation includes an architecture document with system and cross-process approval diagrams plus a table mapping each guarantee to the test or committed evidence that proves it, a shot-by-shot video script, an AgentCore deployment runbook describing the deployed Runtime contract, process-boundary model and limits, and a development contract defining implementation and contest boundaries. The README includes a contest-period and prior-work disclosure: the team previously studied an Apache-2.0 embroidery-shop management application and used that experience only as domain research, with no source code, prompts, UI, assets, schema, customer data, fixtures or implementation incorporated. All submitted product code, tools, agent behavior, interface, synthetic data, tests, documentation and demo materials are stated to have been created during the submission period. The project is licensed under Apache License 2.0, with notice and third-party notice files. Status caveats The repository self-describes as a submission candidate. Its own framing limits it: the local demo omits production authentication, multi-tenancy and external integrations, and communication drafting stops at unsent drafts. The local-model results are presented as development evidence only, and the Bedrock runs are the judged-provider evidence.