Una fuerza laboral híbrida: los agentes ejecutan, las personas dirigen. La Fase 0 prueba los cimientos con datos reales de Nutreo en dos POCs paralelos — el de mercadeo y el de I+D.
Un sistema de playbooks — procesos repetibles, hipótesis validables.
Primer experimento: convertir un grupo curado de leads de alto valor (seleccionados por mercadeo) en primeras reuniones — el cómo se define con el equipo.
De un brief a una formulación.
Construir la fábrica de conocimiento gobernado (materia prima · regulatorio · tablas nutricionales) y validarla generando la ficha desde un brief real.
Detrás de los dos: el mismo conocimiento gobernado y las mismas capacidades reusables.
Lo que queremos: un sistema donde mercadeo pueda plantear una hipótesis, ejecutarla como un proceso, medir si funciona, y si funciona, replicarla con variaciones.
Lo que no tenemos hoy: una forma estructurada de saber qué acciones de mercadeo realmente generan resultado. Cada esfuerzo es distinto, lo que se aprende en uno raramente alimenta al siguiente.
Definir cómo se ve un «playbook» en este sistema —qué partes lo componen, cómo se ejecuta, cómo se mide y cómo se replica— es parte del POC. La primera implementación es el experimento sobre el cual aprendemos.
Como punto de partida, el sistema corre un playbook con esta intención: convertir un grupo curado de leads de alto valor —seleccionados por mercadeo, no listas masivas— en primeras reuniones.
El cómo —qué pasos, qué agentes, qué señales para medir si está funcionando— se define con el equipo de mercadeo. Sale un primer diseño, se prueba sobre 10–20 leads, se mide, se ajusta. Resultados claros al final.
El conocimiento que la POC #2 construye —materia prima curada, marco regulatorio, tablas nutricionales— lo lee también la POC #1: un asset de mercadeo puede citar una propiedad bioactiva real, o verificar que un claim cumple con Res 810. Una sola fábrica de conocimiento alimenta los dos frentes.
Hoy: ~44 herramientas con bases desarticuladas; la formulación se hace a mano en Excel.
El POC no resuelve los 44 sistemas. Prueba la disciplina de conocimiento gobernado sobre una rebanada pequeña —una familia de producto, ~100 materias primas, regulación Colombia— y la valida con una ficha técnica que el formulador firma.
| Tipo | Hace | Ejemplos | Postura de gobierno |
|---|---|---|---|
retrieveget / search / query | Lee una base de conocimiento. Solo lectura, determinista, sin LLM. | get_persona · get_value_prop · query_materia_prima · search_regulatorio | Filtro de zona al leer. Sin compuerta. |
computecompute / check / score | Deriva hechos de forma determinista. Sin LLM. Reproducible re-ejecutando. | compute_perfil_nutricional · check_claims | Auditable re-corriéndola. El resultado se ve en la siguiente compuerta del flujo. |
generatedraft / propose / compose / generate | Redacta un artefacto con LLM. Nunca queda final. | draft_account_brief · propose_formulacion · compose_asset · generate_ficha_tecnica | Siempre a una compuerta humana. Siempre con citas. Filtro de zona sobre lo que recibió. |
Regla: get/search/query → lo leí. compute/check/score → lo calculé. draft/propose/compose/generate → lo escribí, tú decides.
| Agente | V1 |
|---|---|
| ingestión de leads · clasificación en personas | ✓ |
| matching con propuestas de valor | ✓ |
| composición de contenido (LinkedIn · correo · ...) | ✓ |
| tracking de respuesta (LinkedIn · correo) | ✓ |
| scoring de warmth · briefing de handoff | ✓ |
| recomendar calentamiento | asesor |
| calentamiento automatizado | V2 |
| discovery de leads a escala | V2 |
| envío automático multicanal | V2 |
| Agente | V1 |
|---|---|
| parsear brief · validar completitud | ✓ |
| matcher de MP · proponer formulación | ✓ |
| cómputo nutricional · de costo (determinista) | ✓ |
| Stage Gate 1 · pre-check regulatorio (CO) | ✓ |
| drafter de ficha técnica · versionado | ✓ |
| ingestor automatizado de MP a escala | V2 |
| generador de documentos regulatorios | V2 |
| multi-jurisdicción (RD · Perú · USA · RTCA) | V2 |
Cada agente compone capacidades del catálogo (ver anexo «Capacidades»). Para POC #1 esta es la lista anticipada — el catálogo final se define con mercadeo a medida que el sistema descubre qué necesita el playbook. Lo marcado «V2» queda fuera del alcance V1.
El conocimiento es lo que está bajo gobierno. Importa más poder verlo, compararlo y revertirlo —como un documento con todo su historial— que la escala o la concurrencia. Cuando esas cosas hagan falta (Fase 1+), los esquemas ya existen y migran a una base de datos servidor.
| Opción | Buena para | Costo |
|---|---|---|
| Base relacional / Postgres | Transacciones, joins, multiusuario | Infraestructura que operar; el esquema vive fuera del repositorio |
| Base vectorial dedicada | Búsqueda por significado a escala | Otro servicio; contenido opaco, difícil de auditar |
| Almacén de documentos | Datos flexibles sin forma fija | Esquema débil, comparación de versiones débil |
| Base de grafos | Consultas con muchas relaciones | Pesada para lo que la POC necesita |
| Archivos versionados + validación de esquema + índice de búsqueda embebido | Auditable, comparable, reversible; el esquema vive con el código; cero infraestructura; la compuerta de cambio es una revisión de código | Sin escritores concurrentes; escala limitada |