La mayoría de las empresas con las que hablamos quieren un agente de IA. Cuando preguntamos qué hace exactamente ese agente, obtenemos respuestas del tipo "gestionará todo", "se comunicará con proveedores, hará seguimiento de facturas y planificará turnos". Ahí está el problema. Un agente que hace todo generalmente no hace nada de forma fiable.
Este artículo es un procedimiento práctico — no teoría, sino un marco de decisión que hemos validado en despliegues reales. Le guiaremos desde la selección del primer caso de uso, pasando por la definición de herramientas, guardrails y evaluación, hasta cómo expandir el agente de forma progresiva. Y también le diremos qué conviene evitar al principio.
Paso 1: Elija un caso de uso estrecho y bien delimitado
La razón más frecuente de fracaso del primer agente no es técnica. Es un scope demasiado amplio.
Un buen primer caso de uso cumple estos criterios:
- Entrada y salida claras — el agente recibe algo concreto y devuelve algo concreto (no "procesa un email")
- Resultado verificable — usted o el sistema puede comprobar si el agente hizo lo correcto
- Herramientas acotadas — máximo 3–5 herramientas, no "acceso a todos los sistemas"
- Tasa de error tolerable — si el agente comete un error, puede detectarlo antes de que tenga impacto
Ejemplos que funcionan en la práctica como primeros proyectos: un agente que cada mañana descarga las nuevas reclamaciones del helpdesk, las categoriza y escribe un resumen en Excel o en una hoja de cálculo; un agente que revisa nuevos pedidos en el sistema y ejecuta los pasos de API predefinidos si el pedido cumple las condiciones establecidas; un agente que, bajo demanda, extrae documentación relevante de la biblioteca interna mediante RAG sobre documentación industrial y formula una respuesta.
Por el contrario, no recomendamos como primer proyecto: un agente con acceso a varios departamentos a la vez, un agente que envía emails o emite facturas sin supervisión, o un agente donde no está claro cómo se va a medir el éxito.
Paso 2: Defina las herramientas — no "qué puede el agente", sino "qué está autorizado a hacer"
Las herramientas son el núcleo del agente. Un agente sin herramientas es solo un chatbot; un agente con herramientas demasiado permisivas es un riesgo de seguridad.
Al definir las herramientas, piense en dos pasos:
¿Qué necesita el agente físicamente? - Lectura (base de datos, API, archivos, base de datos vectorial) - Escritura (actualizar un registro, enviar un mensaje, escribir en el sistema) - Cálculo o transformación (conversión de formato, resumen, clasificación)
¿Qué tendrá el agente permitido hacer? Este es el paso crítico que se suele saltar. Cada herramienta debe tener un scope explícito: el agente puede leer registros de la tabla X, pero no borrarlos. Puede llamar al endpoint de API Y con clave de solo lectura. Puede escribir en la sección Z, pero no modificar registros históricos.
Una buena regla para el primer agente: operaciones de escritura únicamente a través de una HITL gate — es decir, con aprobación humana antes de ejecutar. Human-in-the-loop en agentes no es una arquitectura compleja; en LangGraph es una sola llamada a interrupt(). Añade latencia equivalente al tiempo de respuesta humana, pero evita errores irreversibles.
El esquema de cada herramienta debe ser validable por máquina. Si el agente devuelve un JSON malformado como argumento de herramienta, debe detectarlo y reintentar — no ignorarlo silenciosamente. Esto no es un caso extremo; en producción es una fuente habitual de problemas.
Paso 3: Elija una arquitectura simple
Para el primer agente recomendamos el bucle ReAct — Reason, Act, Observe en un grafo simple. El motivo es sencillo: es la arquitectura más fácil de depurar.
Si ha leído el artículo sobre Arquitecturas de agentes de IA, sabe que existen patrones más sofisticados (Plan-and-Execute, Reflexion, multiagente). Son válidos — pero no para el primer proyecto. Cada paso adicional es una fuente potencial de error adicional y otra capa donde no se sabe qué está pasando.
Stack recomendado concreto:
- Framework:
LangGraph— basado en grafos, estado explícito, checkpointing integrado; validado en producción para despliegues enterprise - Modelo: empiece con un modelo barato y rápido (tier Haiku, tier Flash o un modelo local vía
Ollama); los modelos frontier (Opus, GPT) actívelos solo cuando la lógica básica funcione - Memoria: contexto a corto plazo en el estado del grafo; para un horizonte más largo, base de datos vectorial — pero solo si el primer caso de uso lo requiere realmente
El error grande al principio: elegir el modelo más potente y más caro porque "queremos los mejores resultados", y luego sorprenderse de que los costes sean insostenibles. El modelo es fácil de cambiar. La arquitectura y las herramientas son mucho más difíciles.
Un detalle práctico: configure un número máximo de pasos del bucle. Un agente sin límite puede entrar en un ciclo ante una entrada inesperada y consumir miles de tokens durante la noche. Un valor de 10–15 pasos por tarea es un punto de partida razonable para la mayoría de casos de uso.
Paso 4: Guardrails — no como filtro, sino como arquitectura
Los guardrails para agentes de IA son un tema que se subestima en el primer proyecto y que luego hay que recuperar a golpes.
Los guardrails no son solo un filtro de salida ("comprueba que la respuesta no contenga nada malo"). Los guardrails son una arquitectura de múltiples capas:
- 1.Validación de entrada — ¿qué entra al agente? ¿Es el formato que el agente espera? ¿Contiene la entrada instrucciones potencialmente peligrosas?
- 2.Clasificación de intención — si el agente recibe texto libre de usuarios, hay que clasificar la intención antes de pasarla al bucle del agente
- 3.Scope de permisos de herramientas — como se describió antes: cada herramienta tiene sus permisos
- 4.HITL gate para operaciones de escritura — las acciones críticas requieren confirmación humana
- 5.Filtro de salida — control semántico de la respuesta antes de enviarla
Para el primer agente en un entorno interno (no expuesto a usuarios externos) basta con empezar por los puntos 3 y 4. La validación de entrada y la clasificación de intención son imprescindibles si el agente recibe inputs de fuentes externas o desconocidas.
La prompt injection — es decir, el ataque en el que contenido malicioso en la entrada convence al agente de hacer algo distinto a lo previsto — es, según el OWASP LLM Top 10, la amenaza de seguridad más frecuente en aplicaciones de IA. Si su agente carga cualquier contenido externo (emails, páginas web, archivos de clientes), debe tener en cuenta activamente este riesgo.
Paso 5: Observability — sin esto no pase el agente a producción
Esta es una regla de la que no cedemos: un agente sin observability no es un agente de producción. Es un proof-of-concept.
Lo que necesita saber concretamente sobre cada ejecución del agente:
- Cuál fue la entrada y la salida
- Cuántos pasos del bucle se ejecutaron
- Qué herramientas se llamaron, con qué argumentos y qué devolvieron
- Dónde ocurrió el error (si ocurrió) y por qué el agente eligió una acción concreta
Herramientas que proporcionan esto: Langfuse (agnóstico al framework, self-hostable), LangSmith (integración profunda con LangGraph), Arize Phoenix (basado en OpenTelemetry, métricas de eval avanzadas). La observability de agentes de IA es hoy un área madura — no hay razón para construirlo desde cero.
Beneficio concreto en la práctica: en un despliegue para un cliente del sector logístico, detectamos mediante trazas que el agente categorizaba correctamente el 94% de los casos, pero en una categoría concreta llamaba consistentemente a una herramienta con un argumento erróneo. Sin observability, lo habríamos descubierto solo después de decenas de registros incorrectos en el sistema.
Paso 6: Eval — ¿cómo sabe que el agente funciona correctamente?
El eval (evaluación) es el paso que con más frecuencia se salta en el primer proyecto. La consecuencia: no sabemos si un cambio en el prompt, en el modelo o en las herramientas ha mejorado o empeorado las cosas.
Para el primer agente basta con un eval harness sencillo:
- Construya 20–50 casos de prueba con entrada definida y salida o acción esperada
- Ejecute el agente sobre esos casos después de cada cambio importante
- Monitorice al menos dos métricas: task completion rate (¿completó el agente la tarea?) y tool call accuracy (¿llamó el agente a las herramientas correctas con los argumentos correctos?)
No es necesario desplegar de inmediato un framework de eval complejo. Un script que ejecute el agente sobre el conjunto de prueba e imprima la puntuación es mejor que ningún eval. A medida que el sistema crece, la evaluación de aplicaciones RAG y LLM se vuelve más sofisticada — pero la base sigue siendo la misma: tener un conjunto de referencia y medir frente a él.
Qué evitar con el primer agente
De la experiencia en despliegues — estos son los errores más frecuentes que alargan el proyecto o lo bloquean:
Demasiadas herramientas desde el principio. Cada herramienta es una fuente de fallo adicional. Empiece con tres y expanda según necesidad real.
Ningún HITL para operaciones de escritura. La primera escritura que el agente realice incorrectamente sin posibilidad de captura generalmente pone fin al proyecto. Añada aprobación — puede eliminarse más adelante cuando tenga confianza en la fiabilidad.
Sistema multiagente como primer paso. El sistema multiagente en la práctica tiene sentido cuando un solo agente no es suficiente. Pero cuando todavía no sabemos qué hace mal un agente, añadir más agentes amplía la confusión, no la reduce.
El modelo como variable principal. Lo hemos escuchado varias veces: "Probaremos GPT-5, seguro que resuelve los problemas." En la práctica, la mayoría de los problemas vienen de una definición deficiente de herramientas, validación ausente o scope poco claro — no de la calidad del modelo. Resuelva la arquitectura, no el modelo.
Sin límites máximos. Un agente sin límite en el número de pasos, sin timeout y sin alerta de costes puede generar miles de llamadas durante la noche. Configure los límites desde el primer día.
Expansión progresiva: del prototipo a la producción
El primer agente funcional es un prototipo. El camino hacia la producción requiere varios pasos explícitos:
- 1.Eval sobre el conjunto de prueba — al menos 20–50 casos, task completion rate > 85% como condición mínima
- 2.Shadow mode — el agente corre en paralelo al proceso existente pero no interviene; se comparan los resultados
- 3.HITL para todas las operaciones de escritura — en la primera fase de producción, una persona aprueba cada acción
- 4.Observability activa — las trazas deben estar disponibles desde el primer día en producción
- 5.Reducción progresiva del HITL — tras 2–4 semanas con buenas métricas, puede eliminar el HITL para acciones de bajo riesgo
La expansión del scope (nuevas herramientas, nuevos casos de uso) es siempre una iteración del mismo ciclo: definir, probar en shadow mode, desplegar progresivamente, monitorizar métricas.
Preguntas frecuentes
¿Qué modelo elegir para el primer agente?
Empiece con un modelo barato y rápido — tier Haiku o Flash, o un modelo open-weight local como Ollama con Qwen o Llama. Los modelos frontier (Opus, GPT) actívelos solo cuando la lógica básica funcione y sepa exactamente dónde el modelo no da la talla. Cambiar el modelo es fácil; reparar la arquitectura, no.
¿Cuántas herramientas puede tener el primer agente?
Recomendamos un máximo de 3–5 herramientas en la primera versión. Cada herramienta es una fuente de fallo adicional y otra cosa que hay que testear. Es mejor tener tres herramientas bien testeadas que diez con límites poco claros.
¿Es obligatorio usar LangGraph u otro framework?
No es obligatorio. El código propio ofrece control total y a veces menos abstracción de la necesaria. El motivo por el que recomendamos LangGraph para los primeros despliegues en producción es el checkpointing integrado, el interrupt() para HITL y las buenas trazas — de lo contrario hay que construir todo eso desde cero.
¿Cuándo tiene sentido pasar a una arquitectura multiagente?
Cuando un solo agente no da abasto de forma consistente — normalmente por un scope de tarea demasiado amplio o por la necesidad de procesamiento paralelo. Si el agente ejecuta secuencialmente 15 pasos donde algunos podrían correr en paralelo, es hora del enfoque multiagente. Pero esto es el segundo o tercer proyecto, no el primero.
¿Cómo estimar los costes del agente en producción?
La variable clave no es solo el precio del modelo, sino también el número de pasos del bucle por tarea y la retry rate. Si el agente hace de media 5 pasos y la retry rate es del 12%, el número real de llamadas es un 12% mayor — y en pipelines de múltiples etapas este overhead se multiplica aún más. Un marco más detallado para estimar costes lo encontrará en el artículo Costes del agente de IA en producción.
*MP Industrial Solutions ayuda a las empresas a definir, diseñar y desplegar su primer agente de IA — desde la selección del caso de uso hasta la arquitectura técnica y el despliegue en producción con observability y guardrails. Si está considerando el primer paso, con gusto analizamos su caso concreto en una consulta inicial.*