En la parte 1 vimos por qué los estudiantes y los profesionales en activo deberían entender los sistemas agénticos, y por qué aprender un framework concreto no es la verdadera competencia profesional.
Ahora pasamos del porqué al cómo.
Construir un primer agente puede ser sorprendentemente fácil.
Le das un objetivo a un modelo, conectas una o dos herramientas y dejas que decida cuándo usarlas.
La pregunta difícil viene después:
¿Cómo conviertes esa demo que funciona en un sistema en el que de verdad puedas confiar?
Ahí empieza la ingeniería agéntica.
Empieza por un problema útil
Imagina que queremos construir un asistente de investigación.
El usuario pregunta:
¿Qué ha cambiado esta semana en seguridad de la IA? Busca fuentes fiables y prepara un breve resumen con citas.
Una versión sencilla podría ser así:
Pregunta → modelo de IA → herramienta de búsqueda → fuentes → respuesta
Eso ya es más que un chatbot normal, porque el modelo puede decidir cuándo necesita información externa y usar una herramienta para obtenerla.
Para un primer proyecto, es suficiente.
No empieces creando un agente investigador, un agente revisor, un agente de citas, un agente redactor y un agente coordinador.
Primero demuestra que un solo agente puede resolver bien un problema útil.
Este principio importa porque cada agente, herramienta y flujo de trabajo adicional añade más puntos donde algo puede fallar.
Paso 1: dale herramientas al agente
Sin herramientas, un modelo puede, sobre todo, razonar con la información que ya tiene a su alcance.
Las herramientas le permiten actuar.
Nuestro asistente de investigación podría tener:
- una herramienta de búsqueda web
- una herramienta de lectura de páginas
- una función que guarda las fuentes útiles
El bucle básico queda así:
Entender el objetivo
→ decidir qué información falta
→ elegir una herramienta
→ usarla
→ observar el resultado
→ decidir qué hacer a continuación
Este bucle sencillo está en el centro de muchos sistemas agénticos.
Pero el diseño de las herramientas importa.
Una herramienta debe tener un propósito claro, entradas predecibles y resultados comprensibles.
Si un agente tiene 50 herramientas con nombres vagos, decidir cuál usar se vuelve más difícil.
Un conjunto más reducido de herramientas bien diseñadas suele ser mejor que darle a un agente acceso a todo.
Las recomendaciones de ingeniería actuales de Anthropic lo dicen de forma directa: la calidad de las herramientas y unos límites claros entre ellas pueden afectar de manera significativa al rendimiento del agente.
Paso 2: añade estado solo cuando el sistema lo necesite
Supongamos que nuestro asistente de investigación consulta cinco fuentes.
Ahora necesita recordar:
- qué ha buscado ya
- qué fuentes ha aceptado
- qué afirmaciones necesitan aún evidencia
- a qué fase de la tarea ha llegado
Eso es el estado.
El estado responde a la pregunta:
¿Qué está pasando ahora mismo en esta tarea concreta?
La memoria está relacionada, pero es distinta.
La memoria puede conservar información útil de una tarea a otra, como las fuentes preferidas de un usuario o sus preferencias de investigación habituales.
Para quien empieza, basta con mantener esta distinción sencilla:
Estado = lo que esta tarea necesita para continuar.
Memoria = información útil más allá de esta tarea.
No añadas memoria permanente solo porque un framework de agentes lo permita.
Guarda información porque el sistema realmente la necesita.
Paso 3: decide qué debe controlar la IA
Esta es una de las decisiones de diseño más importantes.
Algunos procesos son predecibles.
Por ejemplo:
buscar → extraer fuentes → validar citas → redactar el resumen
Si esas fases deben producirse siempre en ese orden, un flujo de trabajo normal puede ser mejor que dejar que el modelo invente el proceso cada vez.
Otros problemas son menos predecibles.
Un agente de investigación puede descubrir que una fuente contradice a otra y decidir que necesita hacer otra búsqueda.
Ahí es donde resulta útil que las decisiones las tome el modelo.
Un sistema práctico suele combinar ambas cosas.
El flujo de trabajo controla lo que debe ocurrir.
El agente decide lo que requiere criterio.
Esta distinción ayuda a evitar una autonomía innecesaria.
Las recomendaciones actuales de Microsoft van en la misma línea: usa patrones más sencillos cuando funcionen, y usa flujos de trabajo cuando importen un orden de ejecución explícito y los puntos de control.
Paso 4: haz que el fallo forme parte del diseño
Una demo suele dar por hecho que todo funciona.
En producción no es así.
La API de búsqueda puede fallar.
Un sitio web puede no estar disponible.
Una herramienta puede devolver información incompleta.
El modelo puede elegir la herramienta equivocada.
Una tarea de larga duración puede detenerse a mitad de camino.
Un sistema agéntico fiable necesita respuestas a preguntas como estas:
- ¿Debe reintentarse este paso?
- ¿Cuántas veces?
- ¿Puede continuar la tarea sin esta herramienta?
- ¿Debe volver al último punto de control correcto?
- ¿Cuándo debe detenerse?
- ¿Cuándo debe consultar a una persona?
En nuestro asistente de investigación, una consulta fallida a una fuente no debería echar por tierra necesariamente toda la tarea.
El sistema podría registrar el fallo, probar otra fuente y continuar.
Pero si no puede verificar una afirmación crítica, no debería inventarse una sin decir nada.
Esa es la diferencia entre recuperarse de un fallo y ocultar un fallo.
Paso 5: evalúa el resultado
Aquí es donde muchos tutoriales de agentes terminan demasiado pronto.
El agente ha dado una respuesta.
Pero ¿era buena?
En nuestro asistente de investigación, podríamos evaluar:
- ¿Eran pertinentes las fuentes?
- ¿Estaban respaldadas las afirmaciones?
- ¿Estaban las citas asociadas a las afirmaciones correctas?
- ¿Usó fuentes de referencia cuando las había?
- ¿Se inventó algo?
- ¿Terminó con un costo y un tiempo aceptables?
Eso es una evaluación, o eval.
El software tradicional suele darnos una respuesta sencilla:
prueba superada / prueba fallida
Los sistemas agénticos son más difíciles porque algunas salidas no son perfectamente deterministas.
Eso no significa que no se puedan probar.
Significa que tenemos que definir cómo es un buen resultado.
Las recomendaciones actuales de Anthropic sobre la evaluación de agentes lo dejan claro: como los agentes actúan a lo largo de varios pasos, modifican el estado y reaccionan a resultados intermedios, la evaluación tiene que examinar el comportamiento del sistema y no solo su frase final.
Sobre todo para los estudiantes, aprender a evaluar pronto es más útil que añadir otro framework al currículum.
Paso 6: haz que el agente sea observable
Si la respuesta final es incorrecta, necesitas saber por qué.
¿Entendió mal la pregunta el modelo?
¿Eligió una fuente poco fiable?
¿Falló una herramienta?
¿Recibió la información correcta y tomó la decisión equivocada?
Eso requiere observabilidad.
Una traza útil podría mostrar:
objetivo
→ decisión del modelo
→ herramienta elegida
→ resultado de la herramienta
→ siguiente decisión
→ salida final
Las recomendaciones actuales de AWS para sistemas agénticos van más allá y tratan las invocaciones de herramientas, la ejecución de flujos de trabajo, el estado y el comportamiento del agente como partes importantes de la observabilidad en producción.
Para aprender, recuerda esta regla sencilla:
Si un agente puede realizar una acción, deberías poder reconstruir lo que ocurrió.
Sin eso, depurar se convierte en un ejercicio de adivinación.
Paso 7: decide dónde deben intervenir las personas
Que intervenga una persona no significa que el agente haya fallado.
A veces la aprobación humana forma parte del diseño correcto.
A nuestro asistente de investigación se le puede permitir buscar y resumir de forma automática.
Pero imagina otro agente que puede:
- eliminar recursos en la nube
- transferir dinero
- enviar un correo electrónico externo
- aprobar un reembolso
- cambiar la configuración de producción
Esas acciones tienen consecuencias.
Un buen diseño puede permitir que el agente prepare la acción, pero que se detenga antes de ejecutarla.
El agente propone → una persona aprueba → el sistema ejecuta
La pregunta importante no es:
¿Puede la IA hacer esto?
Es esta:
¿Debería permitirse que la IA haga esto sin otro punto de decisión?
La ingeniería agéntica consiste, en parte, en decidir dónde debe detenerse la autonomía. Para ver un ejemplo concreto de cómo trazar esa línea, consulta nuestra Perspectiva sobre por qué la autonomía no es lo mismo que la confianza.
Paso 8: añade seguridad antes de añadir más autonomía
Cada herramienta aumenta la capacidad.
También puede aumentar el riesgo.
Si un agente puede acceder a una base de datos, una cuenta en la nube, un sistema de archivos o una API externa, pregúntate:
- ¿Qué identidad está usando?
- ¿A qué puede acceder esa identidad?
- ¿Tiene más permisos de los que necesita esta tarea?
- ¿Están protegidas las credenciales?
- ¿Puede un contenido que no es de confianza influir en sus acciones?
- ¿Están restringidas las operaciones de alto impacto?
No le des a un agente una autoridad amplia solo porque configurar un acceso acotado cuesta más esfuerzo.
El principio es el mismo que en la seguridad de sistemas tradicional:
Da al sistema solo el acceso que requiere su trabajo.
Los sistemas agénticos hacen que esto sea más importante, porque el propio modelo puede decidir qué acción permitida realizar a continuación.
TechiesJournal trata por separado la identidad de los agentes y la seguridad, así que no repetiremos ese tema aquí. Pero cualquiera que construya agentes reales debe tratar la seguridad como parte de la arquitectura, no como una función que se añade más adelante.
¿Dónde encaja MCP?
A medida que tu agente empiece a usar más sistemas externos, te encontrarás con Model Context Protocol, o MCP. Nuestra guía sobre cómo MCP, A2A y WebMCP conectan agentes (en inglés) trata el protocolo en sí.
MCP ofrece una forma estándar para que las aplicaciones de IA descubran herramientas y recursos externos e interactúen con ellos.
Eso puede reducir el trabajo de integración a medida.
Pero MCP no sustituye los fundamentos que hemos visto.
Sigues teniendo que pensar en:
- qué herramientas deben existir
- a qué puede acceder el agente
- la autenticación
- los permisos
- la calidad de las herramientas
- la gestión de errores
- la evaluación
Aprende MCP cuando ya entiendas la llamada básica a herramientas.
De lo contrario, puede que entiendas el protocolo sin entender el sistema que intentas construir.
¿Cuándo necesitas varios agentes?
Más tarde de lo que sugieren muchos tutoriales.
Supongamos que nuestro asistente de investigación funciona bien, pero descubrimos que la verificación de fuentes requiere un proceso realmente distinto.
Con el tiempo, podríamos separar responsabilidades:
Agente de investigación → revisor de evidencias → redactor
Eso puede ser útil.
Pero el diseño multiagente también añade:
- más llamadas al modelo
- más estado
- más coordinación
- más latencia
- más costo
- más formas de fallar
Las recomendaciones actuales de Anthropic y de Microsoft plantean, en esencia, la misma idea de arquitectura: usa el patrón más sencillo que resuelva el problema, y añade orquestación o varios agentes cuando la tarea realmente lo requiera.
Así que, antes de crear otro agente, pregúntate:
¿Qué problema resuelve este agente adicional que no puedan resolver un solo agente o un flujo de trabajo normal?
Si no hay una respuesta clara, no lo añadas.
Del agente al sistema agéntico
Nuestro asistente de investigación original era sencillo:
Pregunta → Modelo → Búsqueda → Respuesta
Una versión más fiable tiene ahora otro aspecto:
Objetivo
↓
Agente
↓
Herramientas
↓
Estado
↓
Evidencias
↓
Evaluación
↓
Punto de control / decisión humana cuando haga falta
↓
Resultado
Alrededor de todo eso están:
seguridad + observabilidad + recuperación ante fallos
Texto alternativo accesible para esta figura
Tres etapas de crecimiento. Un agente sencillo es un modelo con una herramienta. Una aplicación útil es un modelo con herramientas y estado. Un sistema fiable conserva el modelo, las herramientas y el estado, y añade evaluación, observabilidad, recuperación, seguridad y control humano. Los elementos añadidos se marcan con un signo más y un relleno cálido, de modo que la progresión no depende solo del color.
Esa es la transición importante.
El modelo sigue siendo importante.
Pero el modelo ya no es toda la aplicación.
Por eso construir sistemas agénticos se está convirtiendo cada vez más en una disciplina de ingeniería de software y no solo en una habilidad para escribir prompts.
¿Qué deberías construir a continuación?
Si estás aprendiendo, no intentes implementar de golpe todo lo que aparece en este artículo.
Construye por capas.
Primero: un agente y una herramienta útil.
Después: añade estado.
Después: define cómo es un resultado satisfactorio.
Después: añade trazabilidad y gestión de fallos.
Después: añade aprobación humana si el agente puede realizar acciones con consecuencias.
Solo después deberías explorar orquestaciones complejas, arquitecturas muy basadas en MCP o varios agentes.
El mejor proyecto de aprendizaje no es el que tiene más agentes.
Es aquel en el que puedes explicar:
qué intenta conseguir el agente,
qué puede hacer,
qué puede salir mal,
cómo detectas los fallos
y por qué se debería confiar en el resultado final.
Esa es la diferencia entre construir una demo de agente y construir un sistema agéntico.
Continúa la serie Construir sistemas agénticos
Parte 1: anterior. Construir sistemas agénticos: qué deberían aprender ahora estudiantes y profesionales en activo. Empieza aquí si quieres decidir si los sistemas agénticos merecen tu tiempo de aprendizaje y hasta qué punto tu puesto necesita esta competencia.
Parte 2: estás aquí. Construir sistemas agénticos: de tu primer agente a un sistema fiable. Entiende el recorrido técnico que va de un agente sencillo que usa herramientas a un sistema con estado, evaluación, observabilidad, seguridad y recuperación.
Parte 3: siguiente. Aprender IA agéntica: cursos gratuitos, laboratorios prácticos y certificaciones. Compararemos los recursos de aprendizaje actuales de AWS, Microsoft, Google, OpenAI, Anthropic y otros, y distinguiremos entre formación gratuita, certificados de cursos, credenciales prácticas y certificaciones profesionales.
Fuentes y lecturas adicionales
Revisión de fuentes: 2 de octubre de 2026.
- Anthropic — Building Effective Agents. Útil para entender la diferencia entre flujos de trabajo y agentes, por qué las arquitecturas más sencillas deben ir primero y cuándo está justificada una autonomía adicional.
- Anthropic — Writing Effective Tools for Agents. Explica por qué la calidad de las herramientas, unas interfaces claras y la evaluación importan para el rendimiento de los agentes.
- Anthropic — Demystifying Evals for AI Agents. Una explicación práctica de por qué el comportamiento de un agente en varios pasos necesita una evaluación sistemática.
- Microsoft — Agent Framework. Documentación actual que avanza desde un primer agente y sus herramientas hasta el estado, la memoria, los flujos de trabajo, la intervención humana, los puntos de control y el alojamiento.
- AWS — Agentic AI Lens. Recomendaciones útiles para producción que abarcan la observabilidad, el estado, la resiliencia, la seguridad y el comportamiento operativo de los sistemas agénticos.
- OpenAI — Agents SDK documentation. Recursos actuales para desarrolladores que abarcan herramientas, estado, orquestación, salvaguardas (guardrails), revisión humana, trazabilidad y evaluaciones.