Automatización con Claude API: mi primer agente útil

Hay mucho contenido sobre agentes de IA que parecen demos de conferencia: impresionantes durante la presentación, inútiles en producción. Este post es sobre lo contrario: un agente pequeño, aburrido, que resuelve un problema real y funciona todos los días sin supervisión.

El problema concreto

En mi flujo de trabajo con clientes freelance, cada semana necesito revisar un conjunto de fuentes técnicas, extraer lo relevante para mis proyectos activos y preparar un resumen priorizado. Hacerlo manualmente me costaba una hora. Con un agente, me cuesta un prompt y una revisión de cinco minutos.

Qué hace el agente

El agente tiene tres pasos:

• Recolección: lee fuentes predefinidas (changelogs de dependencias, docs actualizados, posts técnicos relevantes).
• Filtrado: cruza cada item con los proyectos activos y descarta lo que no aplica.
• Resumen: genera un digest estructurado con prioridad: urgente (breaking changes), importante (features útiles) e informativo (tendencias).

No es complejo. No usa herramientas externas complicadas. Es un script que llama a Claude API con contexto bien definido.

La arquitectura

Sorprendentemente simple: un script en TypeScript que se ejecuta como cron job, llama a Claude API con system prompt fijo y user prompt dinámico, y guarda el resultado en un archivo markdown.

El system prompt define el rol del agente, las reglas de filtrado y el formato de salida. Es la pieza más importante: un system prompt vago genera resultados vagos. Invertí más tiempo refinando este prompt que escribiendo el código.

Lo que aprendí sobre prompts en producción

En producción, los prompts necesitan ser mucho más rigurosos que en una conversación casual:

Formato explícito. Si quieres JSON, especifica el schema exacto. Si quieres markdown, define los headers y la estructura. La ambigüedad en producción genera fallos intermitentes que son pesadillas de debugging.

Restricciones negativas. 'No inventes información que no esté en las fuentes' es más útil que 'sé preciso'. Los modelos de lenguaje tienen tendencia a rellenar huecos. En producción, eso es un bug.

Temperatura baja. Para tareas deterministas, temperatura 0 o muy baja. No quiero creatividad en un informe técnico. Quiero consistencia.

Manejo de errores

La API puede fallar: rate limits, timeouts, respuestas malformadas. El agente tiene retry con backoff exponencial, validación de la respuesta antes de guardarla, y fallback a 'no se pudo generar el reporte' en vez de silenciar el error.

Un agente que falla silenciosamente es peor que no tener agente. Si no genera el reporte, quiero saberlo.

Coste real

Claude API cobra por tokens. Mi agente procesa entre 10K y 20K tokens de entrada y genera unos 2K de salida por ejecución. A precios actuales, cada ejecución cuesta centavos. El ahorro de una hora semanal justifica el coste con creces.

Cuándo NO construir un agente

• Si el proceso cambia cada semana: un agente necesita consistencia. Si las reglas cambian constantemente, es más eficiente hacerlo manual.
• Si necesitas 100% de precisión: los LLMs alucinan. Si un error tiene consecuencias graves, necesitas revisión humana obligatoria.
• Si puedes resolverlo con un script normal: no todo necesita IA. Un grep + filtro en un script bash puede ser más fiable y más barato.

Conclusión

Mi primer agente útil no es impresionante. No tiene UI bonita ni demo de conferencia. Pero ahorra tiempo real, funciona en producción y no necesita supervisión constante. Ese es el estándar: si tu agente necesita más tiempo de mantenimiento del que ahorra, no es un agente útil, es un proyecto secundario disfrazado.