Contexto
Tengo un radar diario que me llega al correo cada mañana a las 7am. Hasta ayer era un resumen del estado del negocio: Stripe, finanzas, equipo, agenda. Útil, pero pasivo.
Lo que quería construir hoy: que el radar empuje acciones, no solo informe.
Dos cambios concretos:
- Prospecto del día. Cada mañana, un humano nuevo con nombre, empresa, por qué me puede ayudar, e icebreaker listo para copiar y pegar. Rotación por día de la semana entre 6 segmentos (hosts de podcast, founders de agencias LATAM, autores de newsletter, creadores de contenido de IA, consultores).
- Growth primero. Cuando el radar sugiere mejoras a los proyectos, que la idea de growth vaya antes que la de producto — porque 10% MoM es la North Metric y merece ocupar el primer renglón.
El día empezó limpio. Terminó siendo una clase sobre rate limits.
Qué aprendí
1. La IA gratis no es gratis: es un cupo mensual disfrazado
El setup: uso OpenRouter con un modelo gratis (FREE_MODEL) para análisis de zoom, improvements del radar, e icebreakers del prospecto. Todo bonito hasta que varias tareas pelean por el mismo cupo en la misma hora.
Lo que se rompió hoy: el radar-improvements se quedaba sin tokens y devolvía JSON vacío. Misma llamada que el radar-growth, misma configuración, pero una respondía y la otra no. Hice un endpoint debug temporal para comparar payloads — eran idénticos. El problema no era el prompt.
El problema era max_tokens: 800. El modelo estaba usando tokens internos de razonamiento que ni se veían en el output, y con 800 de presupuesto no le quedaba nada para la respuesta JSON. Subí a 2000 y listo.
Ese fue el fix obvio. Pero el aprendizaje real vino después.
2. Cuando dos tareas pelean por el cupo, priorizá la North Metric
Con max_tokens: 2000 por llamada, corría 4 tareas seguidas: growth idea, product idea, zoom analysis, y otro par. A la tercera, OpenRouter respondía HTTP 429 (rate limit). Las primeras dos tareas ganaban, las últimas se perdían.
La decisión arquitectónica: si me va a quedar sin cupo, que se acabe en lo que menos importa, no en lo que más.
Ordené el loop para que growth vaya primero. Si después me pega rate limit, se pierde la idea de producto o algún análisis secundario. Pero la North Metric (10% MoM) nunca se queda sin su prompt.
Este es un patrón que me llevo para cualquier sistema con presupuesto limitado: el orden de ejecución es la decisión de prioridad. No son optimizaciones iguales. Lo primero que corre es lo que más te importa.
3. No toda tarea merece IA — algunas funcionan mejor con template
Aquí vino el cambio más grande del día.
El icebreaker del prospecto originalmente se generaba con IA: "dado este humano, escribime 2-3 oraciones para romper el hielo". Funcionaba, pero tenía dos problemas:
- Consumía cupo de la API gratuita todos los días, compitiendo con tareas más valiosas (análisis de zoom, growth ideas).
- Era inconsistente. Un día el icebreaker era genial, al siguiente genérico. La temperatura del modelo generaba variación que yo no necesitaba — solo quería algo sólido, predecible, editable.
La decisión: templated icebreakers. Seis plantillas, una por segmento (podcast host, founder de agencia, autor de newsletter, creador de contenido, consultor, default). Cada plantilla interpola los datos reales de SocialSweep: nombre, empresa, título, país. Todo sincronico, cero tokens, cero rate limit, resultado idéntico cada vez.
Ejemplo de una plantilla para founder de agencia:
Hola [nombre], vi que lideras [empresa] en [país]. Nosotros hacemos software y automatización para founders — complementario a lo que hacen ustedes. ¿Te interesaría explorar referidos cruzados?
¿Es menos creativo que una IA? Sí. ¿Es más útil en la práctica? También. Porque yo lo voy a editar antes de enviarlo de todos modos. El icebreaker no es el mensaje final, es el primer draft que me saca del bloqueo.
La lección:
La IA es cara (en tokens, en variabilidad, en debugging). Úsala donde el resultado cambia según los datos y el contexto es impredecible. Donde el contexto es predecible — como un mensaje de outreach por segmento — un template bueno le gana todos los días.
4. Un cron diario expone defectos que uno de prueba no ve
El weekly del sábado había estado roto en silencio por semanas. Iteraba sobre linearProjectIds (una lista legacy), encontraba IDs que ya no existían, y devolvía arrays vacíos sin error visible. Yo asumía que el equipo no tenía issues esa semana.
Hoy lo reescribí para que lea el equipo desde config/radar-team.yaml (programático, fuente de verdad única) y haga una sola query Linear cross-team con assignee.email.in: [...]. Además, ahora prioriza issues con cycle.isNext = true para sugerir "la semana que viene" desde lo que ya está planeado, con fallback a backlog por prioridad.
El patrón que se repite: un workflow que corre pocas veces tiene más probabilidad de estar roto que uno que corre todos los días. Los crons diarios se auto-sanean porque tú notas el dolor. Los semanales viven con bugs silenciosos durante meses.
Resultado
- Radar diario L-S con prospecto nuevo cada mañana, dedup contra CRM (no me sugiere alguien con quien ya tuve contacto) y rolling 30 días para no repetir.
- Icebreaker templado (0 tokens), 6 plantillas por segmento, salida consistente, editable.
- Growth idea priorizado como primer renglón de improvements. Si rate limit pega, se pierde lo menos importante.
- Weekly del sábado leyendo cycle next real de Linear, con equipo programático desde YAML.
- Zoom digest rediseñado al mismo lenguaje visual del radar (header, hero, secciones con label uppercase, firma con foto), y con sección de participantes que muestra el proyecto/org activo de cada contacto del CRM.
- 14 commits en el día. Todos atómicos, todos describen el "por qué" en el mensaje.
Aprendizaje clave
Cuando construís infra de agentes que corre todos los días, los rate limits se convierten en presupuesto. Y un presupuesto te obliga a priorizar.
Tres reglas que me llevo de hoy:
1. El orden de ejecución es una decisión de prioridad. Si dos tareas pelean por el mismo cupo, la primera en correr es la que más te importa. No les des el mismo peso porque "ambas son tareas de IA".
2. No toda tarea merece IA. Las repetitivas, predecibles, con contexto estable, casi siempre ganan con un template bien hecho. Reservá los tokens para donde el output realmente cambia con los datos.
3. Los crons que corren poco se rompen en silencio. Si tenés un workflow semanal o mensual importante, hacele un modo "disparar ahora" para poder validarlo sin esperar el trigger natural. Los bugs que viven meses son caros.
El radar ya no es un reporte pasivo. Es un sistema que cada mañana me da una persona para contactar y una idea de crecimiento para priorizar. Ese es el cambio de fondo: de "me entero" a "tengo la próxima acción clara antes de abrir la computadora".