El desarrollo de agentes de inteligencia artificial se está convirtiendo en una de las áreas más interesantes dentro del desarrollo de software con IA.
Pero existe un problema habitual: la cantidad de herramientas y tecnologías disponibles puede resultar abrumadora.
Python, OpenAI GPT, Claude, Gemini, Llama, LangChain, LangGraph, LlamaIndex, RAG, embeddings, bases vectoriales, MCP, Tool Calling, Docker…
¿Con cuál conviene empezar?
La respuesta no debería basarse tanto en cuánto tiempo dedicar a cada tecnología, sino en qué conocimientos dependen de otros conocimientos.
Por eso, este roadmap para aprender desarrollo de agentes IA no está organizado en semanas o meses. Está organizado siguiendo una secuencia lógica de aprendizaje, comenzando por aquello que resulta indispensable para entender lo que ocurre y avanzando progresivamente hasta poder construir agentes capaces de utilizar herramientas, consultar información, recordar contexto, interactuar con sistemas externos y ejecutarse en producción.
El objetivo final no debería ser simplemente aprender una determinada librería.
El verdadero objetivo debería ser comprender cómo funciona un agente de IA y ser capaz de construirlo incluso cuando cambien las herramientas disponibles.
¿Qué es un agente de IA?
Antes de comenzar con tecnologías concretas conviene entender qué es realmente un agente de inteligencia artificial.
Una aplicación tradicional basada en un modelo de lenguaje puede tener un flujo relativamente simple:
Usuario
↓
Prompt
↓
LLM
↓
RespuestaUn agente introduce algo mucho más interesante: la capacidad de decidir qué acciones realizar para alcanzar un objetivo.
Un flujo simplificado podría ser:
Usuario
↓
Objetivo
↓
LLM
↓
Analiza qué necesita
↓
Selecciona una herramienta
↓
Ejecuta una acción
↓
Obtiene información
↓
Evalúa el resultado
↓
Continúa o respondeLa diferencia es importante.
El modelo deja de ser únicamente un generador de texto y pasa a convertirse en una pieza dentro de un sistema capaz de:
- consultar una base de datos;
- llamar una API;
- buscar documentos;
- ejecutar funciones;
- utilizar herramientas;
- mantener estado;
- recordar información;
- coordinar diferentes procesos;
- decidir qué acción ejecutar a continuación.
Una forma sencilla de visualizar la arquitectura sería:
LLM
│
razona / selecciona
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Herramientas Memoria Datos
│ │ │
↓ ↓ ↓
APIs PostgreSQL RAG
MCP Vector DB Documentos
FuncionesEl LLM es importante, pero el agente es todo el sistema que lo rodea.
1. Fundamentos de programación: la base de todo el roadmap
El primer nivel para aprender desarrollo de agentes IA sigue siendo desarrollo de software.
Antes de estudiar LangChain, LangGraph o cualquier framework de agentes, conviene manejar correctamente los fundamentos.
Python
Si el objetivo principal es trabajar con agentes de inteligencia artificial, Python debería ser una de las principales prioridades.
Gran parte del ecosistema relacionado con inteligencia artificial utiliza Python y prácticamente todos los principales proveedores de modelos ofrecen SDK compatibles.
No hace falta convertirse inmediatamente en un experto, pero sí dominar conceptos como:
- variables y tipos de datos;
- listas y diccionarios;
- funciones;
- clases;
- excepciones;
- módulos;
- paquetes;
- entornos virtuales;
- lectura y escritura de archivos;
- JSON;
- variables de entorno;
- programación asíncrona;
- consumo de APIs.
También resulta especialmente importante comprender:
async
awaitLos agentes suelen realizar múltiples llamadas a servicios externos, por lo que comprender la programación asíncrona puede resultar muy útil.
JavaScript y TypeScript
JavaScript y TypeScript también son tecnologías interesantes, especialmente cuando los agentes deben integrarse dentro de aplicaciones web.
Sin embargo, no considero necesario dominar simultáneamente Python y JavaScript para comenzar.
Una estrategia posible sería:
Python → lenguaje principal para IA
JavaScript / TypeScript → aplicaciones web e interfacesSi ya se domina JavaScript o TypeScript tampoco existe ninguna obligación de abandonar ese ecosistema.
Lo importante es dominar suficientemente bien al menos un lenguaje de programación.
Git
Git debería incorporarse desde el principio del aprendizaje.
Algunos conceptos esenciales son:
- repositorios;
- commits;
- ramas;
- merge;
- pull requests;
.gitignore;- manejo adecuado de secretos;
- versionado.
Esto será especialmente importante cuando nuestros experimentos comiencen a convertirse en aplicaciones reales.
2. HTTP, APIs y JSON: fundamentos que no deberían omitirse
Antes incluso de estudiar frameworks de agentes recomiendo comprender correctamente cómo se comunican las aplicaciones.
Es fundamental conocer operaciones HTTP como:
GET
POST
PUT
PATCH
DELETETambién deberíamos comprender:
- headers;
- request body;
- query parameters;
- códigos HTTP;
- autenticación;
- tokens;
- JSON;
- REST APIs.
¿Por qué resulta tan importante?
Porque prácticamente todo lo que hará un agente fuera del propio modelo implicará comunicarse con algún sistema.
Por ejemplo:
Agente
↓
Consulta información
↓
API externa
↓
JSON
↓
Agente interpreta el resultadoCuando estos conceptos se comprenden correctamente, tecnologías como Tool Calling, Function Calling y MCP resultan mucho más sencillas de entender.
3. Comprender cómo funcionan los LLM
Una vez consolidados los fundamentos, el siguiente paso es trabajar directamente con Large Language Models o LLM.
Algunas opciones importantes dentro del ecosistema actual son:
- OpenAI GPT;
- Claude;
- Gemini;
- Llama.
No es necesario aprender profundamente todos los proveedores desde el principio.
Conviene elegir inicialmente uno y aprender correctamente cómo utilizar su API.
Aplicación
↓
API del proveedor
↓
LLM
↓
RespuestaSin embargo, existen conceptos que deberían comprenderse independientemente del proveedor elegido.
Tokens
Los modelos procesan información mediante tokens.
Esto afecta directamente:
- el tamaño del contexto;
- el costo;
- la velocidad;
- la cantidad de información procesada.
Context Window
Cada modelo tiene un límite de información que puede manejar dentro de su contexto.
Comprender este concepto será fundamental cuando posteriormente trabajemos con:
- memoria;
- documentos;
- RAG;
- conversaciones extensas.
System Prompt
El System Prompt permite establecer instrucciones generales que orientan el comportamiento del modelo.
Por ejemplo:
Eres un asistente especializado en legislación administrativa.
Responde únicamente utilizando las fuentes proporcionadas.Structured Outputs
Uno de los conceptos más importantes para desarrollar agentes consiste en conseguir que el modelo genere información estructurada.
Por ejemplo:
{
"accion": "consultar_cliente",
"cliente_id": 152
}Esto permite que nuestra aplicación utilice programáticamente la respuesta del modelo.
Aquí comienza una de las transiciones más importantes entre un chatbot tradicional y un agente.
4. Prompt Engineering
El Prompt Engineering continúa siendo una habilidad relevante.
Hay que aprender a definir correctamente:
- contexto;
- objetivo;
- restricciones;
- formato esperado;
- ejemplos;
- criterios de comportamiento.
Podemos pensar la estructura de un prompt de esta manera:
ROL
↓
OBJETIVO
↓
CONTEXTO
↓
RESTRICCIONES
↓
HERRAMIENTAS DISPONIBLES
↓
FORMATO DE RESPUESTASin embargo, existe un error frecuente: pensar que desarrollar agentes consiste principalmente en escribir buenos prompts.
No es así.
Un agente robusto necesita bastante más ingeniería de software que Prompt Engineering.
A medida que los sistemas aumentan en complejidad, herramientas, estado, APIs, permisos, evaluación, seguridad y observabilidad adquieren cada vez más importancia.
5. Function Calling y Tool Calling: donde realmente comienzan los agentes
Este es probablemente uno de los puntos más importantes de todo el roadmap para aprender agentes IA.
Supongamos que tenemos un asistente conectado a un sistema de empleados.
El usuario pregunta:
¿Cuántos días de licencia tiene disponibles Juan Pérez?
El modelo por sí solo no conoce esa información.
Pero podemos darle acceso a una función:
consultar_licencias(empleado_id)Entonces el flujo podría ser:
Usuario
↓
Pregunta
↓
LLM
↓
Decide utilizar una herramienta
↓
consultar_licencias()
↓
Sistema de personal
↓
Resultado
↓
LLM
↓
Respuesta al usuarioAquí aparece una característica fundamental de los agentes:
El modelo no necesita conocer toda la información. Necesita saber qué herramienta utilizar para conseguirla.
Esto abre enormes posibilidades.
Un agente podría disponer de herramientas como:
buscar_expediente()
consultar_empleado()
crear_ticket()
consultar_clima()
enviar_notificacion()
buscar_documento()
crear_reporte()
consultar_stock()Cada herramienta amplía las capacidades del agente.
6. Aprender a diseñar las herramientas de un agente
Una habilidad que merece especial atención es el diseño de herramientas.
No conviene ofrecer al modelo una función gigantesca capaz de realizar decenas de operaciones.
Por ejemplo, es preferible disponer de:
buscar_cliente()
obtener_facturas()
consultar_deuda()
registrar_pago()en lugar de:
gestionar_todo_el_sistema()Las herramientas deberían ser:
- específicas;
- fáciles de describir;
- predecibles;
- seguras;
- validables;
- auditables.
También deberían tener parámetros claramente definidos.
{
"name": "buscar_expediente",
"description": "Busca un expediente administrativo por número",
"parameters": {
"numero": "string"
}
}Cuanto mejor definidas estén las herramientas, mejores decisiones podrá tomar el agente.
7. RAG: permitir que el agente consulte conocimiento propio
Uno de los siguientes conceptos fundamentales es RAG o Retrieval-Augmented Generation.
Los modelos de lenguaje poseen conocimiento general, pero las organizaciones normalmente necesitan trabajar con información propia.
Por ejemplo:
- documentos internos;
- manuales;
- resoluciones;
- contratos;
- expedientes;
- normativa;
- documentación técnica;
- procedimientos.
Un sistema RAG permite recuperar fragmentos relevantes de estas fuentes antes de consultar al modelo.
El flujo podría ser:
Usuario
↓
Pregunta
↓
Búsqueda semántica
↓
Documentos relevantes
↓
Contexto
↓
LLM
↓
RespuestaEsto permite construir sistemas capaces de responder preguntas utilizando información específica de una organización.
8. Embeddings: comprender la base de la búsqueda semántica
Para comprender RAG es importante conocer el concepto de embeddings.
Un embedding transforma información en una representación numérica.
Conceptualmente:
"manual de vacaciones"
↓
modelo de embeddings
↓
[0.13, -0.82, 0.44, ...]Textos con significados similares terminan relativamente próximos dentro de ese espacio matemático.
Esto permite realizar búsquedas semánticas.
Por ejemplo, una persona podría preguntar:
¿Cuántos días me corresponden por nacimiento de un hijo?
aunque el documento contenga una sección denominada:
Licencia por paternidad.
Una búsqueda tradicional basada exclusivamente en palabras podría tener dificultades para establecer esa relación.
Una búsqueda semántica puede encontrarla gracias a la similitud de significado.
9. Bases de datos vectoriales
Para almacenar y buscar embeddings aparecen las denominadas bases de datos vectoriales.
Entre las tecnologías que conviene conocer se encuentran:
- Pinecone;
- ChromaDB;
- FAISS;
- PostgreSQL con capacidades vectoriales.
No es necesario aprenderlas todas.
La prioridad debería estar en comprender el concepto y el proceso.
Documento
↓
Fragmentación
↓
Chunks
↓
Embeddings
↓
Base vectorialPosteriormente:
Pregunta
↓
Embedding
↓
Búsqueda por similitud
↓
Fragmentos relevantes
↓
LLMUna vez entendido este mecanismo, cambiar de tecnología resulta mucho más sencillo.
10. PostgreSQL sigue siendo fundamental
Trabajar con inteligencia artificial no elimina la necesidad de utilizar bases de datos tradicionales.
Todo lo contrario.
Los agentes necesitan guardar información estructurada como:
- usuarios;
- sesiones;
- configuraciones;
- permisos;
- historial;
- auditorías;
- tareas;
- estado;
- resultados;
- costos;
- logs.
Por eso recomiendo estudiar PostgreSQL independientemente de las bases vectoriales.
Un sistema real podría combinar:
PostgreSQL
+
búsqueda vectorial
+
LLMLa inteligencia artificial complementa la arquitectura tradicional del software. No la reemplaza.
11. Memoria: conseguir que el agente mantenga contexto
Otro concepto central es la memoria de los agentes de IA.
Un agente puede necesitar recordar información dentro de una conversación.
Por ejemplo:
Usuario:
Necesito analizar el expediente 2354.
Agente:
De acuerdo.
Usuario:
¿Quién lo inició?El agente necesita comprender que la segunda pregunta continúa haciendo referencia al expediente mencionado anteriormente.
Memoria de corto plazo
Mantiene información durante la conversación actual.
Memoria de largo plazo
Permite conservar determinada información entre distintas sesiones.
Memoria semántica
Puede utilizarse para almacenar hechos o conocimientos.
Memoria episódica
Puede registrar experiencias o interacciones anteriores.
Un error frecuente consiste simplemente en enviar permanentemente todo el historial de conversación al modelo.
Esto puede generar:
- contextos demasiado grandes;
- costos mayores;
- respuestas más lentas;
- información irrelevante.
Diseñar correctamente la memoria de un agente es un problema de arquitectura.
12. REST, GraphQL y APIs externas
Una vez comprendido Tool Calling, conectar nuestros agentes con APIs resulta mucho más natural.
REST continúa siendo fundamental.
Un agente podría utilizar operaciones como:
GET /empleados/123o:
POST /expedientesGraphQL también puede resultar interesante cuando existen modelos de datos complejos y queremos consultar únicamente campos determinados.
Lo importante no es que el agente tenga acceso indiscriminado a todos los sistemas.
La arquitectura debería permitir que trabaje mediante interfaces controladas y claramente definidas.
13. MCP: conectar agentes con herramientas y fuentes externas
Otro concepto importante dentro del ecosistema moderno de agentes es MCP o Model Context Protocol.
MCP permite estructurar la forma en que aplicaciones basadas en modelos interactúan con herramientas, fuentes de datos y servicios externos.
Podemos imaginarlo como una capa de interoperabilidad.
Sin un protocolo común podríamos tener:
Agente → integración A → Git
Agente → integración B → PostgreSQL
Agente → integración C → Documentos
Agente → integración D → Sistema internoUtilizando una capa común, conceptualmente podríamos pensar en:
┌── Git
│
Agente → MCP ├── PostgreSQL
│
├── Documentos
│
└── APIsPor eso tiene sentido aprender MCP después de comprender APIs y Tool Calling.
De otra manera corremos el riesgo de aprender la implementación sin comprender el problema que intenta resolver.
14. Frameworks de agentes: aprenderlos después de los fundamentos
Después de entender estos conceptos resulta mucho más conveniente comenzar a estudiar frameworks especializados.
Entre los más importantes aparecen:
- LangChain;
- LangGraph;
- LlamaIndex.
Un error habitual consiste en empezar directamente por ellos.
Si comenzamos ejecutando algo similar a:
agent = create_agent(...)la aplicación puede funcionar, pero eso no significa necesariamente que comprendamos qué está sucediendo.
Los frameworks deberían ayudarnos a implementar conceptos que previamente conocemos.
15. LangChain
LangChain proporciona numerosas abstracciones para construir aplicaciones basadas en modelos de lenguaje.
Permite trabajar con elementos como:
- modelos;
- prompts;
- tools;
- retrievers;
- documentos;
- cadenas de procesamiento;
- agentes.
Resulta útil para conectar diferentes piezas del ecosistema.
Sin embargo, conviene intentar comprender siempre qué problema está resolviendo cada abstracción.
16. LangGraph y los agentes con estado
Cuando un agente comienza a tener varios pasos, decisiones y estados aparece un problema de orquestación.
Aquí resulta especialmente interesante un enfoque basado en grafos, como el utilizado por LangGraph.
En lugar de imaginar el agente como una simple cadena:
A → B → C → Dpodemos imaginarlo como un grafo:
┌── buscar información ──┐
│ ↓
Usuario → analizar → decidir → responder
│ ↑
└── herramienta ┘Este enfoque permite modelar:
- nodos;
- transiciones;
- estado;
- condiciones;
- ciclos;
- interrupciones;
- decisiones.
Puede resultar especialmente útil para construir agentes más predecibles y controlados.
17. LlamaIndex
LlamaIndex cobra especial importancia cuando nuestro problema está centrado en conectar modelos de lenguaje con información y documentos.
Puede utilizarse para:
- ingesta de documentos;
- indexación;
- retrieval;
- RAG;
- consultas sobre fuentes de conocimiento.
Si el objetivo consiste en construir asistentes que trabajen intensivamente con documentación, resulta una tecnología interesante para estudiar.
18. Workflows antes que autonomía total
Existe una idea especialmente importante cuando comenzamos a desarrollar agentes.
No siempre necesitamos un agente completamente autónomo.
Muchas veces resulta mejor construir un workflow controlado.
Por ejemplo:
1. Recibir documento
2. Clasificarlo
3. Extraer información
4. Validar campos
5. Consultar base
6. Generar respuestaEste flujo puede utilizar inteligencia artificial y continuar manteniendo una estructura determinística.
La autonomía debería introducirse únicamente cuando aporte un beneficio concreto.
Una buena regla es utilizar código para lo predecible y modelos de lenguaje para aquello que requiere interpretación.
19. Sistemas multiagente
Los sistemas multiagente son una de las áreas que mayor interés genera.
Podemos imaginar una arquitectura como:
Coordinador
│
┌──────────┼───────────┐
↓ ↓ ↓
Investigador Analista RedactorCada agente puede asumir una responsabilidad determinada.
Agente investigador
Busca información.
Agente analista
Evalúa y estructura los datos.
Agente redactor
Genera el resultado final.
Agente supervisor
Controla la calidad del trabajo realizado por otros agentes.
Sin embargo, utilizar múltiples agentes introduce complejidad:
- más llamadas al modelo;
- mayor costo;
- mayor latencia;
- más posibilidades de error;
- coordinación más compleja.
Por eso los sistemas multiagente deberían estudiarse después de aprender a construir correctamente un único agente.
Muchas aplicaciones que aparentemente necesitan cinco agentes pueden resolverse mejor utilizando:
1 agente
+
5 herramientas20. Evaluación de agentes de IA
Construir un agente que funciona correctamente una vez no significa necesariamente disponer de un buen agente.
Necesitamos evaluar su comportamiento.
Podemos crear conjuntos de pruebas como:
Pregunta 1 → resultado esperado
Pregunta 2 → resultado esperado
Pregunta 3 → resultado esperadoDespués podemos evaluar aspectos como:
- precisión;
- herramienta seleccionada;
- argumentos enviados;
- información recuperada;
- calidad de respuesta;
- alucinaciones;
- cantidad de tokens;
- tiempo de ejecución;
- costo.
Sin un mecanismo de evaluación resulta muy difícil determinar si realmente estamos mejorando nuestro agente.
21. Observabilidad: entender qué está haciendo el agente
En una aplicación tradicional podemos analizar logs.
En un agente necesitamos observar además procesos como:
Prompt
↓
Decisión
↓
Tool
↓
Resultado
↓
Nuevo contexto
↓
RespuestaLa observabilidad permite detectar:
- llamadas innecesarias;
- loops;
- herramientas incorrectas;
- respuestas lentas;
- consumo excesivo de tokens;
- errores de APIs;
- problemas de retrieval.
Un agente sin observabilidad puede convertirse rápidamente en una caja negra muy difícil de mantener.
22. Seguridad en agentes de inteligencia artificial
La seguridad merece especial atención cuando comenzamos a permitir que los modelos ejecuten acciones.
Un agente puede interpretar instrucciones, pero no debería tener permisos ilimitados.
No sería recomendable ofrecerle directamente funciones como:
eliminar_usuario()
transferir_dinero()
borrar_base_datos()sin controles adicionales.
Conviene aplicar principios tradicionales de seguridad:
- mínimo privilegio;
- autenticación;
- autorización;
- validación;
- auditoría;
- separación de responsabilidades.
Y agregar controles específicos para sistemas basados en IA.
Agente solicita acción
↓
Validación
↓
Control de permisos
↓
Confirmación humana
↓
EjecuciónEsto resulta especialmente importante para operaciones sensibles o irreversibles.
23. Human in the Loop
No todas las decisiones deberían automatizarse.
Podemos diseñar un agente que prepare una acción pero necesite aprobación humana para ejecutarla.
Por ejemplo:
Agente detecta una factura
↓
Extrae información
↓
Propone imputación
↓
Usuario valida
↓
Sistema registraEste modelo puede resultar especialmente útil en sistemas administrativos, financieros, gubernamentales y empresariales.
El agente aumenta la productividad sin eliminar los controles necesarios.
24. Manejo de errores y resiliencia
Los sistemas externos fallan.
Una API puede devolver un error, tardar demasiado, alcanzar límites de uso o entregar información incompleta.
Un agente debería poder manejar situaciones como:
timeout
rate limit
tool unavailable
resultado vacío
JSON inválido
permiso denegadoPor eso conviene aprender conceptos como:
- retries;
- timeouts;
- circuit breakers;
- fallbacks;
- validación;
- idempotencia.
Los agentes siguen siendo sistemas de software y deberían diseñarse con criterios adecuados de resiliencia.
25. FastAPI: convertir el agente en un servicio
Cuando el agente funciona correctamente de manera local podemos convertirlo en un servicio accesible desde otras aplicaciones.
FastAPI resulta especialmente cómodo dentro del ecosistema Python.
Podríamos exponer un endpoint como:
POST /agentque reciba:
{
"message": "Busca el expediente 2312"
}Esto permite conectar nuestro agente con:
- aplicaciones web;
- aplicaciones móviles;
- sistemas administrativos;
- otros agentes;
- microservicios.
Una posible arquitectura sería:
Frontend
↓
FastAPI
↓
Agente
↓
LLM
↓
Tools
↓
Sistemas externos26. Docker: pasar del desarrollo local a un entorno reproducible
Llegados a este punto necesitamos comenzar a pensar en el despliegue de nuestra aplicación.
Docker permite empaquetar:
código
+
dependencias
+
configuración
+
runtimedentro de un contenedor reproducible.
Un stack básico para un agente podría incluir:
Docker
│
├── FastAPI
├── PostgreSQL
├── Redis
└── Agent WorkerAprender Docker resulta especialmente útil para pasar del prototipo a un entorno real.
27. Cloud y despliegue en producción
El siguiente nivel consiste en aprender a ejecutar nuestros agentes en infraestructura real.
Dependiendo de la arquitectura podemos utilizar:
- AWS;
- Azure;
- Google Cloud;
- Vercel;
- plataformas de contenedores;
- Kubernetes;
- servicios serverless.
Pero el proveedor concreto debería ser secundario.
Los conceptos realmente importantes son:
- configuración;
- escalabilidad;
- logs;
- gestión de secretos;
- monitorización;
- alta disponibilidad;
- costos;
- seguridad.
Si estos conceptos se comprenden correctamente, cambiar de proveedor resulta mucho más sencillo.
28. Controlar el costo de los agentes
Los agentes pueden resultar considerablemente más costosos que una llamada tradicional a un modelo.
Una sola consulta del usuario podría generar:
Usuario
↓
LLM
↓
Tool
↓
LLM
↓
Tool
↓
LLM
↓
RespuestaEsto significa varias llamadas al modelo para responder una única petición.
Por eso conviene medir:
- tokens de entrada;
- tokens de salida;
- cantidad de llamadas;
- costo por conversación;
- costo por usuario;
- costo por tarea.
Optimizar agentes también significa evitar razonamientos, consultas y llamadas innecesarias.
29. Orden recomendado para aprender desarrollo de agentes IA
Si tuviera que condensar todo este roadmap en una única secuencia de aprendizaje, utilizaría el siguiente orden:
- Fundamentos de programación.
- Python.
- Git.
- HTTP, JSON y APIs.
- LLMs.
- Prompt Engineering.
- Structured Outputs.
- Tool Calling y Function Calling.
- Diseño de herramientas.
- Embeddings.
- RAG.
- Bases de datos vectoriales.
- PostgreSQL.
- Memoria y estado.
- MCP.
- LangChain.
- LangGraph.
- LlamaIndex.
- Evaluación.
- Observabilidad.
- Seguridad.
- Human in the Loop.
- Sistemas multiagente.
- FastAPI.
- Docker.
- Cloud y producción.
Esto no significa que haya que dominar completamente cada tecnología antes de pasar a la siguiente.
La idea es diferente:
Cada concepto nuevo debería construirse sobre conocimientos que ya comprendemos.
30. ¿Qué proyecto conviene desarrollar para aprender agentes de IA?
Una excelente forma de recorrer este roadmap consiste en mantener un único proyecto e ir agregándole progresivamente nuevas capacidades.
Por ejemplo, podemos construir un asistente inteligente de documentación.
Primera versión: conectar un LLM
Usuario → LLM → RespuestaCon esta primera versión podemos aprender:
- APIs de modelos;
- prompts;
- tokens;
- contexto.
Segunda versión: agregar RAG
Usuario
↓
RAG
↓
Documentos
↓
LLMAquí incorporamos:
- embeddings;
- chunks;
- bases vectoriales;
- retrieval.
Tercera versión: agregar herramientas
buscar_documento()
consultar_base_datos()
consultar_api()Con esto comenzamos a trabajar seriamente con Tool Calling.
Cuarta versión: agregar memoria
El agente comienza a mantener contexto y estado entre diferentes interacciones.
Quinta versión: incorporar MCP
Podemos comenzar a conectar el agente con diferentes herramientas y fuentes externas mediante una interfaz estandarizada.
Sexta versión: implementar un workflow
Podemos modelar un proceso más complejo mediante un framework como LangGraph.
Usuario
↓
Clasificar
↓
Buscar información
↓
Validar
↓
Ejecutar herramienta
↓
ResponderSéptima versión: agregar evaluación y observabilidad
Incorporamos pruebas, logs, métricas y seguimiento de las decisiones del agente.
Octava versión: crear una API
Utilizamos FastAPI para convertir nuestro agente en un servicio reutilizable.
Novena versión: utilizar Docker
Empaquetamos todos los componentes necesarios para disponer de un entorno reproducible.
Décima versión: desplegar el agente
Finalmente podemos llevar el sistema a infraestructura de producción.
De esta manera no estudiamos tecnologías aisladas.
Construimos progresivamente un sistema cada vez más completo.
¿Qué tecnologías son realmente imprescindibles?
No todas las tecnologías del roadmap tienen la misma importancia.
Resulta útil diferenciar entre conceptos fundamentales y herramientas intercambiables.
Conceptos fundamentales
Estos conocimientos deberían aprenderse independientemente de cualquier framework:
- programación;
- APIs;
- LLMs;
- contexto;
- Structured Outputs;
- Tool Calling;
- RAG;
- embeddings;
- memoria;
- estado;
- evaluación;
- seguridad.
Herramientas intercambiables
Estas tecnologías pueden cambiar con el tiempo:
- LangChain;
- LangGraph;
- LlamaIndex;
- Pinecone;
- ChromaDB;
- proveedores concretos de LLM;
- plataformas cloud.
Esta distinción es fundamental.
Las herramientas cambian. Los fundamentos permanecen.
Preguntas frecuentes sobre desarrollo de agentes IA
¿Necesito saber Machine Learning para desarrollar agentes de IA?
No necesariamente.
Para construir agentes utilizando modelos existentes resulta mucho más importante conocer programación, APIs, arquitectura de software y funcionamiento de los LLM.
Machine Learning tendrá mayor importancia si queremos profundizar en entrenamiento, fine-tuning o desarrollo de modelos.
¿Python es obligatorio para desarrollar agentes?
No.
Es posible construir agentes utilizando JavaScript, TypeScript, Java, C# y otros lenguajes.
Sin embargo, Python posee uno de los ecosistemas más completos relacionados con inteligencia artificial y representa una excelente opción para aprender.
¿Debo aprender LangChain antes de crear mi primer agente?
No.
De hecho, puede resultar conveniente crear primero un agente sencillo utilizando directamente la API de un modelo.
Esto permite comprender mejor cómo funcionan los mensajes, el contexto y Tool Calling.
Después, frameworks como LangChain resultarán mucho más fáciles de entender.
¿LangGraph es necesario para crear agentes?
No para agentes sencillos.
Pero cuando tenemos workflows con estado, decisiones, ciclos y múltiples pasos, un enfoque basado en grafos puede resultar muy útil.
¿Qué diferencia existe entre RAG y memoria?
RAG permite recuperar información desde una fuente de conocimiento.
La memoria mantiene información relevante relacionada con las interacciones o el estado del agente.
Aunque pueden utilizar algunas tecnologías similares, resuelven problemas diferentes.
¿Necesito una base de datos vectorial?
No siempre.
Dependerá de la cantidad de información, el tipo de búsqueda y la arquitectura de la aplicación.
Para proyectos pequeños puede ser suficiente una solución sencilla. Para sistemas documentales de mayor tamaño, las búsquedas vectoriales pueden resultar extremadamente útiles.
¿Necesito un sistema multiagente?
Probablemente no al principio.
Primero conviene intentar resolver el problema utilizando:
1 agente
+
varias herramientasSolo cuando existan responsabilidades realmente diferenciadas puede resultar conveniente introducir múltiples agentes.
Conclusión: aprender agentes de IA significa aprender a construir sistemas
Una de las ideas más importantes de este roadmap es que desarrollar agentes de IA no consiste simplemente en aprender a utilizar un LLM.
Tampoco consiste únicamente en dominar LangChain, LangGraph o cualquier framework específico.
Un agente moderno combina diferentes áreas:
LLMs
+
programación
+
APIs
+
herramientas
+
RAG
+
bases de datos
+
memoria
+
protocolos
+
seguridad
+
evaluación
+
infraestructuraEl verdadero salto ocurre cuando dejamos de pensar:
¿Cómo consigo que el modelo responda esta pregunta?
y empezamos a pensar:
¿Qué información, herramientas y decisiones necesita el sistema para resolver correctamente esta tarea?
Ese cambio de perspectiva es uno de los elementos que transforma un chatbot en un verdadero agente.
Por eso, si tuviera que resumir todo este roadmap para aprender desarrollo de agentes IA en una sola recomendación sería:
Aprende primero los fundamentos, luego las capacidades y finalmente los frameworks.
No empieces intentando construir un complejo sistema multiagente.
Empieza con algo extremadamente sencillo:
LLM
+
una herramientaDespués agrega:
RAGLuego:
memoriaDespués:
varias herramientasMás adelante:
workflowsY finalmente:
agentes especializados
+
producciónDe esta manera cada nueva tecnología tendrá un propósito concreto y será mucho más sencillo comprender qué problema resuelve.
El objetivo final de este roadmap no es poder decir que conocemos LangChain, LangGraph, MCP o una determinada base vectorial.
El objetivo es poder diseñar una arquitectura y decidir conscientemente qué necesita un agente, qué no necesita y cómo construirlo de forma segura, mantenible y útil.
«`
