MINION no comenzó con una declaración clara de que se convertiría en un ERP. Comenzó con una promesa más abierta: darle al agente suficientes herramientas y contexto para completar trabajo útil. El ERP surgió cuando esa promesa se encontró con la gravedad cotidiana de las operaciones empresariales.
Un asistente puede responder una pregunta con contexto temporal. Un sistema operativo para una empresa debe saber qué organización está activa, qué registro es canónico, qué puede cambiar el solicitante, cómo se valida el cambio y qué sobrevive cuando termina la conversación. Esos requisitos cambiaron el centro del producto.
La primera forma útil
La forma inicial fue una colección de superficies capaces: un gateway de agentes, gestión de chats y sesiones, plugins, herramientas y un Hub en SvelteKit. Cada parte podía resolver un problema local. El gateway sabía cómo llegar a un agente. El Hub presentaba sesiones y configuración. Los plugins añadían capacidades acotadas.
Esa modularidad era valiosa, pero aún no respondía a una pregunta más difícil: ¿qué sucede cuando una acción pertenece a un proceso de negocio en lugar de a una conversación?
Una reserva toca a un cliente, un calendario, un servicio, una expectativa de pago y, a veces, stock. Una venta toca a un turno, un ticket, productos, pagos, configuración tributaria, inventario y el registro de una parte. Un caso de soporte puede pertenecer a la misma persona y organización que ambos. El estado de la conversación por sí solo no puede ser la estructura que los una.
La presión que cambió la arquitectura
La plataforma acumuló inquietudes compartidas antes de acumular módulos:
- identidad y configuración en el ámbito de la organización;
- un modelo de permiso para navegación, páginas, API y acciones de agentes;
- registros a los que se podría hacer referencia en CRM, finanzas, programación, soporte, proyectos y canales;
- transacciones de bases de datos y límites a nivel de filas que no confiaban en una organización proporcionada por el cliente;
- contratos de vista previa y confirmación para cambios propuestos por agentes;
- rutas de auditoría y recuperación operativa.
Estos no eran elementos decorativos de la empresa. Eran las condiciones bajo las cuales el agente podía pasar del comentario a la acción controlada.
El ciclo de acción gobernado
SIGUE LAS FLECHASA need enters in business language, not as an implementation shortcut.
Transcripción accesible del diagrama
Business request, policy gate, governed action, durable event, and operational review form a closed authority loop.
Luego, el Hub se expandió en torno a esas condiciones. CRM, finanzas, programación, soporte, proyectos, stock, punto de venta, Brains, canales, automatizaciones y Workforce se convirtieron en módulos visibles. La puerta de enlace y el registro de herramientas siguieron siendo importantes, pero ya no constituían el producto completo. Se convirtieron en parte de un circuito operativo más amplio.
El cambio decisivo fue de autoridad
La transición más importante no fue de “pocas pantallas” a “muchas pantallas”. Pasó de la autoridad conversacional a la autoridad de registro.
En una conversación, el último mensaje puede redefinir la tarea inmediata. En un ERP, una entrada de stock confirmada no se sobrescribe porque el siguiente mensaje cambió de opinión. La identidad de una parte no puede fusionarse entre organizaciones porque dos nombres se parecen. Un rol no puede heredar permiso de escritura solo porque su botón está visible.
Por lo tanto, MINION se volvió más explícito sobre los límites:
- Resolver la organización confiable y el principal.
- Comprobar el módulo y la capacidad de acción.
- Validar una solicitud tipada.
- Previsualizar o confirmar las acciones de alto impacto.
- Confirmar la mutación dentro del límite de la organización.
- Registrar el resultado operativo y exponer una ruta de recuperación.
El asistente sigue siendo importante. La diferencia es que ahora opera dentro de las mismas limitaciones que el resto de la plataforma.
Donde un asistente cruza a un sistema operativo
SIGUE LAS FLECHASUseful interaction, but not yet a system of record.
Transcripción accesible del diagrama
The maturity sequence crosses an authority threshold between tool calls and owned records, then adds controls before adoption.
Una plataforma, no un catálogo de funciones
Sería fácil contar esta historia como una lista de módulos. Eso perdería el sentido. MINION se convirtió en un ERP cuando diferentes módulos comenzaron a compartir infraestructura gobernada:
- la columna vertebral de identidad conecta personas y organizaciones con registros operativos;
- los movimientos de existencias son documentos y asientos append-only del libro mayor, no contadores editables;
- POS compone catálogo, turnos, pagos, partes, reservas y stock;
- Brains organiza el conocimiento empresarial sin descartar los límites de fuente y acceso;
- las acciones de los agentes utilizan los mismos conceptos de autorización y validación que las mutaciones de cara humana;
- los proyectos pueden conectar el trabajo, los repositorios y las puertas de la fábrica.
La plataforma es valiosa cuando esas conexiones reducen la cantidad de verdades incompatibles que una organización debe mantener.
El registro tiene costuras
Esta es una retrospectiva, no una mitología. Parte de la infraestructura existe como dirección futura o como ruta paralela validada, no como valor predeterminado de la aplicación actual. Por ejemplo, los eventos de dominio confirmados del Hub usan notificaciones de PostgreSQL y conservan el trabajo programado como respaldo duradero. Una ruta privada de JetStream fue diseñada y validada por separado para absorber ráfagas y atender trabajadores acotados, pero eso no la convierte en el plano de eventos declarado de la aplicación.
Mantener esas distinciones visibles es parte de la disciplina del producto. Una especificación registra la intención. El código registra una implementación. Un camino oscuro desplegado demuestra infraestructura. Ninguno de ellos prueba por sí solo que el tráfico de producción haya cambiado.
Mantener la columna vertebral de registros gobernados
Conservaría el límite de la organización, el vocabulario compartido de permisos, la preferencia por una sola columna vertebral de registros en lugar de coincidencias punto a punto y la exigencia de que toda acción de un agente se convierta en una mutación gobernada antes de volverse conveniente.
Publicar el mapa de autoridad
Haría legible la evolución de la plataforma antes. Un sistema en crecimiento necesita un mapa público de autoridad: registros canónicos, contratos de eventos, límites de acción y el estado de cada migración. Ese mapa debe generarse a partir de código y pruebas cuando sea posible, no mantenerse como una segunda arquitectura aspiracional.
Cualquier asistente al que se le pida realizar trabajo empresarial duradero termina enfrentando preguntas propias de un ERP. MINION se volvió interesante cuando dejó de esconderlas.