Production Orchestrator

A governed Strands agent for production shops: resolves rush-order conflicts end to end, then applies only the exact plan a human approved - once - while forged, stale, and replayed inputs fail closed

Comment

Inspiration

A rush order in a small embroidery shop can disrupt machine assignments, consume missing thread, move another customer's delivery, and create purchasing work. I built Production Orchestrator to handle that chain without applying schedule or procurement changes unless a human approves the exact plan.

What it does

Production Orchestrator turns a customer email into a coordinated production proposal. Validated intake checks extracted fields against the shop catalog and calendar, then adds only the candidate order to the queue as a narrow start-of-workflow write without changing the shop revision. The agent reads orders, inventory, and machine capacity, finds shortages and conflicts, then proposes schedule changes, a purchase task, and unsent messages.

The proposal is serialized, hashed, and stored as immutable evidence. A real Strands BeforeToolCallEvent interrupt stops apply_production_plan before it writes. Rejection leaves schedule and procurement unchanged. Approval applies the reviewed proposal once.

Resume treats checkpoints as hostile input. Forged hashes, stale state, replayed approvals, wrong identities, and changed provider bindings are refused before schedule or procurement mutation. Human rejection is audited; integrity failures exit nonzero without a dedicated refusal event.

How I built it

A Strands Agent coordinates eight @tool functions covering intake, orders, inventory, capacity, blocker analysis, scheduling, communication drafts, and plan application. The model interprets requests and sequences tools. Deterministic Python owns validation, dates, quantities, inventory arithmetic, proposal hashing, and permission checks.

SQLite stores shop state, proposals, and the audit chain. Strands FileSessionManager persists the session and pending interrupt. A fresh process can reconstruct the agent, restore the interrupt, and recheck the proposal and current state before submitting interruptResponse.

The local demo uses a deterministic model so judges can run it without credentials. Separate evidence exercises the full workflow with Amazon Nova Lite through Amazon Bedrock. The workflow is also deployed to Amazon Bedrock AgentCore Runtime through start and decide. AgentCore evidence records rejection and approval in separate runtime processes. Model proof and deployment proof remain separate so each claim matches its observed run.

Challenges

Model judgment had to stop where shop facts and authority begin. Intake rejects invalid or invented fields. Approval also had to survive process death without becoming reusable permission. Resume rechecks the session, interrupt, canonical proposal, provider, and shop revision. Atomic updates and replay detection make approval failures happen before another schedule or procurement write.

Results

Rejection preserves revision 1 with zero plans applied. Approval advances to revision 2 and applies the proposal once. Draft messages remain unsent because sending requires a separate decision. The repository has 114 tests covering the tool workflow, proposal integrity, atomic application, fresh-process resume, forged checkpoints, stale state, replay, provider binding, and auditing. Current main CI is green.

What I learned

Approval that outlives a worker is a distributed protocol with identity, persistence, replay protection, and explicit failure behavior. The model handles ambiguity and tool selection. Deterministic code owns facts, invariants, and authority. Operators also need evidence of what was proposed, approved, changed, or refused.

What's next

Next steps are authenticated multi-user approvals, signed decisions, role-based policies, and connectors for order, inventory, purchasing, email, and calendar systems. Sending communications will remain a separate approval domain.

Prior-work disclosure

Production Orchestrator was created during the Agents for Humans submission period. Earlier BobbinBoss/Aimbroidery work informed the domain problem only; no prior code, prompts, UI, assets, schema, data, fixtures, or implementation were reused. All submitted implementation and demo materials are new. All customer and shop data shown is synthetic.

Built With

Share this project:

Updates

posted an update —

Build log: from spike to submitted

The project started with one question: can an agent handle a full production workflow while proving it never changed the shop without human approval?

The spike. Real Strands tools, a BeforeToolCallEvent interrupt, and a SQLite audit chain. Rejection left revision 1 with zero writes; approval applied the exact reviewed hash once. Then the hard part: making that approval survive process death. A fresh process restores the session, re-verifies the checkpoint, and submits the official interruptResponse.

The judged provider. Both paths ran live on Amazon Bedrock with Nova Lite. The same scenario produces the same canonical proposal hash across deterministic, Bedrock, and Ollama backends, because deterministic code owns every shop fact and the model only extracts.

The demo. A localhost judge-facing interface showing the tool trail, the proposal, the interrupt, and the audit chain. Deterministic model, no credentials needed.

Deployment. The same workflow deployed to Bedrock AgentCore Runtime behind start and decide invocations, with committed evidence of rejection and approval in separate runtime processes.

Submitted. Video, architecture, testing instructions, and three builder.aws posts are all public.

114 tests, current main CI green, Apache-2.0. The repo has the full evidence trail.

Log in or sign up for Devpost to join the conversation.

Submission history