Cómo crear una startup nativa de IA

• Mientras la IA se encarga de tareas repetitivas durante la noche, surge un nuevo modelo operativo en el que los fundadores se enfocan en mejorar el producto; el cambio real no está en cómo se usa el tiempo, sino en la velocidad con la que la empresa aprende, itera y evoluciona
• En una empresa nativa de IA, cambia el propio modelo operativo: menos personas coordinan menos, los agentes ejecutan tareas repetitivas y los humanos se enfocan en dirección, criterio, relaciones, verificación y responsabilidad
• La transición avanza por etapas: mapear el trabajo, construir un sistema de contexto, elegir la automatización más simple, convertir el trabajo repetitivo en habilidades, escribir evals para juzgar la calidad y ejecutar un ciclo semanal de mejora
• Los modelos se reemplazan y mejoran cada mes, y además se parecen cada vez más entre sí; por eso, el activo propio de cada empresa es su sistema operativo, como el contexto y los evals
• En un entorno donde todos usan los mismos modelos, el verdadero foso es la disciplina, es decir, la constancia de mapear el trabajo cada semana, acumular contexto, escribir evals y hacer girar el ciclo

---

El contraste entre dos startups

• Comparación a las 9 a. m. de dos empresas fundadas el mismo mes en el mismo mercado
  • En la primera, la líder de operaciones procesa tickets de soporte acumulados, el analista rehace el dashboard de la semana pasada y el fundador está atrapado en la reunión diaria por una llamada con un cliente que nadie pudo resolver: todos están apagando los incendios de ayer y el producto está estancado
  • En la segunda, los agentes hicieron todo eso durante la noche: clasificación de tickets, actualización del dashboard y detección de riesgo de churn en las llamadas; el fundador ya está corrigiendo problemas y mejorando el producto con el equipo
• La diferencia clave es la velocidad de aprendizaje: la segunda empresa aprende más rápido cada día y ese apalancamiento se acumula con interés compuesto a lo largo de semanas, meses y años

Paso 1: mapear el trabajo (Map The Work)

• Enumerar todo el trabajo repetido durante las últimas 2 semanas: notas de llamadas con clientes, research de leads, borradores de outbound, clasificación de soporte, QA de producto, onboarding, release notes, actualizaciones para inversionistas, métricas semanales, reproducción de bugs, filtro de candidatos, revisión de facturas, monitoreo de competidores, etc.
  • Si se repite, es candidato a ser codificado; en la agenda de la mayoría de los fundadores ya hay entre 20 y 40 ítems
  • Si un equipo en etapa inicial hace la lista con honestidad, suele descubrir entre 10 y 15 tareas que ya eran rutina

• Clasificar por nivel de autonomía

  • L1 es solo para humanos: decisiones estratégicas, contratación final, reembolsos grandes, firmas legales, comunicación con el directorio
  • L2 es IA prepara y humano aprueba: borrador de actualizaciones para inversionistas, redlining de contratos, reescritura de la página de precios, macros de soporte
  • L3 es IA ejecuta y humano supervisa: clasificación de inbound, enrutamiento de notas de reuniones, enriquecimiento de leads, generación de tests
  • L4 es autónomo dentro de límites claros: monitoreo de competidores, generación de reportes nocturnos, extracción de facturas de proveedores conocidos, detección simple de anomalías

• Los flujos de trabajo aburridos suelen ganar

  • Más que tareas vistosas como un memo estratégico semanal, algo que se repite todos los días como el etiquetado de soporte se ejecuta 10 veces más, recupera más tiempo y genera datos de respuesta correctos y limpios: la frecuencia le gana al prestigio
  • Los primeros objetivos deben ser tareas frecuentes, medibles, reversibles y conectadas con un cuello de botella real

• Trabajo que no se debe automatizar

  • Se excluyen las tareas raras, ambiguas, que requieren alta confianza o que son inestables
  • El equipo de C.H. Robinson llevó la clasificación de 10 mil correos diarios a L4, pero volvió a L2 porque la supervisión se volvió imposible; el volumen ocultaba el costo de clasificar mal
  • Si no puedes explicar qué es un buen resultado, no está listo para codificarse; y si una sola salida errónea puede dañar una relación con un cliente, hay que avanzar despacio

• Configuración inicial

  • Empezar con 1 página y 3 flujos de trabajo: personal (clasificación de inbox, brief diario, borrador de actualización para inversionistas), de cara al cliente (resumen de llamadas, clasificación de tickets, enriquecimiento de leads), e interno (generación de tests, extracción de facturas, narrativa de métricas semanales)
  • Probar demasiadas cosas al mismo tiempo dispersa la atención y provoca el modo de falla más común: terminar con 20 pilotos inconclusos

Paso 2: construir el sistema de contexto (Build The Context System)

• El contexto es la memoria operativa de una startup nativa de IA: el lugar donde se guarda todo lo que la empresa sabe sobre sí misma para que los agentes puedan leerlo
  • Los modelos son reemplazables, pero el contexto es el verdadero activo propio de la empresa; es lo que distingue a un agente que trabaja como cofundador de uno que trabaja como un temporal desorientado
  • Si reescribir salidas toma más tiempo que revisarlas, el problema no es el prompt ni el modelo, sino que el agente no conoce suficientemente la empresa

• Método de diagnóstico semanal

  • Tomar una tarea representativa y dársela a un agente nuevo que solo tenga el contexto del workspace, y pedirle las siguientes 3 acciones
  • Si propone 2 o más sugerencias sólidas, el contexto está funcionando; si da 3 respuestas genéricas, el contexto es débil y ningún prompt lo va a rescatar

• Basado en un repositorio Git

  • Empezar con un único repositorio Git compartido que puedan leer todos los miembros del equipo y los agentes: tiene control de versiones, diff, es legible para humanos y agentes, y no depende del runtime de un proveedor específico
  • En el día 7, el workspace puede consistir en una sola raíz con CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md y GTD.md para el trabajo activo
  • Mantenerlo en 40 a 60 líneas escritas a mano; una lista densa de cosas a evitar supera a 400 líneas de texto generado y desordenado

• Dividir por límites de permisos

  • A medida que se crece, usar un repositorio compartido de empresa + repositorios privados por función (ventas, producto, ingeniería, finanzas, soporte), o repositorios privados por proyecto o cliente + una raíz compartida para toda la empresa
  • A escala enterprise, asignar permisos por directorio o repositorio con servidores Git privados como Gitea self-hosted, GitHub Enterprise o GitLab
  • El harness interno Goose de Block lee el mismo flujo de artefactos con scopes por rol, y en el momento en que esos scopes se desalinean empieza a mezclar declaraciones públicas con contexto privado de negociaciones; los límites importan muchísimo

• Tres tipos de datos que entran al sistema

  • Conectores: recopilan datos externos desde SaaS, APIs, servidores MCP, correo, calendario, CRM, soporte, analítica, GitHub, Linear, Stripe, warehouse y documentos
    • Todo conector necesita identificadores, permisos por scope, logs de auditoría y credenciales administradas; de lo contrario, se convierte en el mayor agujero de seguridad. Una capa de IAM como Zitadel se encarga de la disciplina de identidad
    • En el trabajo de ejecución de código MCP de Anthropic, usar un patrón de filesystem de carpetas del servidor para precargar todas las definiciones de herramientas redujo el uso de contexto de aproximadamente 150 mil tokens a alrededor de 2 mil tokens, una reducción de 98.7%
  • Datos que genera la empresa: specs, resúmenes de clientes, decisiones, aprendizajes, notas de proyecto, reglas operativas; por defecto en Markdown
    • La regla más importante es separar lo crudo (raw) de lo destilado (distilled): una transcripción de llamada es material crudo; las decisiones tomadas en esa llamada, las objeciones del cliente, el responsable del seguimiento y el riesgo de renovación son el material destilado que el agente realmente consulta
    • Mantener un log de decisiones append-only, una por línea, para que el razonamiento acompañe a la conclusión
  • Bases de datos y streams: donde ya viven las fuentes, como datos de producto en Postgres, marketing en el warehouse y eventos de analítica
    • No copiar a ciegas todo a Markdown; dejar la base de datos como fuente de verdad, dar al agente un usuario de solo lectura restringido, documentar el esquema en un archivo para agentes (data-models/postgres.md) y dejar claros los queries y escrituras permitidos
    • Por defecto, configurar al agente para que no pueda borrar datos de producción. El incidente de Replit de mediados de 2025, cuando un agente de código borró la base de datos de producción durante una sesión, recordó que las instrucciones en prompts no son un límite de seguridad

• Versiones avanzadas y trazabilidad de fuentes

  • Grafos de contexto estructurados: antes de consultar, el agente procesa el material crudo en entidades y relaciones como personas, empresas, objeciones, compromisos, solicitudes de funcionalidades, riesgo de renovación, seguimientos, fechas, decisiones y links a la fuente
    • En lugar de guardar la transcripción, extrae el contenido y encadena llamadas de la misma persona o proyecto, lo que permite responder "¿cuál es el riesgo de renovación de Vandelay Industries?" citando líneas exactas de lo dicho
  • Todo resumen debe poder rastrearse hasta su fuente original (transcripción, ticket, commit, factura o fila de DB). Sin fuente, se acumulan resúmenes plausibles pero imposibles de verificar, y con el primer error colapsa la confianza en todo el agente
    • Con fuente, el agente se vuelve auditable y cualquier miembro del equipo puede verificar el origen con un clic y resolver discrepancias en segundos

Paso 3: elegir la automatización más simple (Choose The Simplest Automation)

• No conviertas todos los flujos de trabajo en agentes: los mejores sistemas son una mezcla de scripts, personas asistidas por IA, flujos de trabajo deterministas y agentes
  • El rol del fundador es elegir la herramienta más liviana que pueda operar con seguridad y aun así superar el estándar de calidad

• Aplicación según la herramienta

  • Script: pasos deterministas (exportar reportes, convertir CSV, ejecutar pruebas, verificar enlaces, validar JSON, formatear el paquete semanal de métricas)
  • Persona asistida por IA: resultados que requieren juicio antes de salir de la empresa (actualizaciones para inversionistas, correos del fundador, copy de precios, notas de contratos)
  • Flujo de trabajo: cuando los pasos se conocen de antemano (recopilar llamadas → resumir → extraer objeciones → redactar notas para CRM → generar seguimiento); motores como LangGraph, Temporal, Inngest y Prefect se encargan del orden, los reintentos y la observabilidad
  • Agente: cuando no se puede definir de antemano la ruta (investigar bugs en producción, research de mercado, casos de soporte anómalos, cuentas de clientes enredadas)
    • El agente bb de Browserbase carga un archivo de habilidades y permisos con alcance específico para cada tarea como agente general orientado a Slack; es mejor que crear un bot separado por tarea, porque con el tiempo los bots se desalinean entre sí

• Harness: capa de seguridad de 6 pasos

  • Preflight: verificar contexto y permisos antes de que el agente gaste tokens
  • Plan: descomponer la tarea y exponer la fase de propuesta
  • Approve: una persona o un modelo juez bloquea malos planes antes de ejecutarlos
  • Execute: ejecutar el trabajo
  • Verify: validar la salida con pruebas, esquemas, rúbricas y ejemplos
  • Log: registrar lo ocurrido en el archivo de ejecución para que la siguiente iteración tenga la respuesta correcta

• Los guardrails van en el código y la configuración, no en el prompt

  • Un prompt como “no borres datos de producción” no es un límite de seguridad
  • Elementos no negociables: tope de ejecuciones y de costo diario, límite de reintentos, profundidad máxima de llamadas a herramientas, credenciales con alcance por agente, prohibición de escribir en producción sin aprobación, prohibición de auto-merge de código, kill switch para toda la flota
  • Los incidentes de generación recursiva ocurridos durante todo 2025, en los que un agente seguía llamando agentes hijos, generaron costos reales antes de que Harness pudiera alcanzarlos; los topes deben ponerse en tiempo de ejecución, antes de que el modelo tenga oportunidad de ignorar instrucciones

Paso 4: codificar habilidades y evals (Encode Skills And Evals)

• Hasta aquí todo es preparación; codificar tareas repetitivas como habilidades y calificarlas con evals es el motor que hace crecer a la empresa, poco a poco y de forma compuesta, cada semana
  • Una habilidad es una instrucción reutilizable más ejemplos para una tarea repetitiva: después de ejecutarla a mano dos veces, se codifica lo que se repite
  • Toda habilidad necesita una forma clara: alcance, entradas, contexto a cargar, procedimiento, formato de salida, ejemplos, reglas de escalamiento, responsable y registro de ejecución
  • Si no dice qué recibe, qué devuelve, cuándo pedir ayuda y quién la mantiene, no es una habilidad sino un prompt largo

• Ejemplo de plantilla de habilidad (customer-call-synthesis)

  • Scope: llamadas de ventas después de obtener la transcripción / Inputs: transcripción, historial de la cuenta, contexto del producto, oportunidad activa
  • Load: ICP, precios, roadmap del producto, taxonomía de objeciones / Steps: extraer hechos → agrupar objeciones → identificar riesgos → redactar seguimiento
  • Output: notas para CRM, brief del cliente, solicitud de función, siguientes acciones / Examples: 3 llamadas previas con notas esperadas
  • Escalate: temas legales o de seguridad, riesgo de churn, precios enterprise / Owner: revenue lead / Eval: 30 llamadas históricas con campos de extracción esperados

• Empieza con habilidades amigables para fundadores

  • Síntesis de llamadas con clientes: extraer objeciones, solicitudes de funciones, riesgos, compromisos y siguientes acciones desde transcripciones originales
  • Clasificación de inbox: ordenar mensajes de inversionistas, clientes, reclutamiento y operaciones, y redactar respuestas para las primeras tres categorías
  • Actualización para inversionistas: redactar la narrativa a partir de métricas y decisiones, con citas de ambos lados
  • Análisis de página de precios: comparar la página en vivo con el registro más reciente de objeciones de clientes
  • Narrativa semanal de métricas: explicar qué cambió, qué se rompió y qué hay que revisar
  • Generación de tests: convertir especificaciones en pruebas y un PR preliminar

• Las 3 capas de los evals, acumuladas en orden

  • Primero, verdad de referencia etiquetada a mano: una persona marca qué es una buena salida en ejemplos reales
  • Segundo, verificaciones deterministas: ofrecen un juicio claro a costo cero (validez del esquema, números que coinciden con la fuente, enlaces que abren, citas que existen, pruebas que pasan)
  • Tercero, juicio de LLM: solo para lo que las verificaciones deterministas no alcanzan a medir (calidad de escritura, tono, ajuste al brief); basta un modelo pequeño y rápido, pero antes de confiar hay que calibrarlo con ejemplos marcados por personas

• Caso de estudio: síntesis de llamadas con clientes

  • El revenue lead marca 30 llamadas históricas: hechos importantes, objeciones, riesgos y seguimiento
  • Verificación determinista: exactitud de nombres, monto contractual y semana de la fecha de seguimiento; y si el brief suena como la llamada lo evalúa el juicio de LLM
  • Después de unas 50 ejecuciones, normalmente se rompen dos cosas: falla el seguimiento de hablantes en llamadas con 3 o más personas, o fusiona dos objeciones distintas en una sola; se corrige por clúster y se reescribe hasta lograr comportamiento consistente

• Caso de estudio: clasificación de leads outbound

  • El fundador etiqueta 300 leads históricos con yes/no según si encajan en el ICP
  • Verificaciones mecánicas: si la empresa es real, si el sitio web carga, si el número de empleados está informado; el resto queda al juicio de LLM frente a la descripción del ICP
  • Cuando el eval está listo, bucles open source de evolución de prompts (GEPA, DSPy) reescriben durante la noche el prompt de clasificación contra las etiquetas; al fundador no le importa leer el prompt final, solo el veredicto del eval

• Las 5 etapas de madurez del eval

  • 1. revisión manual de un ejemplo → 2) puntuar unos pocos casos con una rúbrica escrita → 3) aplicar esa rúbrica a 20–300 casos históricos → 4) probar con un set holdout que el agente nunca vio → 5) seguir la métrica de negocio que la habilidad buscaba mover

• Mantener un buen estado después del lanzamiento: 6 números cada semana

  • Tasa de aceptación, tasa de override, costo por ejecución, cycle time, tiempo de revisión, número de incidentes
  • La tasa de aceptación es la clave: si está por debajo de ~70% (las ediciones menores cuentan como aceptación), todavía no está listo para subir el nivel de autonomía
  • Cuando la tasa de aceptación es baja, reescribir el prompt casi nunca es la respuesta; normalmente es una de cuatro cosas: agregar contexto en runtime, reducir el alcance de la habilidad, añadir ejemplos funcionales al archivo, o escribir reglas claras de escalamiento para casos que nunca debió asumir

Paso 5: volver al equipo nativo de IA (Make The Team AI-Native)

• El fundador empieza primero: la forma más rápida de mover al equipo a una nueva manera de operar es mostrarlo en vivo dentro del contexto de la empresa
  • Demostrar el brief matutino armado durante la noche desde calendario, inbox y Slack; la síntesis de clientes de las llamadas de ayer; el PR de pruebas que el agente corrió contra una especificación; y el borrador de actualización para inversionistas creado a partir del último paquete de métricas
  • La meta es la calibración: ver directamente lo que la capa de agentes puede y no puede hacer
  • Jack Dorsey pasó horas cada mañana durante todo 2025 usando estas herramientas directamente antes de reorganizar Block; eso derivó en una gran reestructuración de eficiencia, y la decisión salió de un liderazgo que había usado agentes en carne propia

• Instálalo desde el día uno; el onboarding termina con un entregable

  • En la primera sesión, cada miembro del equipo sale con un entregable que se puede desplegar ese mismo día (brief de cliente ordenado, macro de soporte, PR de pruebas, crítica de la página de precios); una capacitación que no produce trabajo real se olvida en una semana
  • La herramienta Glass de Ramp pasó de 20 usuarios diarios a alrededor de 700 en tres meses porque cada sesión de onboarding terminaba, por regla, agregando 1 habilidad o artefacto de la nueva persona a la biblioteca compartida

• El rol de las personas crece

  • Las personas diseñan el sistema, se adueñan de las relaciones, juzgan los resultados y cargan con la responsabilidad; los agentes se encargan de ejecutar
  • Los miembros del equipo que solo operan tareas estrechas quedan expuestos en este modelo; quienes convierten juicio en instrucciones, ejemplos y evals valen más que antes

• La contratación también cambia

  • Sube el estándar para abrir un rol: parte de lo que antes requería contratar ahora es una habilidad, así que los nuevos roles solo se asignan al trabajo que de verdad necesita a una persona
  • Al contratar, en vez de trivia, se da un proyecto grande que no pueda terminarse a mano en el tiempo dado y se observa cómo dirige agentes; se evalúan criterio, gusto y capacidad de recuperación cuando el agente se desvía
  • Ejemplos reales: a un analista se le pide un reporte real con recolección de fuentes, extracción de evidencia y un brief pulido en 3 horas; a un ingeniero, replicar una superficie real del producto o construir una herramienta interna basada en especificaciones en un día, incluyendo pruebas; a una contratación de growth, un mapa de mercado y plan de campaña para 50–100 empresas, con scraping, agrupamiento, redacción y priorización. La clave es que todo eso no pueda completarse a mano dentro del tiempo dado.

Paso 6: operar la startup como un bucle de retroalimentación (Run As A Feedback Loop)

• Las startups nativas de IA mejoran su sistema operativo cada semana; vuelven al inicio y arrancan de nuevo
  • Lo que debe cubrir la revisión: qué hizo el agente, en qué puntos intervino la persona, qué eval fallaron, qué contexto faltó, qué habilidades hay que acotar, qué flujos de trabajo hay que eliminar y qué flujos merecen subir de nivel de autonomía

• Ejecutar dos bucles al mismo tiempo

  • Bucle interno: mejorar el trabajo existente (costo por ejecución ↓, tiempo de ciclo ↓, incidentes ↓, tiempo de revisión por artefacto ↓)
  • Bucle externo: explorar lo siguiente (nuevos segmentos de clientes, ideas de producto, cambios de precio, alianzas, movimientos de la competencia, cambios regulatorios, riesgo de churn); los agentes en segundo plano generan candidatos las 24 horas y las personas eligen cuáles perseguir

• Fábrica de software (la parte más grande del bucle interno)

  • Las personas escriben las especificaciones y las pruebas, y los agentes implementan en función de ellas; las verificaciones deterministas se ejecutan solas y una persona revisa antes del merge
  • Empieza por donde los criterios de aceptación sean claros y el alcance del impacto sea pequeño: generación de pruebas, actualización de dependencias, migraciones, herramientas internas, scaffolding de integraciones, scripts de QA, correcciones automáticas de seguridad
  • Dos reglas duras: nada se hace merge automáticamente, y ningún agente escribe en producción
    • Incluso Cursor, aunque ejecuta agentes autónomos en la nube a gran escala, mantendrá una compuerta de revisión humana para los merges hasta inicios de 2026; esa compuerta permite escalar el resto de forma segura

• Sistema de aprendizaje de mercado (bucle externo)

  • Registros de llamadas, extracción de objeciones, agrupación de solicitudes de funciones, seguimiento de competidores, observación de cambios de uso, lectura de patrones de soporte, estudio de oportunidades perdidas
  • Convertir hallazgos en hipótesis y luego probar las más sólidas: conversaciones con clientes, pruebas de landing pages, experimentos de producto, nuevas consultas sobre los datos
  • Los agentes proponen y las personas eligen: si dejas tanto las propuestas como las decisiones estratégicas en manos de agentes, terminarán instalándose en un consenso mediocre o en optimizar, como subiendo una colina, la métrica más fácil de elevar

• La clave de la auto-mejora a nivel empresa = la capacidad de escribir eval

  • Etiqueta manualmente cientos de ejemplos como buenos/malos, crea un eval y conéctalo a un bucle de evolución de prompts: frameworks como GEPA y DSPy proponen mutaciones de prompts con modelos de reflexión pequeños, el eval las clasifica sobre el conjunto etiquetado, despliega al ganador y repite
  • El fundador escribe los eval y lee los clústeres de fallas, pero no usa ni lee los prompts evolucionados
  • Lo que frena no es la capacidad del agente, sino si puedes codificar el criterio de qué es bueno; saber programar ayuda, pero no es el cuello de botella, y un experto de dominio capaz de marcar de forma confiable una salida como buena/mala puede operar todo el bucle
  • El eval es el artefacto central que soporta la carga, y en el momento en que se deja de escribir eval, también se detiene el crecimiento compuesto de la empresa

Conclusión

• No se necesita un genio ni un gran equipo; se necesita la disciplina de mapear el trabajo, acumular contexto, escribir eval y ejecutar el bucle cada semana. Ahora que todos usan el mismo modelo, el sistema operativo es el arma secreta