The latest articles on DEV Community by leandro-layerle (@leandrolayerle). https://dev.to/leandrolayerle https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F893984%2Fb0c26c8e-2f05-4230-977e-0bc2fe143f4a.jpg https://dev.to/leandrolayerle en leandro-layerle Tue, 07 Jul 2026 13:34:30 +0000 https://dev.to/leandrolayerle/no-todo-chatbot-es-un-agente-de-ia-3oec https://dev.to/leandrolayerle/no-todo-chatbot-es-un-agente-de-ia-3oec <p>En los últimos meses se empezó a usar la palabra <strong>agente</strong> para casi cualquier cosa que tenga IA.</p> <p>Un chatbot que responde preguntas.</p> <p>Un asistente que resume texto.</p> <p>Una automatización que llama a un modelo.</p> <p>Una integración con una API.</p> <p>Todo parece ser “un agente”.</p> <p>Pero ahí aparece el primer problema: <strong>si llamamos agente a cualquier cosa, dejamos de entender qué estamos construyendo realmente</strong>.</p> <p>Y cuando eso pasa, tomamos malas decisiones técnicas.</p> <p>Agregamos complejidad donde no hacía falta.</p> <p>Diseñamos flujos difíciles de mantener.</p> <p>Le damos demasiada libertad a la IA.</p> <p>Y después nos sorprendemos cuando el sistema se vuelve poco predecible.</p> <p>La idea de este artículo es ordenar el tema.</p> <p>No desde el hype.</p> <p>No desde la promesa mágica.</p> <p>Sino desde el diseño de software.</p> <h2> Un chatbot responde </h2> <p>Un chatbot, en su forma más simple, responde a una entrada del usuario.</p> <p>El flujo suele verse así:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Usuario pregunta → Modelo responde </code></pre> </div> <p>Esto puede ser muy útil.</p> <p>Puede servir para atención al cliente, documentación, soporte interno, generación de ideas, resúmenes o ayuda dentro de una aplicación.</p> <p>Pero en esencia, el chatbot suele ser <strong>reactivo</strong>.</p> <p>Espera una pregunta.</p> <p>Genera una respuesta.</p> <p>Y termina ahí.</p> <p>No necesariamente consulta herramientas.</p> <p>No necesariamente mantiene estado.</p> <p>No necesariamente ejecuta pasos.</p> <p>No necesariamente decide qué hacer después.</p> <p>Por eso, un chatbot puede ser potente, pero no por eso es un agente.</p> <h2> Un asistente ayuda dentro de un contexto </h2> <p>Un asistente ya puede ser un poco más sofisticado.</p> <p>Puede tener instrucciones más claras.</p> <p>Puede conocer el contexto del usuario.</p> <p>Puede responder siguiendo cierto rol.</p> <p>Puede ayudar dentro de una aplicación.</p> <p>Por ejemplo:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Sos un asistente de soporte técnico. Respondé usando solamente la documentación interna. Si no sabés la respuesta, derivá el caso. </code></pre> </div> <p>Esto mejora mucho la experiencia.</p> <p>Pero sigue sin ser necesariamente un agente.</p> <p>¿Por qué?</p> <p>Porque todavía puede estar limitado a responder.</p> <p>Puede no tener capacidad de planificar, elegir herramientas, ejecutar acciones o avanzar sobre una tarea de varios pasos.</p> <p>El asistente ayuda.</p> <p>Pero no siempre actúa.</p> <h2> Un workflow con IA no siempre es un agente </h2> <p>También podemos tener workflows que usan IA.</p> <p>Por ejemplo:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Recibo un ticket → clasifico el ticket con IA → asigno prioridad → genero una respuesta sugerida → notifico al equipo </code></pre> </div> <p>Ese flujo usa IA.</p> <p>Pero el camino está definido por nosotros.</p> <p>El sistema no decide libremente qué hacer.</p> <p>Sigue pasos preestablecidos.</p> <p>Esto es muy importante.</p> <p>Un workflow puede ser mucho más conveniente que un agente.</p> <p>De hecho, muchas soluciones reales deberían empezar como workflow y no como agente.</p> <p>Porque un workflow es más simple de probar.</p> <p>Más fácil de observar.</p> <p>Más fácil de mantener.</p> <p>Más fácil de explicar.</p> <p>Y más fácil de controlar.</p> <p>Anthropic hace una distinción muy útil: los <strong>workflows</strong> son sistemas donde el modelo y las herramientas se orquestan mediante caminos de código predefinidos; los <strong>agentes</strong>, en cambio, pueden dirigir dinámicamente sus procesos y el uso de herramientas para resolver una tarea.</p> <p>Fuente: <a href="https://www.anthropic.com/research/building-effective-agents" rel="noopener noreferrer">Building Effective Agents - Anthropic</a></p> <h2> Entonces, ¿qué es un agente? </h2> <p>Un agente de IA no es solamente “un modelo respondiendo”.</p> <p>Un agente es un sistema donde el modelo participa más activamente en la resolución de una tarea.</p> <p>Una forma simple de verlo sería:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>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.</p> <p>Fuente: <a href="https://developers.openai.com/api/docs/guides/agents" rel="noopener noreferrer">Agents - OpenAI API docs</a></p> <p>La diferencia no está sólo en el modelo.</p> <p>La diferencia está en el sistema alrededor del modelo.</p> <p>Un agente normalmente combina varias piezas:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Modelo Instrucciones Herramientas Contexto Estado Validaciones Límites Observabilidad </code></pre> </div> <p>El modelo es una parte.</p> <p>Pero el agente real es el diseño completo.</p> <h2> La palabra clave: herramientas </h2> <p>Una diferencia fuerte entre un chatbot simple y un agente es el uso de herramientas.</p> <p>Una herramienta puede ser:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>Por ejemplo, imaginemos un sistema de soporte.</p> <p>Un usuario pregunta:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>¿Qué pasó con mi pedido? </code></pre> </div> <p>Un chatbot común podría responder algo genérico:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Podés consultar el estado de tu pedido en la sección Mis compras. </code></pre> </div> <p>Un agente, en cambio, podría hacer algo como:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>Ahí ya no estamos hablando sólo de texto.</p> <p>Estamos hablando de integración con sistemas.</p> <p>Y cuando hay integración con sistemas, aparece la responsabilidad técnica.</p> <h2> El peligro: darle demasiada libertad </h2> <p>Un agente no debería ser una IA “haciendo lo que quiera”.</p> <p>Eso es una mala idea.</p> <p>Un buen agente necesita límites.</p> <p>Necesita saber qué puede hacer y qué no.</p> <p>Necesita herramientas bien diseñadas.</p> <p>Necesita permisos.</p> <p>Necesita validaciones.</p> <p>Necesita trazabilidad.</p> <p>Necesita fallback.</p> <p>Necesita, en algunos casos, intervención humana.</p> <p>Porque si un agente puede ejecutar acciones reales, también puede equivocarse de forma real.</p> <p>Puede consultar mal.</p> <p>Puede interpretar mal.</p> <p>Puede llamar una herramienta incorrecta.</p> <p>Puede generar una respuesta convincente pero equivocada.</p> <p>Puede tomar una acción que no debería.</p> <p>Entonces el problema no es solamente:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>¿Cómo hago que el agente sea más inteligente? </code></pre> </div> <p>La pregunta correcta es:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>¿Cómo diseño un sistema donde la IA pueda aportar valor sin perder control? </code></pre> </div> <p>Para mí, esa es la conversación importante.</p> <h2> No todo necesita agentes </h2> <p>Esta frase debería estar escrita arriba de cualquier proyecto de IA:</p> <blockquote> <p>No todo necesita agentes.</p> </blockquote> <p>A veces alcanza con un prompt mejor diseñado.</p> <p>A veces alcanza con una función tradicional.</p> <p>A veces alcanza con un workflow.</p> <p>A veces necesitás RAG.</p> <p>A veces necesitás una automatización simple.</p> <p>Y recién después, en algunos casos, necesitás un agente.</p> <p>El error es empezar por la tecnología antes de entender el problema.</p> <p>Algo parecido pasa cuando en software queremos resolver todo con microservicios, eventos o arquitectura compleja.</p> <p>La herramienta puede ser buena.</p> <p>Pero si se usa antes de tiempo, se vuelve un problema.</p> <p>Con agentes pasa lo mismo.</p> <h2> Cuándo sí pensaría en un agente </h2> <p>Yo empezaría a pensar en agentes cuando la tarea tiene varias de estas condiciones:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>Ejemplos:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>En esos casos, un agente puede tener sentido.</p> <p>Pero incluso ahí, yo empezaría simple.</p> <p>Primero una herramienta.</p> <p>Después dos.</p> <p>Después validaciones.</p> <p>Después estado.</p> <p>Después observabilidad.</p> <p>Después autonomía.</p> <p>No al revés.</p> <h2> Un ejemplo simple para developers .NET </h2> <p>Supongamos que queremos crear un agente de soporte para un sistema de clientes.</p> <p>El dominio tiene:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Customers Orders SupportTickets </code></pre> </div> <p>Y queremos que el agente pueda responder preguntas como:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Dame un resumen del cliente con este email. Mostrame sus últimas órdenes. ¿Tiene tickets abiertos? Generá una sugerencia de respuesta para soporte. </code></pre> </div> <p>Una mala forma de diseñarlo sería darle acceso libre a todo.</p> <p>Una mejor forma sería exponer herramientas concretas:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>FindCustomerByEmail GetCustomerSummary GetRecentOrders GetOpenSupportTickets SuggestSupportResponse </code></pre> </div> <p>Cada tool debería tener:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Nombre claro Input bien definido Output estructurado Validaciones Errores esperados Límites de acceso Logs </code></pre> </div> <p>Ahí el agente no “hace magia”.</p> <p>El agente opera sobre capacidades que nosotros diseñamos.</p> <p>Eso cambia completamente la conversación.</p> <h2> Agente no significa multiagente </h2> <p>Otro error común es pensar que si vamos a hablar de agentes, entonces tenemos que hablar de multiagentes desde el día uno.</p> <p>No hace falta.</p> <p>De hecho, casi nunca empezaría por ahí.</p> <p>Primero hay que poder diseñar bien un agente simple.</p> <p>Después, si el problema realmente lo justifica, podemos pensar en varios agentes coordinados.</p> <p>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.</p> <p>Fuente: <a href="https://openai.github.io/openai-agents-python/" rel="noopener noreferrer">OpenAI Agents SDK</a></p> <p>En la práctica, la complejidad tiene que ganarse su lugar.</p> <p>No se agrega por moda.</p> <h2> El criterio técnico importa más que la herramienta </h2> <p>Podés construir agentes con distintas herramientas:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Semantic Kernel LangChain LangGraph OpenAI Agents SDK LlamaIndex CrewAI AutoGen Código propio </code></pre> </div> <p>Pero la herramienta no reemplaza el criterio.</p> <p>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.</p> <p>Fuente: <a href="https://docs.langchain.com/oss/python/langgraph/workflows-agents" rel="noopener noreferrer">Workflows and agents - LangGraph docs</a></p> <p>Eso está muy bien.</p> <p>Pero antes de elegir framework, hay que responder preguntas más básicas:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>¿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? </code></pre> </div> <p>Si esas preguntas no están claras, el framework no te salva.</p> <h2> Mi forma de verlo </h2> <p>Para mí, un agente útil no es el que parece más autónomo.</p> <p>Es el que resuelve una tarea concreta con el menor nivel de autonomía necesario.</p> <p>Eso puede sonar menos sexy.</p> <p>Pero es mucho más realista.</p> <p>La autonomía sin control no es arquitectura.</p> <p>Es riesgo.</p> <p>Un buen agente no necesita hacer todo.</p> <p>Necesita hacer bien lo que tiene permitido hacer.</p> <h2> Cierre </h2> <p>No todo chatbot es un agente.</p> <p>No todo asistente es un agente.</p> <p>No todo workflow con IA es un agente.</p> <p>Y no todo problema necesita agentes.</p> <p>Antes de construir, conviene ordenar los conceptos.</p> <p>Porque cuando entendemos la diferencia entre chatbot, asistente, workflow y agente, diseñamos mejor.</p> <p>Elegimos mejor las herramientas.</p> <p>Controlamos mejor los riesgos.</p> <p>Y construimos soluciones más útiles.</p> <p>En las próximas entregas voy a llevar esto a código.</p> <p>La idea es construir un laboratorio práctico de agentes de IA para developers .NET.</p> <p>Sin humo.</p> <p>Con diseño.</p> <p>Con tools.</p> <p>Con límites.</p> <p>Con repos.</p> <p>Y con aprendizajes reales.</p> <h2> Próxima entrega </h2> <p><strong>Cómo diseñar tu primer agente de IA con .NET sin empezar por multiagentes</strong></p> <p>Si te interesa este tema, voy a continuar esta serie construyendo un ejemplo práctico con .NET, tools y MCP.</p> ai agents dotnet architecture