Lo que no te dicen de los agentes de IA y deberías saber
El hype agéntico empuja a fundadores y equipos a dar acceso amplio a sistemas que apenas comprenden. Detrás de los demos hay decisiones técnicas, económicas y éticas que conviene aterrizar antes de construir el primer agente.
Llevamos un par de años conviviendo con la IA generativa: sistemas que escriben, traducen, resumen, generan código, hacen imágenes. La transición que está ocurriendo ahora —y que va a definir los próximos años— es de la IA generativa a la IA agéntica. Es decir, sistemas que ya no se limitan a producir contenido cuando se los consulta, sino que ejecutan tareas con cierto grado de autonomía: revisan tu correo, agendan reuniones, hacen compras, modifican archivos, despliegan código.
El entusiasmo es comprensible. La promesa de delegar trabajo repetitivo a un sistema que opera 24/7 es seductora para cualquier fundador o líder de equipo. Pero entre la promesa y la implementación responsable hay un terreno lleno de matices que el marketing de las plataformas suele omitir. Este texto recoge ocho variables que conviene tener clarísimas antes de construir tu primer agente.
Un agente no es lo mismo que una app, ni que un artefacto
La línea entre estos tres términos se ha vuelto borrosa y esa confusión cuesta dinero y tiempo. Un asistente conversacional —como ChatGPT, Claude o Gemini en su interfaz web— responde cuando tú le hablas. Un artefacto es una pieza de código (una calculadora, un dashboard, una herramienta de análisis) que se ejecuta cuando tú la abres en tu navegador: no tiene vida propia. Un agente, en cambio, es un programa desplegado en algún servidor que puede ejecutarse sin ti, en horarios programados o reaccionando a eventos.
La diferencia operativa más importante: el artefacto requiere tu presencia activa, el agente no. Eso cambia todo: los costos, los riesgos, la complejidad de mantenimiento y, sobre todo, las consecuencias de un error.
La cuota de tu suscripción no alimenta a tu agente
Una confusión muy extendida: pagar Claude Pro, ChatGPT Plus o cualquier suscripción al asistente conversacional no le da combustible a un agente que tú construyas. Esa suscripción cubre tu uso humano de la interfaz web. Para que un agente funcione necesitas créditos de API, que se pagan aparte por consumo, generalmente por cada millón de tokens procesados.
Más aún: los agentes consumen muchos más tokens de los que uno intuye, porque internamente hacen varios pasos de razonamiento, llamadas a herramientas, búsquedas web, lectura de resultados, síntesis. Un solo "ejecuta el research diario" puede traducirse en docenas o cientos de llamadas internas al modelo. Antes de construir varios agentes, conviene estimar el costo mensual de cada uno, medirlo durante dos semanas en producción y recién entonces escalar. Los costos reales suelen sorprender al alza.
Un artefacto bien diseñado puede reemplazar a un agente mal pensado
Muchas tareas que la gente cree que necesitan automatización en realidad solo necesitan una buena herramienta a demanda. ¿Necesitas evaluar si un feature vale la pena construir? Es un artefacto. ¿Necesitas que alguien te avise cuando un competidor lance algo nuevo? Eso sí es un agente.
El criterio de decisión es simple: si la tarea no necesita ejecutarse sola en horarios definidos o reaccionar a eventos, probablemente un artefacto basta. Y los artefactos sin IA integrada son virtualmente gratis de operar después de su creación, mientras los agentes cuestan por cada ejecución programada. Para un equipo con presupuesto ajustado, esto debería sesgar la decisión hacia artefactos siempre que la tarea lo permita.
Los agentes no recuerdan nada por defecto
Si tu agente de research corre el lunes y luego el martes, el del martes no recuerda lo del lunes a menos que tú diseñes explícitamente esa memoria —guardar resultados en una base de datos o un archivo, y leerlos al inicio de cada ejecución. De fábrica, cada ejecución es amnésica.
Esto es contraintuitivo, porque la gente asume que el agente "aprende" o "se vuelve más inteligente" con el tiempo, pero no es así. La inteligencia está en el modelo subyacente, no en el agente como entidad. La memoria, la mejora continua y el aprendizaje específico al contexto son funcionalidades que tienes que construir tú.
Los modelos no son intercambiables sin consecuencias
La documentación de las plataformas suele decir "puedes usar el modelo más económico para ahorrar". Es cierto, pero los modelos pequeños fallan más en tareas complejas de razonamiento. Un agente de research con un modelo barato puede entregar resúmenes superficiales o errores factuales que un modelo más capaz habría detectado.
La economía real radica en empezar con el modelo más capaz para validar que el agente funciona, luego bajar al más barato y verifica que la calidad se mantiene aceptable. Saltarse ese paso es una receta para tener un agente barato e inútil.
Los permisos amplios son una espada de Damocles
Existen historias de terror documentadas: agentes que borraron bases de datos, agentes que enviaron correos masivos con información confidencial, agentes que ejecutaron transacciones que no debían. Casi todos esos incidentes tienen un denominador común: alguien le dio al agente más permisos de los necesarios "por si acaso los necesita".
El principio aquí es viejo en seguridad informática y aplica perfectamente: permiso mínimo necesario, siempre. Un agente que solo necesita leer no debería poder escribir. Uno que solo necesita escribir borradores no debería poder enviarlos. Uno que solo necesita reportar no debería tener credenciales para ejecutar. Y para acciones irreversibles —borrar, transferir dinero, publicar— conviene mantener un humano en el proceso, aunque eso reduzca la "magia" del agente.
Lo que se llama "deploy a producción" rara vez es trivial
Los demos de YouTube muestran agentes funcionales en quince minutos. Lo que no muestran es lo que viene después: hosting que cuesta, manejo de errores cuando la API falla, logs para diagnosticar lo que ocurrió cuando algo salió mal, reintentos cuando una llamada se cae a mitad de ejecución, alertas cuando el agente se desvía de su rol, validación de outputs para no propagar errores a sistemas downstream.
Un agente "completo" en producción es bastante más trabajo que el demo bonito que viste en redes. No es para desanimar, sino para presupuestar correctamente. Construir el agente es la primera parte del trabajo. Operarlo de forma confiable es la otra mitad. Y suele subestimarse.
La pregunta que filtra todo lo anterior
Antes de darle a un agente cualquier permiso, conviene hacerse una pregunta brutalmente sencilla: ¿qué pasa en el peor caso si este agente alucina o se equivoca? Si la respuesta es "pierdo treinta minutos leyendo un brief malo", adelante. Si la respuesta es "pierdo data, dinero, reputación o información sensible de personas", entonces el costo del error supera al ahorro del agente y conviene poner un humano en el medio o, directamente, no automatizar esa parte.
El hype agéntico actual genera presión para construir cosas rápido y darles permisos amplios. La buena noticia es que entre "no uso agentes" y "le doy las llaves de mi negocio a un sistema autónomo" hay un espectro muy amplio. Empezar por agentes de bajo riesgo —los que solo leen, no escriben— permite ganar intuición sin pagar el precio de un error caro.
Construir agentes va a ser cada vez más fácil. Construirlos bien va a seguir requiriendo criterio. Y ese criterio, por ahora, no se delega.