Construir agentes IA que realmente funcionan
Un agente IA es un LLM con la habilidad de tomar acciones. En vez de solo generar texto, puede llamar APIs, consultar bases de datos, enviar mensajes, disparar flujos de trabajo y tomar decisiones en bucle. La promesa es automatización: un sistema que maneja tareas sin supervisión humana constante.
La realidad es más matizada. Los agentes funcionan brillantemente para tareas bien delimitadas con fronteras claras. Se desmoronan espectacularmente cuando se les dan objetivos vagos, acceso ilimitado a herramientas y ninguna barandilla. La diferencia entre un agente de demo y uno de producción no es el LLM — es todo lo que rodea al LLM.
Lo que realmente es un agente
Quita el hype y un agente tiene cuatro componentes:
El LLM recibe entrada (mensaje de usuario, disparador programado, evento). Decide qué herramientas llamar. Las llama vía servidores MCP. Recibe resultados. Decide qué hacer siguiente. Este bucle continúa hasta que la tarea termine o el agente decida parar.
Simple en teoría. El diablo está en cada detalle.
Construir un agente en Zubnet
En la plataforma, crear un agente involucra cuatro pasos. Cada uno tiene decisiones que determinarán si tu agente funciona confiablemente o se vuelve una fuente de llamadas a las 3 de la mañana.
1. Crear el agente
Dale un nombre, elige un modelo y escribe un prompt de sistema.
El modelo importa más de lo que piensas. Para agentes que necesitan llamar herramientas confiablemente, usa un modelo fuerte de razonamiento. Claude Sonnet 4, GPT-4.1 o Gemini 2.5 Pro. Modelos más pequeños ahorran dinero pero toman peores decisiones de llamada a herramientas, y una mala llamada a herramienta en un agente no es solo una respuesta incorrecta — es una acción incorrecta.
El prompt de sistema es la constitución de tu agente. Sé explícito sobre:
• Qué debería hacer el agente (y qué nunca debería hacer)
• Cuándo usar cada herramienta y cuándo saltárselas
• Cómo manejar errores y ambigüedad
• Cuándo pedir aclaración al usuario vs. tomar una decisión
• Qué tono usar en mensajes
Ser demasiado vago. “Eres un asistente útil que gestiona nuestro repo de GitHub” llevará a un agente que crea issues aleatorios, cierra cosas que no debería y mergea PRs sin revisión. “Puedes crear issues de GitHub cuando los usuarios reporten bugs en el canal #bugs. Nunca debes cerrar issues, mergear PRs o modificar configuraciones del repositorio.” — ese es un prompt de sistema que produce un agente confiable.
2. Conectar un canal
Los canales son cómo los agentes se comunican con el mundo. En Zubnet, puedes conectar:
• Telegram — pega tu token de bot desde @BotFather
• Discord — pega tu token de bot desde el Discord Developer Portal
• Webhooks — cualquier endpoint HTTP que pueda enviar/recibir JSON
El canal determina dónde vive el agente. Un agente bot de Telegram responde en chats de Telegram. Un agente bot de Discord vive en tu servidor Discord. Un agente webhook responde a llamadas API.
Elige un canal para empezar. No intentes construir un agente multi-canal el primer día. Hazlo funcionar confiablemente en una plataforma primero.
3. Agregar herramientas (servidores MCP)
Las herramientas son lo que hace que los agentes sean más que chatbots. En Zubnet, las herramientas son proporcionadas por servidores MCP (Model Context Protocol). Tenemos 117 de ellos. Algunos ejemplos:
• GitHub — buscar repos, crear issues, leer archivos, listar PRs
• PostgreSQL / MySQL — consultar bases de datos (solo lectura si eres inteligente)
• Brave Search — buscar en la web
• Filesystem — leer y escribir archivos
• Slack — enviar mensajes, leer canales
Activa los servidores que necesites, configura sus credenciales (claves API, URLs de BD), y el agente puede usarlos.
Solo da a los agentes las herramientas que realmente necesitan. Un agente que puede buscar en GitHub no necesita acceso de escritura a la base de datos. Un agente que envía resúmenes diarios no necesita acceso al filesystem. Cada herramienta innecesaria es una superficie de ataque para que las cosas vayan mal.
4. Configurar disparadores
Los disparadores determinan cuándo se activa el agente:
• Mensaje de usuario — responde cuando alguien le escribe al bot (defecto para agentes de chat)
• Programación cron — corre en horas fijas (ej., “todos los días a las 9 AM”)
• Evento — se dispara cuando algo específico pasa (payload de webhook coincide con un patrón)
Los agentes disparados por cron son geniales para tareas recurrentes: resúmenes diarios de standup, reportes analíticos semanales, chequeos de monitoreo. Los agentes disparados por eventos manejan flujos reactivos: nuevo issue de GitHub → clasificar y etiquetar, nuevo ticket de soporte → redactar respuesta.
Las partes difíciles
Construir el agente toma 20 minutos. Hacerlo confiable toma semanas. Aquí es donde los agentes de producción realmente fallan:
Manejo de errores: cuando el LLM alucina una llamada a herramienta
Los LLMs a veces llaman herramientas con parámetros incorrectos, llaman herramientas que no existen o llaman la herramienta correcta en el contexto incorrecto. Tu agente necesita manejar todo esto con elegancia.
En Zubnet, las llamadas a herramientas fallidas devuelven mensajes de error al LLM, que entonces puede decidir qué hacer. Pero necesitas decirle qué hacer en el prompt de sistema:
If a tool call fails:
1. Do NOT retry the same call with the same parameters
2. Analyze the error message
3. If it is a permission error, tell the user you cannot do that
4. If it is a rate limit, wait and try once more
5. If it is an unknown error, summarize what happened and ask for help
6. Never retry more than twice totalSin estas instrucciones, los agentes se quedan atascados en bucles de reintento, quemando tokens y tiempo en la misma llamada que falla una y otra vez.
Límites de tasa: topes de frecuencia
Un agente conectado a un servidor Discord ocupado con 500 usuarios activos puede recibir cientos de mensajes por minuto. Sin limitación de tasa, hará:
• Agotar tu presupuesto de tokens API en horas
• Alcanzar límites de tasa del proveedor y empezar a devolver errores
• Generar tantas respuestas que el canal se vuelve inutilizable
Configura topes de frecuencia. En Zubnet, puedes configurar:
• Máx de respuestas por minuto (por canal)
• Máx de tokens por hora (control de presupuesto)
• Período de enfriamiento entre respuestas al mismo usuario
• Límite de profundidad de cola (descartar mensajes cuando va muy atrás)
Permisos: restringir lo que los agentes pueden hacer
Este es el que te salvará de desastres. Los agentes deberían tener los permisos mínimos necesarios para su trabajo.
• Herramientas de BD: solo lectura a menos que se necesiten escrituras específicamente
• Herramientas GitHub: leer + crear issues, pero no cerrar/mergear/eliminar
• Herramientas filesystem: directorios específicos solamente, nunca /
• Herramientas de mensajería: canales específicos solamente, nunca DMs a ejecutivos
Piénsalo así: ¿cuál es la peor cosa que este agente podría hacer con las herramientas que tiene? Si la respuesta te pone nervioso, reduce los permisos.
Degradación elegante
Cuando una herramienta está caída, el agente no debería fallar. Debería reconocer la limitación y hacer lo que pueda sin esa herramienta. Incluye esto en tu prompt de sistema:
If a tool is unavailable or returning errors:
- Acknowledge it to the user: "I cannot access GitHub right now"
- Do what you can without that tool
- Never make up data to compensate for a missing tool
- Suggest the user try again laterEjemplos reales
Ejemplo 1: Bot de soporte
Un bot de Telegram que responde preguntas de clientes usando tu base de conocimiento.
• Modelo: Claude Sonnet 4 (fuerte siguiendo instrucciones)
• Herramientas: Brave Search (para docs), PostgreSQL (solo lectura, para búsquedas de cuenta)
• Canal: Telegram
• Disparador: Mensaje de usuario
• Límite de tasa: 30 respuestas/min, enfriamiento de 2s por usuario
El prompt de sistema se enfoca en: responder desde docs primero, escalar a humano si no está seguro, nunca compartir datos de otros clientes, nunca hacer promesas sobre características o plazos.
Ejemplo 2: Agente de resumen diario
Un bot de Discord que publica un resumen matutino de lo que pasó durante la noche.
• Modelo: GPT-4.1 (bueno para resúmenes estructurados)
• Herramientas: GitHub (leer PRs e issues), Slack (leer canales)
• Canal: Discord (canal #daily-summary)
• Disparador: Cron, cada día laboral a las 9:00 AM
• Límite de tasa: 1 mensaje por disparo (solo se dispara una vez)
El prompt de sistema se enfoca en: resumir PRs mergeados, issues abiertos/cerrados y discusiones clave de Slack. Manténlo bajo 500 palabras. Usa viñetas. Etiqueta miembros relevantes del equipo.
Ejemplo 3: Monitor de contenido
Un agente que vigila eventos específicos y alerta al equipo.
• Modelo: Gemini 2.5 Pro (rápido, bueno en clasificación)
• Herramientas: Brave Search (monitorear menciones), Slack (enviar alertas)
• Canal: Webhook (disparado por servicio de monitoreo)
• Disparador: Evento (webhook entrante con resultados de búsqueda)
• Límite de tasa: 10 alertas/hora (prevenir fatiga de alertas)
El prompt de sistema se enfoca en: clasificar menciones como positivas/negativas/neutras, solo alertar en negativas o críticas, incluir URL fuente y resumen de una oración.
Pruebas: empieza pequeño
Los agentes de Zubnet tienen dos modos:
• Modo rápido — configuración simplificada, bueno para pruebas. Configuración limitada de herramientas, disparadores básicos. Úsalo para validar que tu concepto de agente funcione.
• Modo avanzado — configuración completa, listo para producción. Prompts de sistema detallados, límites de tasa granulares, controles de permisos, múltiples disparadores.
Siempre empieza en modo rápido. Haz que el comportamiento básico funcione bien. Luego gradúa al modo avanzado y agrega las barandillas.
• Envía 20 mensajes normales — ¿responde correctamente?
• Envía 5 mensajes que debería rechazar — ¿los rechaza?
• Deshabilita una herramienta — ¿se degrada elegantemente?
• Envía 50 mensajes en 1 minuto — ¿funciona el límite de tasa?
• Envía un mensaje en un idioma que no debería soportar — ¿lo maneja?
• Pídele hacer algo fuera de su alcance — ¿se mantiene en su carril?
La verdad incómoda sobre los agentes
Los agentes no son magia. Son LLMs en bucle con acceso a herramientas. Cometen errores. A veces harán lo incorrecto. La pregunta no es “¿cometerá un error mi agente?” — es “¿qué pasa cuando lo haga?”
Los agentes que funcionan en producción son los que tienen:
• Alcance ajustado (“haz bien esta sola cosa”)
• Fronteras explícitas (“nunca hagas estas cosas”)
• Permisos limitados (menor privilegio, siempre)
• Límites de tasa y topes de presupuesto (prevenir costes descontrolados)
• Rutas de escalada humana (“ante la duda, pregunta a un humano”)
• Monitoreo y logs (para saber qué pasó)
Los agentes en Zubnet están disponibles para todos los usuarios. Empieza con un simple bot de Telegram o Discord, hazlo bien, luego expande. La infraestructura maneja las partes difíciles — tú te enfocas en el prompt de sistema, las herramientas y las barandillas.
¿Listo para construir? Crea tu primer agente en zubnet.com