I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Puntos clave

1. Fecha / fuente. 12 de agosto de 2026, LinkedIn Pulse, newsletter Growth Marketing Fit, ~2.500 palabras. Sistema construido en Claude para un equipo de marketing de ~60 personas.
2. Enfoque clave. « Pensaba que estaba construyendo una máquina de contenido. Estaba construyendo una máquina de confianza, y no lo sabía, así que dediqué mi esfuerzo inicial exactamente al lugar equivocado. » ### Prohibir el « pass » desnudo Un verificador es un sistema de mundo cerrado: solo puede pronunciarse sobre lo que se le ha dado. Ante una afirmación que ninguna de sus fuentes cubre, no encuentra contradicción y devuelve un veredicto favorable indistinguible de una verificación real. La solución es una restricción de formato: | El informe debe indicar | Por qué | |---|---| | Cuántas afirmaciones se verificaron | denominador: sin él, un « OK » no significa nada | | Cuántas se relacionaron realmente con una fuente | esa es la tasa de cobertura real, siempre menor | | Cuáles quedaron fuera de su jurisdicción | de lo contrario el juez se extralimita y el silencio de otras afirmaciones pasa por acuerdo | | Cuáles no pertenecen a ninguna fuente del sistema | ese es el verdadero registro de riesgos de la organización | « No puedo verificar esto » debe ser un resultado de primera clase, al mismo nivel que « pass » y « fail ». El antipatrón simétrico es más peligroso que ninguna verificación en absoluto: « una buena revisión que no vale nada es mucho peor que ninguna revisión, porque blanquea la salida » — alguien más adelante ve reviewed: pass y deja de mirar. Referencia cruzada [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### La verificación que la revisión por activo individual no puede producir Dos activos de la misma campaña pueden ser cada uno individualmente correcto, cada uno trazable a una fuente real, cada uno validado — y aun así contradecirse entre sí. Verificar contra la capa de verdad y verificar activos entre sí son dos verificaciones distintas; la primera no puede producir la segunda. El diagnóstico del autor: « si ejecutas campañas multi-activo y solo verificas un activo a la vez, tienes este bug ahora mismo. » Transposición fuera del marketing: un PR que toca tres archivos, un conjunto de specs generado por lotes, un documento y su código producidos juntos. La coherencia cruzada es una verificación a nivel de bundle, nunca una suma de verificaciones unitarias. ### La capa de verdad Fallo relatado: los hechos del producto vivían dentro de la skill que escribía los artículos, y luego el mismo hecho tenía que existir en la skill de email, en la battlecard, en la página web. « En pocas semanas tenía cuatro versiones ligeramente distintas de nuestra fecha de lanzamiento en cuatro archivos distintos, y la deriva era invisible porque cada archivo era individualmente plausible. » Regla: « un documento que declara hechos y un documento que produce contenido son dos documentos distintos, con dos propietarios distintos », cada uno versionado y fechado. Nada que produzca contenido tiene permitido contener un hecho — tiene que solicitarlo. Beneficio: un hecho cambia, lo cambias una vez, las 35 skills son correctas al día siguiente; una afirmación se disputa, solo hay un lugar donde mirar. Por qué nadie la construye: « No puedes hacer una demo de una capa de verdad. Solo puedes hacer una demo de lo que evita, que no es nada visible. » Ejercicio propuesto: abrir los últimos cinco activos producidos, resaltar cada afirmación factual, nombrar para cada una el único documento propietario — « aquellas a las que no puedes asignar un propietario son tu verdadero registro de riesgos. » Extiende [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Dos lecciones sobre las skills 1. El contrato de salida tiene que ser paranoico con la ambigüedad. Durante semanas, la skill de « entrada de blog » escribió descripciones de artículos — encabezados de sección seguidos de una frase que explicaba lo que cubriría la sección, « absolutamente cada vez » — y superó todas las revisiones, porque la estructura era impecable. Causa: una línea ambigua en la plantilla (« la entrada, bajo los encabezados de sección propios del enfoque »), leída razonablemente como una solicitud de esquema. Detalle organizativo más importante que el bug: nadie lo señaló, « la gente asume que la herramienta tiene razón y que son ellos quienes la usan mal. » 2. El trabajo más importante de una skill es describir para qué no sirve. Pasadas unas treinta skills, el problema deja de ser calidad y pasa a ser enrutamiento: dos skills que ambas manejan de forma plausible « escríbeme algo para ventas » compiten por cada solicitud, y el ganador arbitrario produce el formato equivocado. La mitad de cada descripción se convirtió en un límite explícito. Comparar con [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Del prompt a la fontanería Las reglas de voz prohibían las rayas largas, cada prompt lo decía, los testers siguieron encontrándolas durante semanas: « seguía repitiendo la regla más fuerte, lo cual es una solución probabilística a un problema cuya solución determinista estaba justo ahí. » Solución: una única función del lado de la salida que las elimina. Heurística generalizable: « si te sorprendes repitiendo una instrucción, esa es la señal de sacarla del prompt y ponerla en la fontanería », con su corolario — « pedir amablemente no es un control. » ### El fallo silencioso Una constante destinada a contener un carácter marcador invisible se había vaciado a una cadena en blanco. Sin diff visible, sin error. Más adelante, un paso de limpieza empezó a hacer coincidir cada dígito de cada prompt y a eliminarlo: « 7,1% en más de 6.000 organizaciones, 2500 palabras » llegaba al modelo como « ,% en más de , organizaciones, palabras ». Cada estadística, fecha, recuento de palabras y número de sección se eliminó silenciosamente, durante un número desconocido de versiones. Esa era la verdadera razón por la que las cifras citadas seguían saliendo mal — « y había pasado semanas culpando a la tendencia del modelo a inventar números. Los inventaba porque yo los había eliminado. » Principio: « El software tradicional se cae cuando se rompe. Estos sistemas siguen funcionando, con confianza, con calidad reducida, y producen algo que parece correcto. » Dos soluciones: probar el pipeline, no solo la salida — una prueba cuya única función es verificar que los números sobreviven un recorrido de ida y vuelta por el ensamblaje del prompt; y recordar que la validación tiene los mismos huecos que el sistema — un campo limitado a 500 caracteres se quedó en 688 durante dos versiones porque el script verificaba todos los demás límites excepto ese. Regla de diagnóstico: antes de acusar a un modelo de inventar un número, verificar que el número realmente le llegó. ### Capa 4, distribución interna « Aquí es donde mueren en silencio la mayoría de los proyectos internos de IA. No por fallo técnico. Por ser técnicamente excelentes y ser usados por cuatro personas. » El autor había construido primero para sí mismo — un plugin que requería fluidez en línea de comandos, lo cual describía a seis personas de sesenta. Solución: el mismo sistema construido dos veces, el mismo conocimiento y las mismas verificaciones, dos puntos de entrada — un plugin para constructores, una aplicación de navegador para el resto (catálogo, tres campos, un borrador con sus verificaciones al lado como botones). El punto más fino de la sección: la adopción sigue a la confianza, no a la capacidad. La herramienta se usó más una vez que la salida empezó a admitir lo que no sabía con certeza — « Un borrador que marca "este ejemplo de cliente es ilustrativo, encuentra uno real antes de publicar" se usa. Un borrador que presenta con confianza un ejemplo de cliente inventado se usa una vez, avergüenza a alguien, y la herramienta muere por el boca a boca. » ### Enseñar al sistema a rechazar La última pieza adapta un activo para otro segmento de mercado y conoce el segmento que la empresa decidió no perseguir: al pedírsele ese segmento, se niega y explica por qué. « Mismo principio que la declaración de cobertura. Un sistema que solo puede decir que sí te entregará con confianza lo incorrecto para siempre, y no podrás distinguir "esto es correcto" de "esta era la única respuesta disponible". » Rechazar y admitir ignorancia son la misma primitiva: la capacidad del sistema de delimitar su propio dominio de competencia. ### Las tres incertidumbres que quedan abiertas 1. ¿Capa de verdad incrustada o recuperada en vivo? « Las copias incrustadas quedan obsoletas sin que nadie lo note. Las recuperaciones en vivo son lentas y se rompen cuando alguien renombra una carpeta. » El autor hace una mezcla y dice que no es razonada. 2. ¿El coste de verificación sigue siendo sostenible? Un activo completamente verificado cuesta « varias veces » un borrador en bruto: rentable para trabajo de cara al público, probablemente no para un resumen interno, « y la línea entre ambos es más difusa de lo que mi sistema afirma. » Variable de gobernanza a instrumentar primero: un nivel de verificación ligado a la criticidad del activo. 3. ¿Cuánto de esto sobrevive a las próximas dos generaciones de modelos? Su apuesta, presentada como tal: la capa de verdad y la disciplina de cobertura sobreviven, porque « resuelven un problema organizativo de procedencia y propiedad que existiría incluso con un modelo perfecto. » ### El plan « si empiezas el lunes » 1. Anotar los diez hechos que el equipo repite más, con un propietario y una fecha para cada uno — versión cero de la capa de verdad, « lleva una tarde. » 2. Tomar tu mejor prompt y extraer de él cada hecho hacia ese documento; hacer que el prompt los solicite. 3. Construir un paso de verificación que se ejecute en una sesión nueva, vea solo el borrador y las fuentes, y deba indicar lo que no pudo verificar. 4. Encontrar lo que se sigue repitiendo en los prompts y trasladarlo a código. 5. Mostrárselo a alguien no técnico y observar cómo lo usa sin ayuda. Prueba de referencia a ejecutar antes que nada: pasar un activo ya publicado por la verificación en una sesión completamente nueva, sin más contexto que el borrador y las fuentes. « Lo que sale es tu línea base de calidad real. Suele ser humillante. La mía lo fue. »