production-orchestrator

Production Orchestrator es una herramienta de programación de producción basada en agentes dirigida a pequeños talleres de bordado y ropa decorada. Se presenta como candidato para la pista de agentes profesionales del hackathon "Agents for Humans", validado localmente, contra Amazon Bedrock y desplegado en Bedrock AgentCore Runtime. Está construido con el framework Strands Agents y está destinado a inspeccionar el estado del taller, identificar bloqueos, proponer un cronograma respaldado por evidencia, presentar decisiones trascendentales para aprobación humana y aplicar únicamente el plan exacto revisado por una persona. Problema que aborda Los pequeños talleres de producción coordinan simultáneamente fechas de entrega, aprobaciones de clientes, disponibilidad de materiales, compatibilidad de máquinas, capacidad de operadores y comunicación con el cliente. Un solo pedido urgente puede forzar varias decisiones conectadas, y el costo de omitir una es el reprocesamiento, una entrega tardía o una escalada evitable del cliente. El objetivo declarado del proyecto es inspeccionar el estado real del taller, detectar bloqueos de manera determinista, producir una propuesta versionada, redactar las comunicaciones relacionadas, detenerse antes de una escritura trascendental y preservar una cadena de auditoría completa. Cómo se ensambla el agente Un agente en el módulo de flujo de trabajo coordina la recepción, las lecturas del taller, el análisis determinista, la creación de propuestas, la redacción de comunicaciones y el paso de aplicación restringido. Se exponen ocho funciones de herramienta: intake_customer_request, list_active_orders, get_inventory, get_machine_capacity, analyze_shop_blockers, propose_schedule, draft_communications y apply_production_plan. Un hook BeforeToolCallEvent, ProductionPlanApprovalHook, intercepta apply_production_plan antes de la ejecución y genera la interrupción de aprobación, para que el revisor acepte o rechace la propuesta exacta direccionada por hash. Un FileSessionManager persiste la sesión de Strands y la interrupción pendiente, permitiendo que el proceso del trabajador finalice entre la propuesta y la decisión; un proceso nuevo reconstruye la sesión y envía la respuesta oficial a la interrupción. El README enfatiza una división deliberada de responsabilidades: el modelo elige y secuencia las herramientas, mientras que el código determinista valida todos los hechos extraídos del taller, calcula bloqueos y cantidades, vincula la aprobación al contenido canónico de la propuesta y hace cumplir la puerta de escritura. La intención declarada es mantener el razonamiento del agente útil sin pedirle al modelo que haga cumplir sus propios permisos. Demo local para el jurado Después de uv sync --locked, ejecutar el comando de demo inicia una interfaz local en 127.0.0.1:8765 que ejercita el flujo de trabajo completo de ocho herramientas y se detiene en una interrupción real de Strands antes de la escritura trascendental. La página renderiza el rastro de herramientas registrado como un feed de actividad, un tablero de producción antes/después, borradores de mensajes legibles y las consecuencias exactas de la decisión. Elegir "Keep current schedule" o "Approve coordinated plan" hace que un proceso nuevo reconstruya la sesión persistida y reanude la interrupción oficial. Se pueden seleccionar tres escenarios sintéticos: un pedido urgente con conflicto de capacidad y escasez de hilo, un pedido de camisetas de equipo que desplaza dos trabajos más pequeños y un lote de monogramas metálicos con escasez de material. Una expansión de "Technical proof" muestra el hash de la propuesta inmutable, hechos del modelo y proveedor, IDs de proceso de inicio y reanudación distintos y la cadena de auditoría. La demo impulsa el flujo de trabajo con un modelo de llamada a herramientas local determinista, por lo que no requiere llamadas a modelos de pago; el README establece que cada hecho del taller proviene igualmente de una llamada a herramienta real. Se vincula solo a localhost, almacena el estado de SQLite y la sesión transitoria bajo una ruta de demo-runtime ignorada, prepara las comunicaciones como borradores no enviados y no proporciona autenticación de producción, multi-tenencia ni integraciones externas. Rutas del proveedor y evidencia Las rutas completas de rechazo y aprobación de las ocho herramientas se ejercitaron a través de Amazon Bedrock con el modelo amazon.nova-lite-v1:0 en us-east-1, con informes consignados en un directorio de evidencia. Según el README, el rechazo preservó la revisión 1 sin evento de plan aplicado, mientras que la aprobación exacta avanzó atómicamente el cronograma y la tarea de adquisición a la revisión 2, con el único hash aplicado coincidiendo con la propuesta revisada en la interrupción. Las propuestas inmutables se persisten en SQLite mediante el hash de contenido canónico. Las ejecuciones de rechazo y aprobación de procesos nuevos se describen como prueba de que un nuevo intérprete de Python puede reconstruir el mismo agente y sesión, restaurar la interrupción pendiente y enviar la respuesta oficial. Se informa que los IDs de interrupción incorrectos, la sesión alterada, las vinculaciones de propuesta o proveedor, el estado obsoleto y la repetición fallan cerrados. El mismo flujo de trabajo está desplegado en Amazon Bedrock AgentCore Runtime como production_orchestrator-3S24euH1Cz. Se afirma que los pares de inicio y decisión en vivo contra el endpoint reproducen ambos resultados en procesos distintos dentro del contenedor, con el rechazo aplicando cero planes y la aprobación aplicando el hash exacto revisado una vez. Existe una ruta de modelo local para mostrar que la capa de gobernanza es independiente del proveedor: la interrupción, la vinculación de hash, la verificación de checkpoint y la reanudación de fallo cerrado son el mismo código para cada proveedor. El README informa que esta ruta se ejercitó con un modelo gemma4:e4b ejecutándose totalmente en una sola NVIDIA RTX 3060 a través de Ollama, invocando las ocho herramientas en el orden requerido y reanudando una interrupción persistida en un proceso nuevo. Etiqueta explícitamente estas ejecuciones como evidencia de desarrollo en lugar de prueba de proveedor juzgado, y describe las dos observaciones de latencia como dos puntos de datos en lugar de un benchmark controlado, señalando que las decisiones y las longitudes de respuesta difieren y que la latencia del proveedor excluye la ejecución de herramientas y el retraso del operador. El host de Ollama se trata como parte de la configuración de proveedor confiable del checkpoint, por lo que la reanudación contra un host diferente falla cerrada, al igual que un perfil de AWS intercambiado. Desarrollo y herramientas Los prerrequisitos enumerados son Python 3.11+, uv, un modelo local capaz de usar herramientas para reproducción de respaldo y un perfil de AWS de privilegio mínimo nombrado con acceso explícito a la región y al modelo Bedrock para la ruta juzgada. La configuración inicial utiliza uv sync, pytest y ruff check. Puntos de entrada CLI separados impulsan el flujo de trabajo de recepción completo y una prueba de reinicio de dos fases más estrecha (inicio y luego reanudación con una decisión). El README aconseja usar un directorio de runtime no utilizado por decisión, y establece que las bases de datos de runtime y los archivos de sesión son ignorados, y que ninguna credencial de AWS, información de clientes o estado de runtime pertenece a git. Documentación y gobernanza La documentación referenciada incluye un documento de arquitectura con diagramas de sistema y de aprobación entre procesos, además de una tabla que mapea cada garantía con la prueba o evidencia consignada que la demuestra, un guion de video paso a paso, un runbook de despliegue de AgentCore que describe el contrato de Runtime desplegado, el modelo de límite de proceso y los límites, y un contrato de desarrollo que define la implementación y los límites del concurso. El README incluye una divulgación del período del concurso y trabajos previos: el equipo estudió previamente una aplicación de gestión de talleres de bordado Apache-2.0 y utilizó esa experiencia solo como investigación de dominio, sin incorporar código fuente, prompts, UI, activos, esquemas, datos de clientes, fixtures o implementación. Se afirma que todo el código del producto enviado, herramientas, comportamiento del agente, interfaz, datos sintéticos, pruebas, documentación y materiales de demo fueron creados durante el período de entrega. El proyecto tiene licencia Apache License 2.0, con archivos de aviso y aviso de terceros. Advertencias de estado El repositorio se describe a sí mismo como un candidato a entrega. Su propio marco lo limita: la demo local omite la autenticación de producción, la multi-tenencia y las integraciones externas, y la redacción de comunicaciones se detiene en borradores no enviados. Los resultados del modelo local se presentan solo como evidencia de desarrollo, y las ejecuciones de Bedrock son la evidencia del proveedor juzgado.