En los últimos meses se empezó a usar la palabra agente para casi cualquier cosa que tenga IA.
Un chatbot que responde preguntas.
Un asistente que resume texto.
Una automatización que llama a un modelo.
Una integración con una API.
Todo parece ser “un agente”.
Pero ahí aparece el primer problema: si llamamos agente a cualquier cosa, dejamos de entender qué estamos construyendo realmente.
Y cuando eso pasa, tomamos malas decisiones técnicas.
Agregamos complejidad donde no hacía falta.
Diseñamos flujos difíciles de mantener.
Le damos demasiada libertad a la IA.
Y después nos sorprendemos cuando el sistema se vuelve poco predecible.
La idea de este artículo es ordenar el tema.
No desde el hype.
No desde la promesa mágica.
Sino desde el diseño de software.
Un chatbot responde
Un chatbot, en su forma más simple, responde a una entrada del usuario.
El flujo suele verse así:
Usuario pregunta
→ Modelo responde
Esto puede ser muy útil.
Puede servir para atención al cliente, documentación, soporte interno, generación de ideas, resúmenes o ayuda dentro de una aplicación.
Pero en esencia, el chatbot suele ser reactivo.
Espera una pregunta.
Genera una respuesta.
Y termina ahí.
No necesariamente consulta herramientas.
No necesariamente mantiene estado.
No necesariamente ejecuta pasos.
No necesariamente decide qué hacer después.
Por eso, un chatbot puede ser potente, pero no por eso es un agente.
Un asistente ayuda dentro de un contexto
Un asistente ya puede ser un poco más sofisticado.
Puede tener instrucciones más claras.
Puede conocer el contexto del usuario.
Puede responder siguiendo cierto rol.
Puede ayudar dentro de una aplicación.
Por ejemplo:
Sos un asistente de soporte técnico.
Respondé usando solamente la documentación interna.
Si no sabés la respuesta, derivá el caso.
Esto mejora mucho la experiencia.
Pero sigue sin ser necesariamente un agente.
¿Por qué?
Porque todavía puede estar limitado a responder.
Puede no tener capacidad de planificar, elegir herramientas, ejecutar acciones o avanzar sobre una tarea de varios pasos.
El asistente ayuda.
Pero no siempre actúa.
Un workflow con IA no siempre es un agente
También podemos tener workflows que usan IA.
Por ejemplo:
Recibo un ticket
→ clasifico el ticket con IA
→ asigno prioridad
→ genero una respuesta sugerida
→ notifico al equipo
Ese flujo usa IA.
Pero el camino está definido por nosotros.
El sistema no decide libremente qué hacer.
Sigue pasos preestablecidos.
Esto es muy importante.
Un workflow puede ser mucho más conveniente que un agente.
De hecho, muchas soluciones reales deberían empezar como workflow y no como agente.
Porque un workflow es más simple de probar.
Más fácil de observar.
Más fácil de mantener.
Más fácil de explicar.
Y más fácil de controlar.
Anthropic hace una distinción muy útil: los workflows son sistemas donde el modelo y las herramientas se orquestan mediante caminos de código predefinidos; los agentes, en cambio, pueden dirigir dinámicamente sus procesos y el uso de herramientas para resolver una tarea.
Fuente: Building Effective Agents - Anthropic
Entonces, ¿qué es un agente?
Un agente de IA no es solamente “un modelo respondiendo”.
Un agente es un sistema donde el modelo participa más activamente en la resolución de una tarea.
Una forma simple de verlo sería:
Usuario plantea un objetivo
→ el agente analiza el contexto
→ decide si necesita usar una herramienta
→ ejecuta una acción
→ observa el resultado
→ decide el siguiente paso
→ responde o continúa
OpenAI describe a los agentes como aplicaciones que pueden planificar, llamar herramientas, colaborar entre especialistas y mantener suficiente estado para completar trabajos de varios pasos.
Fuente: Agents - OpenAI API docs
La diferencia no está sólo en el modelo.
La diferencia está en el sistema alrededor del modelo.
Un agente normalmente combina varias piezas:
Modelo
Instrucciones
Herramientas
Contexto
Estado
Validaciones
Límites
Observabilidad
El modelo es una parte.
Pero el agente real es el diseño completo.
La palabra clave: herramientas
Una diferencia fuerte entre un chatbot simple y un agente es el uso de herramientas.
Una herramienta puede ser:
Consultar una base de datos
Buscar información en una API
Leer un archivo
Crear un ticket
Enviar una notificación
Ejecutar una validación
Consultar el estado de una orden
Generar un reporte
Por ejemplo, imaginemos un sistema de soporte.
Un usuario pregunta:
¿Qué pasó con mi pedido?
Un chatbot común podría responder algo genérico:
Podés consultar el estado de tu pedido en la sección Mis compras.
Un agente, en cambio, podría hacer algo como:
1. Identificar al cliente
2. Buscar sus órdenes recientes
3. Consultar el estado del pedido
4. Ver si hay tickets abiertos
5. Generar una respuesta contextual
6. Sugerir una acción
Ahí ya no estamos hablando sólo de texto.
Estamos hablando de integración con sistemas.
Y cuando hay integración con sistemas, aparece la responsabilidad técnica.
El peligro: darle demasiada libertad
Un agente no debería ser una IA “haciendo lo que quiera”.
Eso es una mala idea.
Un buen agente necesita límites.
Necesita saber qué puede hacer y qué no.
Necesita herramientas bien diseñadas.
Necesita permisos.
Necesita validaciones.
Necesita trazabilidad.
Necesita fallback.
Necesita, en algunos casos, intervención humana.
Porque si un agente puede ejecutar acciones reales, también puede equivocarse de forma real.
Puede consultar mal.
Puede interpretar mal.
Puede llamar una herramienta incorrecta.
Puede generar una respuesta convincente pero equivocada.
Puede tomar una acción que no debería.
Entonces el problema no es solamente:
¿Cómo hago que el agente sea más inteligente?
La pregunta correcta es:
¿Cómo diseño un sistema donde la IA pueda aportar valor sin perder control?
Para mí, esa es la conversación importante.
No todo necesita agentes
Esta frase debería estar escrita arriba de cualquier proyecto de IA:
No todo necesita agentes.
A veces alcanza con un prompt mejor diseñado.
A veces alcanza con una función tradicional.
A veces alcanza con un workflow.
A veces necesitás RAG.
A veces necesitás una automatización simple.
Y recién después, en algunos casos, necesitás un agente.
El error es empezar por la tecnología antes de entender el problema.
Algo parecido pasa cuando en software queremos resolver todo con microservicios, eventos o arquitectura compleja.
La herramienta puede ser buena.
Pero si se usa antes de tiempo, se vuelve un problema.
Con agentes pasa lo mismo.
Cuándo sí pensaría en un agente
Yo empezaría a pensar en agentes cuando la tarea tiene varias de estas condiciones:
Requiere varios pasos
Necesita consultar herramientas
Depende del contexto
Puede tener caminos distintos
Necesita observar resultados intermedios
Puede requerir decisión dinámica
Tiene valor si se automatiza parcialmente
Necesita escalar a un humano en ciertos casos
Ejemplos:
Analizar un ticket de soporte y sugerir una respuesta
Consultar información de un cliente y resumir su estado
Revisar órdenes recientes y detectar problemas
Ayudar a documentar un sistema existente
Explorar un repositorio y sugerir mejoras
Orquestar tareas internas de un equipo técnico
En esos casos, un agente puede tener sentido.
Pero incluso ahí, yo empezaría simple.
Primero una herramienta.
Después dos.
Después validaciones.
Después estado.
Después observabilidad.
Después autonomía.
No al revés.
Un ejemplo simple para developers .NET
Supongamos que queremos crear un agente de soporte para un sistema de clientes.
El dominio tiene:
Customers
Orders
SupportTickets
Y queremos que el agente pueda responder preguntas como:
Dame un resumen del cliente con este email.
Mostrame sus últimas órdenes.
¿Tiene tickets abiertos?
Generá una sugerencia de respuesta para soporte.
Una mala forma de diseñarlo sería darle acceso libre a todo.
Una mejor forma sería exponer herramientas concretas:
FindCustomerByEmail
GetCustomerSummary
GetRecentOrders
GetOpenSupportTickets
SuggestSupportResponse
Cada tool debería tener:
Nombre claro
Input bien definido
Output estructurado
Validaciones
Errores esperados
Límites de acceso
Logs
Ahí el agente no “hace magia”.
El agente opera sobre capacidades que nosotros diseñamos.
Eso cambia completamente la conversación.
Agente no significa multiagente
Otro error común es pensar que si vamos a hablar de agentes, entonces tenemos que hablar de multiagentes desde el día uno.
No hace falta.
De hecho, casi nunca empezaría por ahí.
Primero hay que poder diseñar bien un agente simple.
Después, si el problema realmente lo justifica, podemos pensar en varios agentes coordinados.
El OpenAI Agents SDK, por ejemplo, trabaja con conceptos como agentes, herramientas, handoffs y guardrails. Eso es muy potente, pero no significa que todo sistema deba empezar con múltiples agentes.
Fuente: OpenAI Agents SDK
En la práctica, la complejidad tiene que ganarse su lugar.
No se agrega por moda.
El criterio técnico importa más que la herramienta
Podés construir agentes con distintas herramientas:
Semantic Kernel
LangChain
LangGraph
OpenAI Agents SDK
LlamaIndex
CrewAI
AutoGen
Código propio
Pero la herramienta no reemplaza el criterio.
LangGraph, por ejemplo, diferencia workflows y agentes: los workflows tienen caminos predeterminados, mientras que los agentes son más dinámicos y definen su propio proceso y uso de herramientas.
Fuente: Workflows and agents - LangGraph docs
Eso está muy bien.
Pero antes de elegir framework, hay que responder preguntas más básicas:
¿Qué problema quiero resolver?
¿Qué decisiones puede tomar la IA?
¿Qué herramientas necesita?
¿Qué datos puede consultar?
¿Qué acciones puede ejecutar?
¿Qué pasa si se equivoca?
¿Cómo observo lo que hizo?
¿Dónde interviene una persona?
Si esas preguntas no están claras, el framework no te salva.
Mi forma de verlo
Para mí, un agente útil no es el que parece más autónomo.
Es el que resuelve una tarea concreta con el menor nivel de autonomía necesario.
Eso puede sonar menos sexy.
Pero es mucho más realista.
La autonomía sin control no es arquitectura.
Es riesgo.
Un buen agente no necesita hacer todo.
Necesita hacer bien lo que tiene permitido hacer.
Cierre
No todo chatbot es un agente.
No todo asistente es un agente.
No todo workflow con IA es un agente.
Y no todo problema necesita agentes.
Antes de construir, conviene ordenar los conceptos.
Porque cuando entendemos la diferencia entre chatbot, asistente, workflow y agente, diseñamos mejor.
Elegimos mejor las herramientas.
Controlamos mejor los riesgos.
Y construimos soluciones más útiles.
En las próximas entregas voy a llevar esto a código.
La idea es construir un laboratorio práctico de agentes de IA para developers .NET.
Sin humo.
Con diseño.
Con tools.
Con límites.
Con repos.
Y con aprendizajes reales.
Próxima entrega
Cómo diseñar tu primer agente de IA con .NET sin empezar por multiagentes
Si te interesa este tema, voy a continuar esta serie construyendo un ejemplo práctico con .NET, tools y MCP.
Top comments (0)