INITE Protocol: las 6 etapas aplicadas en un deploy real del Q2-2026, con los artefactos de cada paso

Qué es este post y qué no es

El INITE Protocol es la metodología de 6 etapas detrás de cada deploy B2B SME que entrega INITE AI. Break, Hold, Track, Cut, Cast, Form. Los nombres son etiquetas de etapa y la mayoría de los lectores puede adivinar el sentido por la palabra. Lo que es más difícil de transmitir - y lo que cualquier overview de metodología con sabor a consultoría omite - es qué hace el equipo realmente en cada etapa, qué artefactos salen y qué decisiones se toman.

Este post llena ese vacío. Recorre un deploy real del Q2-2026 en una firma de servicios profesionales de 60 personas (anonimizado; sector, escala y patrón de proceso preservados; nombres y números específicos removidos donde el contrato lo exige). El deploy entregó 2 workflows en producción en 19 días corridos desde el kick-off. La proyección de ROI a 12 meses es +$340K contra un costo total de construcción de $74K. El equipo usa los workflows diariamente y no nos ha pedido que volvamos - que es el objetivo.

Cada artefacto descrito abajo es un entregable real de un engagement real. El protocolo en sí está documentado en lib/brand-canonical.ts (whatShipped), locales/<lang>/common/protocol.json, y el JSON-LD HowTo en components/StructuredData.tsx. Los números de prueba (40-60% de eficiencia, ROI de 3-6 meses, 50+ empresas, 200+ workflows) son el agregado reportado por la empresa en todos los engagements.

Etapa 1 - Break (Semana 1-2): Diagnosticar y Resetear

La etapa Break responde una pregunta: ¿hay aquí un proceso cuya matemática de automatización sobreviva al escrutinio? Si sí, seguimos. Si no, terminamos el engagement y reembolsamos el depósito del diagnóstico.

Qué hacemos. Entrevistas con stakeholders (CEO, COO, 1-2 operadores de frente - en este caso el socio que lleva la práctica, la office manager y 2 consultores sénior). Observación del proceso - acompañamos el trabajo real por 4-8 horas por workflow objetivo. Pull de datos - ingestamos 90 días de datos operativos de los sistemas existentes (CRM, herramienta de proyecto, billing, time tracking). Medición de baseline - instrumentamos el proceso actual con timing, throughput y conteos de error.

Artefactos producidos.

1. Mapa de proceso con marcadores de cuello de botella. Un diagrama swimlane de cada paso en el workflow objetivo, con throughput cuantificado, tasa de error y tiempo de ciclo en cada handoff. Para este deploy mapeamos 3 workflows candidatos: (a) calificación de leads entrantes (tiempo de ciclo mediano 38 horas, 24% de drop-off), (b) comunicaciones de status de proyecto (4,5 horas/semana por consultor, 12 consultores), (c) conciliación de invoice/time-entry (8 horas/semana, 22% de tasa de error).
2. Reporte de costo-del-caos. El valor en dólares de las horas perdidas por semana en retrabajo manual, handoffs perdidos y espera. Para este deploy el costo-del-caos fue $11.200/semana en los 3 workflows candidatos - el número contra el cual se mide el ROI después.
3. Matriz de prioridad. Cada workflow candidato puntuado en viabilidad de automatización (técnica, 0-100) × ROI (negocio, 0-100). La parte alta de la matriz es lo que se construye en Cast; la baja es explícitamente diferida. La matriz de abajo es la real (números preservados).

El tercer workflow no se construye en este engagement. Queda documentado como candidato de follow-up para un ciclo futuro, pero solo después de que la etapa Hold limpie los problemas de calidad de datos que lo hacen tanto menos viable como menos ROI hoy. El diferimiento honesto es parte de la metodología - no empaquetamos el malo para hacer el engagement más grande.

Decisión al final de Break. Costo-del-caos $11.200/semana → anualizado $560K → top 2 workflows estimados en recuperar 50-60% de eso = $280-340K/año. Costo de construcción estimado en $74K total a lo largo de 12 meses (ingeniería + monitoreo + tuning). Estimación conservadora de ROI: +$200K en año 1, payback en mes 4. Decisión: avanzar a Hold.

Cerca de 1 de cada 3 de nuestros engagements de Break termina con la decisión de no proceder. El diagnóstico no encuentra candidato donde la matemática conservadora de ROI sea positiva. Reembolsamos el depósito y escribimos las razones. Esto suena a frase de marketing; en la práctica es la regla que mantiene honesto al resto de la metodología.

Etapa 2 - Hold (Semana 2-3): Estabilizar y Arreglar

La etapa Hold responde: ¿se puede automatizar el proceso objetivo en su estado actual o necesita estabilización primero? Automatizar el caos es la forma más cara de hacer que sistemas lentos sigan siendo lentos para siempre; esta etapa detiene eso.

Qué hacemos. Para cada workflow que se construirá en Cast, identificamos las fuentes de datos upstream, reglas de validación y puntos de handoff que tienen que ser confiables para que la automatización funcione. Arreglamos los rotos. Documentamos los SOPs (procedimientos operativos estándar) para las versiones manuales de los pasos que permanecerán humanos - porque el nuevo workflow automatizado igual hará handoff a humanos en los bordes, y el lado humano tiene que ser consistente.

Artefactos producidos.

1. SOPs para workflows clave. Para este deploy: las reglas de triaje de email para leads entrantes (qué cuenta como lead calificado, qué se escala, qué se descarta - escrito por primera vez); la plantilla de actualización de status que el equipo venía improvisando; los requisitos de campos de datos para el CRM (cuáles son obligatorios al capturar el lead vs en la conversión).
2. Correcciones de calidad de datos. El CRM tenía tres valores de lead-source donde debería haber uno ("website", "web", "Website"). Los colapsamos. La herramienta de proyecto tenía 4 valores de status activos cuando el equipo solo usaba 3. Quitamos el muerto. El inbox de email tenía 14 reglas acretadas en 5 años, mitad muertas. Podamos a 6 reglas activas.
3. Correcciones manuales rápidas que ahorran tiempo inmediatamente. Dos de los cuellos de botella en el workflow de calificación de leads resultaron ser arreglables sin nada de AI - uno era una regla de reenvío de email que rutaba leads a un auto-responder de vacaciones; el otro era un bug de campo obligatorio en el CRM que forzaba a los consultores a reingresar los mismos datos dos veces. Ambos arreglados en Hold, antes de que comenzara Cast. Los ahorros de tiempo solo de Hold sumaron cerca de 6 horas/semana en el equipo - una victoria pequeña pero medible antes de que se entregara cualquier automatización.

Hold es la etapa que la mayoría de las metodologías de "piloto AI" se saltan, y es la etapa que determina si el eventual workflow Cast tendrá inputs estables contra los cuales trabajar. Un workflow conducido por LLM que recibe valores de lead-source inconsistentes, valores de status ambiguos y emails ruteados al inbox equivocado producirá basura y el equipo culpará al AI. La etapa Hold asegura que el sustrato esté limpio.

Etapa 3 - Track (Semana 3-4): Medir y Analizar

La etapa Track responde: ¿cómo se ve realmente el proceso en producción instrumentada, no en el mapa basado en entrevistas que dibujamos en Break?

Qué hacemos. Instrumentamos cada paso del workflow con logging de eventos con timestamp - típicamente un middleware liviano que registra eventos del proceso (lead recibido, lead calificado, lead convertido, actualización de status enviada, etc.) con timing, identidad y desenlace. Recolectamos 2-3 semanas de datos sobre el proceso ahora-estabilizado de Hold. Encontramos patrones que el mapa estático perdió.

Artefactos producidos.

1. Dashboard de KPI (métricas en vivo). Un dashboard en tiempo real de los KPIs por workflow que se rastrearán a través de Cast y Form. Para este deploy: tiempo de ciclo por workflow, throughput por consultor, tasa de intervención (con qué frecuencia el operador sobre-escribe una decisión automatizada) y tasa de error. El dashboard se enciende en Track y queda encendido en todas las etapas subsecuentes - el equipo lo ve a diario.
2. Reporte de análisis de patrones. Los hallazgos no-obvios de los datos instrumentados. Para este deploy, tres hallazgos se destacaron. (a) 31% de los leads entrantes llegaban entre las 18h y las 8h hora local - el workflow manual no tenía a nadie en turno entonces y esos leads quedaban 12-16 horas antes de la primera respuesta (un hecho que el equipo no había medido porque nadie estaba mirando fuera de horario). (b) Las actualizaciones de status eran 2,3x más largas cuando se escribían entre las 16-18h los viernes que en otros momentos - sospechamos fatiga de apuro; la automatización puede normalizar esto. (c) Los consultores que escribían las actualizaciones más largas tenían las notas más altas de satisfacción del cliente - no deberíamos automatizarlos a la brevedad ciegamente; la calidad de forma larga es una feature.
3. Puntuaciones de viabilidad de automatización por paso del proceso. Una evaluación línea por línea de qué pasos en cada workflow son buenos candidatos a automatización (alto volumen, inputs bien definidos, criterios de éxito claros) vs cuáles deben quedar humanos (bajo volumen, inputs ambiguos, juicios). Para este deploy, la calificación de leads puntuó 82/100 (altamente automatizable), la generación del primer borrador de actualización de status puntuó 76/100 (automatizable con revisión human-in-loop), y el envío final orientado al cliente puntuó 38/100 (debe quedar humano, incluso después de borradores AI).

Track es lo que convierte la hipótesis de la etapa Break ("este proceso se ve lento y propenso a errores") en especificación de la etapa Cast ("este workflow tiene estos cuellos específicos en estos pasos específicos, con esta forma de datos específica"). Un equipo que se salta Track entrega un Cast que arregla la cosa equivocada.

Etapa 4 - Cut (Mes 2): Simplificar y Eliminar

La etapa Cut responde: ¿qué pasos en el proceso no deberían existir en absoluto, antes de que cualquiera de ellos se automatice?

Qué hacemos. Tomamos el mapa de proceso ahora-instrumentado de Track y caminamos paso a paso. Para cada paso, preguntamos: ¿este paso agrega valor, o es tejido cicatricial de un problema que ya no existe? Eliminamos los que no agregan. Fusionamos pasos duplicados. Reordenamos pasos donde el orden es arbitrario. Preparamos el proceso limpio como especificación para Cast.

Artefactos producidos.

1. Flujos de proceso enjutos. La versión limpia de cada workflow objetivo, lista para automatización. Para este deploy, el workflow de calificación de leads pasó de 11 pasos a 6. Cinco pasos eliminados: una entrada de datos duplicada (el CRM se actualizaba dos veces por razones de compatibilidad legacy que ya no eran ciertas hacía 18 meses), una aprobación redundante de gerente (añadida durante un problema de calidad anterior que se había resuelto), dos emails de seguimiento de status que nadie leía (medimos open rates - 4% y 7%), y una exportación manual de datos que alimentaba un reporte que nadie corría ya.
2. Pasos redundantes eliminados - conteo y categorías. A lo largo de los 2 workflows objetivo, 9 pasos eliminados de 22 - 41%. La mediana de eliminación en la etapa Cut en nuestros deploys es 30-40%; este engagement quedó en la parte alta porque la firma no había hecho una revisión de procesos en 4 años y el tejido cicatricial se había acumulado. Categorías: 4 entradas de datos duplicadas, 2 aprobaciones redundantes, 2 notificaciones muertas, 1 alimentación manual a un reporte muerto.
3. Especificaciones listas para automatización. Para cada paso que permanece y va a automatizarse, una spec escrita - forma de datos de entrada, criterios de éxito, manejo de errores, camino de escalación, métricas de monitoreo. Ese es el artefacto contra el cual construye Cast. Para el workflow de calificación de leads, la spec tiene 11 páginas. Para el workflow de actualizaciones de status, la spec tiene 7 páginas. Las specs escritas previenen el modo de falla más común de Cast, que es el equipo de ingeniería construyendo algo que no calza con lo que el equipo de operaciones acordó en Track.

Cut es la etapa que la mayoría de las iniciativas "vamos a agregar AI" lideradas por CTO se saltan porque nadie quiere pelear con el equipo sobre eliminar su paso de estimación. Peleamos. La matemática gana; las decisiones de eliminación se escriben con el volumen por paso de Track anexado como evidencia. Un equipo que no Corta termina automatizando el caos y bloqueándolo.

Etapa 5 - Cast (Mes 2-3): Construir e Implementar

La etapa Cast responde: ¿los workflows especificados se despliegan a producción y sobreviven al contacto con usuarios reales?

Qué hacemos. Construimos cada workflow contra la especificación congelada en Cut. Desplegamos a producción - no un entorno de demo, no un sandbox, el entorno real con los usuarios reales. Cableamos monitoreo antes del lanzamiento. Integramos con las herramientas existentes que el equipo ya usa - el CRM, el inbox, la herramienta de proyecto - en lugar de reemplazarlas.

Para deploys que se sientan sobre el ecosystem Inite (ver el post compañero sobre el runtime compartido @inite/*), la etapa Cast reusa @inite/assistant para el runner LLM, @inite/inbox para cualquier superficie de conversación, @inite/api-kit para el patrón de wrapper de request, @inite/incidents para el camino de escalación human-in-loop, y @inite/security para enmascarado de PII en el audit log. La infraestructura reusada comprime Cast de "construir todo" a "configurar la mayor parte y escribir la lógica de dominio". Para este deploy, el workflow de calificación de leads se entregó en 8 días corridos de spec congelada a leads reales en vivo.

Artefactos producidos.

1. 1-3 workflows automatizados en producción. Para este deploy: (a) workflow de calificación de leads en vivo en CRM + inbox de email - 100% de los leads entrantes ahora fluyen por el triaje AI, con operator-override disponible en cualquier paso; (b) workflow de actualización de status de proyecto en vivo en la herramienta de proyecto + email - genera borradores de actualización que el consultor revisa y envía. Ambos workflows entraron a producción en 14 días corridos desde el inicio de Cast.
2. Integración con las herramientas existentes de la firma. Sin nuevo dashboard para que el equipo aprenda. El workflow de leads aparece como reglas de automatización y comentarios generados por AI dentro del CRM existente. El workflow de actualización de status aparece como borradores en el flujo de email-compose existente. Las herramientas diarias del equipo no cambian; el AI es plomería invisible adentro de ellas. La adopción es el asesino silencioso de los pilotos; construir dentro del set de herramientas existente del equipo es como Cast lo evita. Usamos el patrón de registry de herramientas de @inite/assistant para exponer los workflows a cualquier agente que necesite llamarlos - incluyendo los agentes MCP-compatibles que el CTO de la firma usa para code review.
3. Entrenamiento del equipo y handover. Una sesión en vivo de 90 minutos por workflow con el equipo que lo operará, más un runbook escrito (3-5 páginas) por workflow cubriendo: cómo corre el workflow normalmente, qué métricas de monitoreo mirar, qué hacer cuando dispara una alerta, quién dentro es dueño del workflow, cómo escalar a nosotros. El runbook es el puente a Form.

Cast es también donde los chequeos de preparación para agentes de navegador se aplican a cualquier superficie orientada al operador que el workflow expone - porque si un agente AI va a manejar las herramientas de la firma para ayudar a humanos, las herramientas mismas tienen que ser legibles por agentes. Este es un detalle pequeño pero cada vez más importante en los deploys de 2026.

Etapa 6 - Form (Mes 3-6): Optimizar y Escalar

La etapa Form responde: ¿el workflow desplegado sobrevive 12 meses de uso real, y el equipo acumula una capacidad en lugar de recibir un proyecto puntual?

Qué hacemos. Vemos el tráfico de producción los primeros 90 días. Ajustamos el workflow contra datos reales, no asumidos. Escalamos a workflows adicionales en la misma plataforma. Pasamos la propiedad operativa a un dueño interno identificado.

Artefactos producidos.

1. Dashboard de monitoreo de performance. El dashboard de KPI de Track, ahora cableado a los workflows de producción y mirado a diario por el dueño interno. Para este deploy, métricas de la semana 12: tiempo de ciclo de calificación de leads bajó de 38 horas a 1,4 horas (reducción de 96%), tasa de drop-off de 24% a 9%; tiempo de consultor para actualización de status de 4,5 horas/semana a 0,8 horas/semana (reducción de 82%), nota de satisfacción de consultor (Likert 1-5) subió de 3,1 a 4,4. La reivindicación de 40-60% de eficiencia en el protocolo se sostiene - este deploy está en la parte alta.
2. Optimización con base en datos de uso real. 4 rondas de tuning en los primeros 90 días. Ronda 1 (semana 3): el AI era demasiado agresivo al clasificar leads borderline como no calificados - ajustamos el threshold y la tasa de falso-negativo cayó de 11% a 3%. Ronda 2 (semana 6): los borradores de actualización de status estaban demasiado genéricos - agregamos retrieval de contexto por cliente de la herramienta de proyecto. Ronda 3 (semana 9): el camino de escalación estaba demasiado ruidoso - agregamos un gate de threshold de confianza. Ronda 4 (semana 12): el patrón de override del consultor mostró que 3 tipos específicos de lead nunca deben auto-calificar - los agregamos como reglas duras. El tuning no es opcional; es lo que hace que el workflow sea bueno en lugar de funcional.
3. Plan de escala para la próxima ola de automatización. Con la plataforma viva, el ancho de banda del equipo se abre. Documentamos 4 candidatos de follow-on para el próximo ciclo: el workflow de conciliación de invoice/time diferido en Break (ahora viable porque Hold limpió los datos); una automatización de client-onboarding; un asistente de redacción de propuestas; una automatización de quarterly-business-review. Cada uno puntuado en la misma matriz viabilidad × ROI usada en Break. La firma eligió 2 para correr en Q3-2026; los estamos scopeando como un engagement separado.

El handover es la parte más difícil de Form. El dueño interno recibe acceso root a la config del workflow, al dashboard de monitoreo, al registry de prompts y al runbook de escalación. Quedamos disponibles en check-in trimestral el primer año, pero la responsabilidad operativa es de ellos. Los workflows sin un dueño interno identificado con presupuesto para tuning son los que silenciosamente se apagan en 6 meses. Rehusamos entregar Cast sin Form, y rehusamos llamar Form completo sin el dueño interno.

Cuánto costó el deploy y qué produjo

Los números son reales para este deploy específico. El agregado de los 200+ workflows que hemos entregado en 50+ empresas se sienta en la banda de 40-60% de aumento de productividad y payback de 3-6 meses. Engagements individuales varían arriba y abajo; este quedó en la parte alta porque la firma venía corriendo los procesos manuales por 4+ años y la etapa Cut encontró tejido cicatricial inusualmente alto.

Qué es el protocolo en una frase

El INITE Protocol es como se ve una metodología cuando se construye al revés desde la pregunta "¿el workflow sobrevivió 12 meses de uso real?". Break / Hold / Track aseguran que la matemática es real. Cut asegura que el sustrato vale ser automatizado. Cast entrega software grado-producción contra un proceso limpio. Form hace que el cambio pegue. Saltarse cualquiera de las seis es como muere el dinero de la consultoría AI. Seguir las seis es como 200+ workflows en 50+ empresas siguen corriendo después de que nos vamos.

Si tu matemática sobrevivió en Break, tu equipo es dueño de Form. Todo lo del medio es ingeniería.