El diagnóstico que PIMSA aprobó no cambia: 18 agentes — 3 orquestadores (Hugo, Tomás, Olivia) + 15 especialistas — ejecutando las 63 actividades en 13 áreas operativas. Lo que cambia es de dónde sale la información: en lugar de que cada agente se conecte a seis sistemas distintos, Nyvia centraliza todo el dato de PIMSA en una plataforma sobre Amazon S3 + Snowflake, y los agentes de HAILO consumen vistas de negocio documentadas. Este documento es el plan de ejecución: qué construye cada quien, qué necesita HAILO de Nyvia — vista por vista, actividad por actividad — y el roadmap conjunto de 13 semanas.
PIMSA sumó a Nyvia para construir el cimiento de datos: extracción de todas las fuentes, bóveda en Amazon S3, catálogo en AWS Glue y vistas de negocio en Snowflake. HAILO construye los agentes encima de ese cimiento. Ustedes definen la estrategia; los dos equipos corren en paralelo sin estorbarse.
Los mismos 18 agentes y las mismas 63 actividades del alcance contractual aprobado. Mismos nombres, mismas áreas, mismos criterios de éxito.
Antes: cada agente conectado por su cuenta a Close, MyPimsa, portal Allianz, SharePoint, Excel y WhatsApp. Ahora: una sola integración de lectura — Snowflake — con SQL sobre vistas documentadas.
La extracción de fuentes (incluido el portal Allianz sin API) es responsabilidad de Nyvia con Playwright en su servidor local. HAILO ya no mantiene conectores de extracción ni credenciales de portales.
El negocio llega modelado: splits por producto, cancelaciones que restan producción neta, bonos e identidad única del cliente (teléfono E.164) entre cinco sistemas — resuelto antes de escribir una línea de código de agente.
Un solo dato, tres consumidores: agentes HAILO, BI y el sistema interno nuevo (fábrica de software) leen la misma fuente de verdad. Los cambios de sistema interno no rompen a los agentes: los absorbe la capa.
Este es un plan de trabajo, no una propuesta comercial: no contiene precios ni condiciones de pago. El alcance económico ya está acordado en el diagnóstico aprobado y sus anexos.
Dimensionada para el volumen real de PIMSA (~94,500 leads históricos, ~3,000 nuevos por semana). Sin clúster permanente: el procesamiento vive en un servidor local de Nyvia y Snowflake se enciende solo cuando alguien pregunta.
IAM con mínimo privilegio · Secrets Manager para credenciales · cifrado S3 SSE y TLS. Datos bajo LFPDPPP y CNSF: lo sensible se segrega del lado de la capa.
CloudWatch: logs por fuente y ejecución, métricas de aceptados/rechazados, alarmas ante fallas consecutivas. Tabla etl_execution_log en Snowflake.
Toda fila es rastreable hasta el archivo, la fecha y la ejecución que la produjo. RAW conserva el original sin transformación destructiva.
El dato maestro vive en formatos abiertos, en la cuenta de PIMSA. El cimiento no es de Nyvia ni de HAILO: es de PIMSA.
Una sola regla dura y el resto se sigue solo: HAILO no lee el dato maestro de S3 en directo — lee vistas de Snowflake. El dato maestro cambia de forma cada vez que una fuente cambia; las vistas no. Si los agentes leen la vista, no se rompen nunca.
HAILO_AGENTS)SÍUna vista publicada no cambia de esquema sin aviso previo de al menos una semana.
Cada vista dice con qué periodicidad se actualiza. Si se atrasa, la bitácora lo registra.
Campos, tipos, significado de negocio y una consulta de ejemplo que funciona. Vive en el catálogo (carpeta 03).
Toda fila es rastreable hasta el archivo, la fecha y la ejecución que la produjo.
Tres superficies, nada más. Todo lo demás (WhatsApp, Outlook, Calendly, Slack, escritura al CRM) son canales de acción que siguen siendo integración directa de HAILO — Nyvia provee el dato, no el canal.
Consultas SELECT sobre vistas del esquema de consumo. Conector oficial de Python (snowflake-connector-python) y SQL API REST (/api/v2/statements) para llamadas ligeras desde herramientas MCP.
Lo que los agentes generan (análisis de sesión, resultados A/B, avisos enviados, Vobos, cortes aprobados) entra a la bóveda como cualquier otra fuente: PUT con rol IAM dedicado, formato JSONL, un manifiesto por carga.
Tablas propias de los agentes en Snowflake: memoria de trabajo, colas de seguimiento, modelos de viabilidad, simuladores. HAILO las crea y administra; Nyvia no las toca.
Una línea en la carpeta 03: qué pregunta de negocio necesita responder el agente, con qué frecuencia y qué campos espera. Pregunta de negocio, no consulta SQL: «necesito saber cuánto se le paga a cada asesor este corte».
Con una de tres respuestas: ya existe (aquí está) · se publica en X días · no es posible con la fuente actual, y por qué.
Campos, tipos, frescura declarada y ejemplo de consulta. Una vez publicada, no cambia sin aviso previo.
El catálogo es el menú de HAILO: si está ahí, se puede consumir. Cualquiera ve qué vistas existen sin preguntar.
La estructura es plana: el equipo de PIMSA habla con Hugo, Tomás y Olivia; ellos delegan a los especialistas. Para cada actividad se define: qué vistas de Snowflake consume (lo que HAILO le pide a Nyvia), por qué canales actúa (integración directa de HAILO) y qué escribe de vuelta a la bóveda. La ola indica cuándo se productiviza, siguiendo el calendario conjunto.
generar_corte.py.HAILO_AGENTS y migra después.
Cada fila es una solicitud para la carpeta 03, planteada como pregunta de negocio con su contrato propuesto y frescura requerida. Los nombres son propuesta de HAILO — el nombre final y el esquema los define Nyvia al publicar. Las vistas de la Ola 1 son el entregable comprometido del 7 de agosto.
| Vista | Pregunta de negocio | Contrato propuesto (campos clave) | Frescura | Act. · Agente |
|---|---|---|---|---|
| V_COMISIONES_CORTE_SEMANAL | ¿Cuánto se le paga a cada asesor este corte y de qué ventas viene? | corte_id · fecha_corte · asesor · póliza · producto · canal_venta · monto_bruto · split_oso · split_mau · split_asesor · monto_asesor · ref. archivo origen | Semanal (día de corte) | A.1 A.3 A.4 · Carla |
| V_COMISIONES_DISCREPANCIAS | ¿Qué diferencias hay entre el reporte de Allianz y el control interno, y por qué? | corte_id · tipo (falta_en_allianz / falta_en_control / diferencia_monto / cancelada_no_actualizada) · póliza · asesor · monto_allianz · monto_control · causa_probable | Semanal | A.2 · Carla |
| V_ASESORES_DATOS_PAGO | ¿A quién le facturo y con qué datos fiscales? | asesor_id · nombre · rfc · clabe · email · teléfono E.164 · tipo (webinar/orgánico) · estatus | Diaria | A.4 · Carla |
| V_BONOS_MENSUALES | ¿Quién ganó bono este mes y cuánto? | mes · asesor · tipo_asesor · bono_base · bono_cumplimiento · bono_crosssell_vida · cancelaciones_restadas · total_devengado | Mensual (día 1) | A.9 · Carla |
| V_PRODUCCION_NETA_MENSUAL | ¿Cuál es la producción neta de cada asesor, por fuente del prospecto? | mes · asesor · fuente (webinar/orgánico/referido/campaña) · valor_plan_emitido · num_solicitudes · cancelaciones · produccion_neta | Mensual + parcial diario | A.11 · Carla |
| V_CANCELACIONES | ¿Qué pólizas se cancelaron y a qué asesor le pegan? | fecha · póliza · asesor_original · valor_plan · motivo · fuente_detección (cartera / WhatsApp) | Diaria | G.2 A.9 A.11 · Nora Carla |
| V_PROVEEDORES_FACTURACION | ¿A qué proveedor le toca facturar pronto? | proveedor · frecuencia · próxima_fecha · último_aviso | Diaria | A.7 · Carla |
| V_PRESUPUESTO_MENSUAL | ¿Cuánto presupuesto disponible queda este mes y cómo cierra? | mes · presupuesto_total · comprometido · disponible · proyección_cierre · umbral_alerta | Diaria | P.2 · Lucía |
| V_POLIZAS_ELEGIBILIDAD_DESCANSO | ¿Este cliente puede tomar periodo de descanso? | póliza · cliente · mes_pago_actual · al_corriente · descansos_previos · elegible | Diaria | F.9 · Renata |
| Vista | Pregunta de negocio | Contrato propuesto (campos clave) | Frescura | Act. · Agente |
|---|---|---|---|---|
| V_CITAS_PROGRAMADAS | ¿Qué citas tocan hoy/mañana y en qué estado va su confirmación? | cita_id · lead_id · teléfono E.164 · prospecto · asesor · fecha_hora · link_zoom · estatus · origen (webinar/orgánico) · toques_enviados | ≤ 15 min | C.2 C.3 C.4 C.7 · Paula |
| V_CITAS_NOSHOW | ¿Quién no se presentó y a quién hay que rescatar? | cita_id · lead_id · asesor · fecha_cita · asistió · intentos_rescate · último_contacto | ≤ 1 h post-cita | C.6 I.15 · Paula Mateo |
| V_DISPONIBILIDAD_ASESORES | ¿Qué 3 ventanas le propongo al prospecto? | asesor · ventanas disponibles próximos 7 días (Calendly) | ≤ 15 min | C.4 C.5 · Paula |
| V_LEADS_SEGUIMIENTO_DIA | ¿Qué seguimientos tocan hoy, por asesor? | lead_id · prospecto · asesor · etapa_manual · días_desde_cita · notas_última_cita · próximo_toque | Diaria (madrugada) | D.2 D.3 · Valeria Tito |
| V_LEADS_DORMIDOS | ¿Qué leads a 30/60/90 días sin cierre vale la pena retomar? | lead_id · días_sin_cierre · notas_cita_previa · monto_interés · asesor | Semanal | D.2 · Valeria |
| V_REUNIONES_TRANSCRIPTS | ¿Qué reuniones asesor-cliente nuevas hay que analizar? | reunión_id · cita_id · asesor · cliente · fecha · transcript_uri (bóveda) · estatus_análisis | Diaria | D.6 D.1 · Sage Valeria |
| V_SECUENCIAS_METRICAS | ¿Qué mensaje de la cadena está fallando y cuál convierte? | secuencia · mensaje_num · canal · enviados · abiertos · respondidos · clicks · periodo | Semanal | I.14 I.15 · Mateo |
| V_REPORTES_CALENDARIO | ¿Qué reporte está por vencer o ya venció sin cargarse? | reporte · responsable · frecuencia · hora_límite · último_entregado_at · estatus | Continua | H.10 · Ana |
| Vista | Pregunta de negocio | Contrato propuesto (campos clave) | Frescura | Act. · Agente |
|---|---|---|---|---|
| V_FUNNEL_WEBINAR | ¿Cómo convierte cada webinar, etapa por etapa y por asesor? | webinar_id · fecha · campaña · registros · asistentes · citas · cierres · pólizas · por asesor | Diaria | H.5 H.24 H.12 I.26 · Mateo Lucía |
| V_ROI_CANAL | ¿Qué canal escalo, optimizo o pauso? | canal/unidad · periodo · inversión_pauta · costos_directos · costos_indirectos · ingreso · roi | Semanal | H.17 H.27 H.28 H.29 · Lucía |
| V_RENTABILIDAD_ASESOR | ¿Qué asesor genera ROI positivo y quién requiere intervención? | asesor · periodo · costo por registro/asistente/cita_agendada/cita_conectada/cierre · comisión_generada · roi_neto | Mensual + parcial continuo | H.18 H.27 · Valeria Lucía |
| V_KPIS_PERSONA | ¿Qué KPI está fuera de meta ahora mismo? | persona · kpi · valor_actual · meta · fuera_de_meta · tendencia | Horaria | H.8 H.12 H.11 H.6 · Diego Ana Camilo |
| V_KPIS_EQUIPO_MENSUAL | ¿Cómo cerró el equipo el mes, con ranking? | mes · persona · kpi · cumplimiento · ranking | Mensual | H.9 H.11 · Audit Ana |
| V_PROYECCION_CIERRE_MES | ¿Cómo va a cerrar el mes si seguimos a este ritmo? | mes · ritmo_cierres · citas_pipeline · show_rate · cierres_proyectados · ingreso_proyectado | Diaria (desde el día 12) | H.24 H.29 · Lucía |
| V_BENCHMARK_HISTORICO | ¿Cuál fue nuestra mejor semana/mes y qué condiciones existían? | métrica · mejor_valor · fecha_mejor · contexto · valor_actual | Semanal | H.26 H.28 · Lucía |
| V_EXPERIMENTOS | ¿Qué experimento ganó, contra qué benchmark, y qué aprendimos? | experimento_id · hipótesis · variable · campaña · métricas por etapa (impresiones→ROI) · benchmark · resultado | Por sprint | I.19 · Mateo |
| V_META_ADS_DESEMPENO | ¿Qué anuncio está rindiendo y cuál se degrada? | campaña · adset · ad · gasto · cpl · ctr · registros · por día | Diaria | I.3 H.12 H.27 I.26 · Mateo Diego Lucía |
| V_PERFIL_CIERRE | ¿Qué perfil de prospecto llega hasta el cierre, por producto? | producto/campaña · edad · ocupación · dispositivo · hora_interacción · etapa_alcanzada · cerró | Mensual | I.26 · Mateo |
| V_CLIENTES_CROSSSELL | ¿A qué cliente de ahorro le ofrezco Vida, y por qué señal? | cliente · productos_actuales · perfil · señal_crosssell · prioridad | Semanal | Flujo 5 · Tito Tomás |
| V_ASESORES_ACTIVIDAD | ¿Qué asesor lleva más de una semana sin actividad? | asesor · última_cita_agendada · último_prospecto · días_inactivo | Diaria | D.4 · Diego |
| Vista | Pregunta de negocio | Contrato propuesto (campos clave) | Frescura | Act. · Agente |
|---|---|---|---|---|
| V_COBRANZA_PENDIENTES | ¿Qué cobros fallidos, próximos cargos y no-emisiones hay que atender hoy? | item_id · cliente · póliza · asesor · tipo (cobro_fallido/no_emisión/próximo_cargo) · motivo_exacto · próxima_fecha_cargo · días_atraso · prioridad | Diaria | E.5 E.6 M.6 · Nora Audit |
| V_TRAMITES_AUTORIZACION | ¿Qué solicitud lleva más de 5 días atorada en autorización? | solicitud_id · cliente · estatus · días_en_autorización · próxima_acción · fuente | Diaria | F.1 F.5 · Nora |
| V_TICKETS_ALLIANZ | ¿Qué ticket de Allianz amerita correo de presión? | ticket_id · buzón (cliente/endosos) · fecha_envío · días_sin_respuesta · evidencias_uri · estatus | Diaria | F.6 · Nora |
| V_POLIZAS_RENOVACION | ¿Qué renovaciones de Vida, GMMI y Auto vienen a 60/30/15 días? | póliza · ramo · cliente · asesor · días_para_renovar · estatus_gestión | Diaria | M.2 · Nora |
| V_CONCILIACION_CARTERA | ¿La cartera real de Allianz coincide con el control interno? | periodo · póliza · en_allianz · en_control · diferencia | Semanal | M.1 · Audit |
| V_CONSTANCIAS_FISCALES | ¿A qué cliente PLUS Art. 151 / GMMI le falta CSF o constancia con RFC correcto? | cliente · tipo (CSF/retención) · ventana · presente · rfc_correcto · asesor | Por ventana (oct-nov · feb-mar) | M.7 · Audit |
| V_EXPEDIENTES_INCOMPLETOS | ¿Qué expediente sigue incompleto y de quién es? | persona/póliza · faltante (contrato/CSF/documentación) · responsable · días_abierto | Diaria | L.6 · Audit |
| V_RECLUTA_PIPELINE | ¿El pipeline de recluta va en tiempo (Entrevista 1, 2, Chally)? | candidato_id · origen · etapa · fechas · resultado · completitud_registro | Diaria | M.5 · Audit |
| V_COBRANZA_KPIS | ¿Cobranza está en meta (cartera vencida, gestión > 30 días)? | periodo · gestora · cartera_vencida_pct · clientes_30d_gestionados · kpis vs meta | Quincenal | M.6 · Audit |
| Vista | Pregunta de negocio | Contrato propuesto (campos clave) | Frescura | Act. · Agente |
|---|---|---|---|---|
| V_DOCUMENTOS_CATALOGO | ¿Cuál es la versión vigente de cada documento y dónde vive? | document_id · tipo · nombre · storage_uri · versión_vigente · checksum | Diaria | I.9 K.7 L.6 B.5 · Renata Audit Tito |
| V_SOPS_INDICE | ¿Qué SOP/Loom responde esta duda, y en qué minuto? | sop_id · título · loom_url · tema · timestamp_relevante · resumen | Semanal | K.4 F.8 B.3 B.4 K.1 · Renata Sage |
| V_MENSAJES_GANADORES | ¿Qué mensaje ya ganó un A/B en este contexto? | mensaje_id · contexto · secuencia · métrica_mejorada · fecha · texto | Continua | I.16 · Mateo |
| V_VENTAS_SEMANA | ¿Qué ventas cerró la semana y dónde está su grabación? | venta_id · asesor · cliente · producto · fecha · zoom_recording_uri | 2×/semana | K.6 · Sage |
| V_LANZAMIENTOS_TABLERO | ¿Qué lanzamiento está en riesgo por tareas atrasadas? | lanzamiento · tareas · responsables · fechas · dependencias · atrasos | Continua | H.14 I.19 · Ana Mateo |
Cinco fuentes que las 63 actividades necesitan y que hoy no están en las rutas de ingesta del plan de Nyvia. HAILO las levanta como pedidos en la carpeta 03 durante la semana 1:
El dato fluye en los dos sentidos. Todo lo que los agentes producen entra por la puerta de ingesta en JSONL, con manifiesto por carga, y Nyvia lo integra a las vistas:
raw/hailo/paula/ — toques, confirmaciones, reagendas, rescatesraw/hailo/carla/ — avisos, cortes aprobados, Vobosraw/hailo/sage/ — análisis de sesión por reuniónraw/hailo/mateo/ — variaciones, resultados A/B, competenciaraw/hailo/pulso/ — autorizaciones y cancelaciones estructuradas de gruposraw/hailo/audit/ · raw/hailo/sofia/ — hallazgos y bitácoras de calidadDía 0: lunes 3 de agosto de 2026. Cada ola entrega valor y no espera a la siguiente. Empezamos por Comisiones a propósito: si algo del modelo no funciona, se sabe en el mes 1 sobre el flujo más difícil, no en el mes 12 sobre todos. HAILO construye cada agente una ola detrás de las vistas de Nyvia — el desfase es deliberado.
snowflake.query + registro del catálogo. Motor de Vobo (Slack/WhatsApp) y guardrails base. Carla en desarrollo contra el contrato de vistas.Cuatro organizaciones trabajando en paralelo (Nyvia, HAILO, PIMSA y la fábrica de software del sistema interno), una sola responsable por cada cosa. Nadie necesita el visto bueno de otro para trabajar.
Agenda fija de tres puntos: qué vistas se liberaron esta semana, qué necesita HAILO para la siguiente, qué está bloqueado. Sin presentaciones. Participan Néstor (Nyvia) y el owner técnico de HAILO.
Estatus por ola, riesgos abiertos y decisiones que requieren a dirección. Es donde PIMSA prioriza — no donde se aprueba trabajo.
Demo de lo construido, revisión de criterios de aceptación y firma conjunta. Se documenta qué quedó fuera y por qué.
Un solo grupo con las tres organizaciones. Si algo se atora más de 48 h, se escala ahí — no se espera al sync del martes.
Contrato de campos, tipos, frescura declarada y un ejemplo de consulta que funciona. Vive en el catálogo.
No basta con que exista: alguien de HAILO se conectó, consultó y confirmó que obtiene lo que su agente necesita.
Ricardo para comisiones, Paola para cobranza, Josma para funnel. Contra su realidad, no contra el documento.
Incluido lo que quedó fuera y por qué. Ninguna ola se cierra unilateralmente: la confirman las tres organizaciones.
Acuerdos y alcance (contratos, frontera técnica, actas) · Arquitectura y contrato de interfaz (diagramas, zonas S3, política de escritura) · Ontología y modelo de datos (las 18 entidades, versionado por ola).
Catálogo de vistas — el menú de HAILO, una ficha por vista · Calendario y bitácora (plan de 13 semanas vivo) · Accesos e interlocutores (quién es dueño de qué acceso; nunca credenciales — esas viven en Secrets Manager).
Riesgos y decisiones (fecha, decisión, por qué, quién) · Entregables por ola con criterios firmados · Sesiones (notas y grabaciones de cada sync, revisión y cierre).
Cada agente de HAILO opera con su propia credencial de Snowflake, nombrada, con permisos granulares. Si algo falla, se sabe exactamente cuál fue.
PIMSA maneja datos personales, fiscales, financieros y de salud bajo LFPDPPP y CNSF. Lo sensible se segrega del lado de la capa; los agentes consultan vistas ya filtradas con lo mínimo necesario.
El modelo de aprobación humana del diagnóstico se mantiene: nada se manda a Allianz, ningún corte se aplica y ninguna captura sensible al CRM ocurre sin visto bueno. Quién consultó qué y cuándo queda registrado.
El equipo de PIMSA habla con Hugo, Tomás y Olivia por WhatsApp, con voz clonada. Telegram es el puente de transición durante el arranque.
pimsa.hailo.mx — acceso con la cuenta Microsoft empresarial. Los tableros de Camilo, Lucía y Valeria viven ahí.
Una conversación, una respuesta: los 15 especialistas trabajan detrás de los 3 orquestadores.
Humanos en estrategia y excepciones; agentes en ejecución repetitiva y consolidación analítica. Fase por fase hasta la operación híbrida total.
Ninguno es sorpresa: todos vienen del diagnóstico y todos tienen dueño desde hoy.
| Riesgo | Impacto | Cómo lo manejamos | Quién vigila |
|---|---|---|---|
| Provisión de accesos y cuentas | Alto | Snowflake tarda ~2 semanas. Se arranca el día 1 en paralelo, con un responsable único de accesos por organización. | PIMSA |
| Extracción de Allianz (sin API) | Alto | Prueba de concepto en las semanas 1–2. Plan B: parsear el correo de control. Trámites y cobranza quedan en la Ola 4 por esto. | Nyvia |
| Profundidad de las reglas de comisiones | Alto | Por eso Comisiones va primero: splits, bonos y cancelaciones se validan con Ricardo antes de modelar nada más. | Nyvia + PIMSA |
| Calidad e identidad del dato | Medio-alto | Cinco formatos de póliza, teléfono sin normalizar, 34% de las filas de Vida sin asesor. Normalización desde el día 1 y zona de rechazos. | Nyvia |
| Agentes construidos antes de que exista la vista | Medio | El desfase del mes 1 es deliberado. El catálogo dice en todo momento qué ya se puede consumir y qué no; HAILO desarrolla contra el contrato y prueba contra la vista real. | HAILO + Nyvia |
| Alucinación al escalar el número de agentes | Medio | Agentes específicos con pocas tareas, guardrails por llamada y trazabilidad (LangGraph/LangSmith). Se prueba con casos reales antes de tocar comisiones o clientes. | HAILO |
| Tres proveedores construyendo en paralelo | Medio | La fábrica de software construye el sistema interno nuevo integrado a la base desde el diseño. La carpeta y el sync evitan trabajo duplicado. | PIMSA |
| Costo de consulta en Snowflake | Bajo | Warehouse X-Small con auto-suspend a 60 s, Resource Monitor con alertas al 50/75/90% y vistas materializadas para las lecturas frecuentes (dashboard de Camilo). HAILO agrupa consultas por diseño. | Nyvia + HAILO |
El cimiento no es de Nyvia ni de HAILO: es de PIMSA. Nyvia lo construye, HAILO construye encima, y en octubre queda documentado y en su cuenta — sin cajas negras y sin candados.