Crear un agente de IA que funcione en una demo lleva una tarde. Llevarlo a producción es otra cosa, y ahí es donde se queda la mayoría. La diferencia no está en el modelo que elijas: está en el trabajo de ingeniería que rodea al modelo, que es justo lo que el mercado paga.
Esta guía recorre los seis pasos de construir un agente, el stack que se usa hoy de verdad y el hueco por el que se cae casi todo. Va dirigida a quien programa, no a quien compra.
TL;DR. Un agente de IA es un sistema que percibe un entorno, decide y actúa para cumplir un objetivo. Construirlo son seis pasos: acotar el objetivo, preparar los datos, elegir el modelo, orquestar herramientas y memoria, evaluar con criterios medibles y operarlo. El cuello de botella real no es entrenar, es desplegar y sostener. Y los datos de mercado lo confirman: en las ofertas españolas que piden LangChain, lo que aparece al lado es Docker, Kubernetes y CI/CD.
¿Qué hace falta para crear un agente de IA?
Un agente de IA es un sistema autónomo que percibe su entorno, razona sobre lo que percibe y actúa para cumplir un objetivo. Se distingue de un chatbot en una cosa: el agente puede usar herramientas y encadenar varios pasos sin que se lo pidan uno a uno.
Lo que hace falta para construirlo son cuatro cosas, y solo una es de modelos. Necesitas Python a nivel sólido, un modelo al que llamar por API o desplegado tú, un sitio donde guardar contexto y una forma de comprobar que el agente hace lo que dices que hace. El resto del trabajo, que es la mayoría, es ingeniería de software normal.
Conviene decirlo pronto porque ahorra meses: no necesitas entrenar un modelo desde cero. Prácticamente ningún agente en producción lo hace.
Los seis pasos, de la hipótesis al agente en producción
Paso 1: acotar el objetivo y el entorno
Define qué tarea resuelve el agente y en qué entorno opera, y hazlo por escrito antes de abrir el editor. Un agente que resuelve consultas sobre inventario y uno que decide reintentos de pago comparten poco más que el nombre: cambian los datos, la latencia aceptable, el coste de equivocarse y quién responde cuando se equivoca.
El error frecuente aquí no es técnico. Es empezar por lo que la herramienta permite hacer en vez de por el problema que hay que resolver, y descubrir tres semanas después que nadie necesitaba eso.
Paso 2: preparar los datos y el contexto
Los datos que necesita un agente rara vez son un dataset de entrenamiento. Son el contexto que le das en cada llamada: documentación, historial, estado del sistema, resultados de las herramientas que invoca.
En la práctica esto significa montar recuperación. Trocear los documentos con criterio, generar embeddings, guardarlos en una base vectorial y recuperar solo lo relevante para cada consulta. Es el patrón RAG, y es donde se decide la calidad de las respuestas mucho más que en la elección del modelo.
Paso 3: elegir el modelo
Elige por tarea, coste y latencia, en ese orden. Un modelo grande de razonamiento resuelve mejor la planificación de varios pasos; uno pequeño y rápido sale más barato para clasificar o extraer campos. Casi ningún agente serio usa un solo modelo: enruta según lo que toque hacer.
Si el caso exige que el modelo hable el vocabulario de tu dominio, la vía habitual es afinar uno abierto sobre tus ejemplos, no entrenar desde cero. Y antes de afinar conviene agotar el contexto y el prompt, que es mucho más barato y suele bastar.
Paso 4: orquestar herramientas, memoria y control
Aquí es donde un agente deja de ser una llamada a una API. Necesita saber qué herramientas tiene disponibles, cuándo usarlas, qué recuerda entre turnos y cuándo pararse a preguntar en vez de seguir.
Tres decisiones que conviene tomar explícitamente:
- Herramientas. Qué puede tocar el agente y con qué permisos. Un agente con acceso de escritura a producción es una decisión de arquitectura, no un detalle de configuración.
- Memoria y estado. Qué persiste entre sesiones y qué se descarta. La memoria infinita es caro y ruidoso; la memoria nula obliga al usuario a repetirse.
- Supervisión humana. En qué acciones se para y pide confirmación. Esto no se añade al final: define la arquitectura desde el principio.
Paso 5: evaluar con criterios medibles
Sin evaluación no sabes si el agente mejora o empeora cuando cambias un prompt. Necesitas un conjunto de casos con la respuesta esperada, una métrica por caso y un proceso que corra eso en cada cambio, igual que una suite de tests.
Es el paso que más se salta y el que más caro sale. Un agente sin evaluación funciona bien hasta el día que deja de hacerlo, y entonces nadie sabe qué cambio lo rompió.
Paso 6: desplegar y operar
Contenerizar, exponer una API, instrumentar trazas, vigilar coste por llamada y latencia, y tener un plan para cuando el proveedor del modelo cambie de versión debajo de ti sin avisarte, que ocurre, y que puede degradar de un día para otro un comportamiento que llevabas semanas afinando sin que nada en tu código haya cambiado. Esta parte es indistinguible de operar cualquier otro servicio. Por eso se subestima.
¿Qué stack se usa hoy para construir agentes?
El terreno se ha movido rápido, así que la tabla separa por función en vez de dar una lista de nombres que caduca.
| Función | Qué resuelve | Opciones habituales |
|---|---|---|
| Orquestación | Encadenar pasos, invocar herramientas, gestionar el bucle del agente | LangChain y LangGraph, LlamaIndex, SDK de agentes del propio proveedor |
| Recuperación | Dar contexto relevante al modelo en cada llamada | Bases vectoriales como Qdrant, Pinecone, Milvus o pgvector |
| Conexión a herramientas | Exponer sistemas y datos al agente de forma estandarizada | Model Context Protocol (MCP), funciones o herramientas del propio API |
| Evaluación | Medir si un cambio mejora o rompe el comportamiento | Suites propias de casos, más trazas comparables entre versiones |
| Operación | Desplegar, observar, controlar coste y latencia | Docker, Kubernetes, CI/CD, observabilidad de trazas y tokens |
Fíjate en la última fila. No es de IA.
¿Qué pide de verdad el mercado español a quien construye agentes?
Aquí hay un dato propio que conviene mirar antes de decidir qué aprender. Sobre el análisis de mercado laboral tech de Shakers en España (n=19.377 ofertas, ventana del 14 de junio al 10 de agosto de 2026), LangChain aparece en 569 ofertas, un 2,9% del total, y ocupa el puesto 38 entre las skills más pedidas. Por detrás de MongoDB y de Ansible.
En el mismo conjunto, Python aparece en 6.044 ofertas, más de diez veces más. AWS en 4.465. CI/CD en 4.041. Kubernetes en 3.058. Docker en 2.808.
Qué acompaña a LangChain en las ofertas que lo piden
Al revisar las ofertas españolas que mencionan el framework, lo que aparece junto a él no son herramientas de entrenamiento de modelos:
- Contenerización y orquestación: Docker, Kubernetes
- Entrega continua: CI/CD, Git
- Exposición de servicios: FastAPI, Flask, microservicios
- Nube: AWS, Azure, GCP
Fuente: análisis de mercado de Shakers, n=19.377, junio a agosto de 2026. Snapshot reproducible en el repositorio.
La lectura para quien quiere dedicarse a esto es incómoda si venías buscando aprender modelos. El framework de agentes es la parte pequeña y la que antes caduca. Lo que se paga, y lo que aparece en diez veces más ofertas, es saber poner un servicio en producción y mantenerlo vivo.
¿Por qué la mayoría de los agentes no llega a producción?
Porque el prototipo y el sistema son dos problemas distintos, y solo el primero es divertido. BCG midió esa distancia a escala de empresa: el 75% probó IA y solo el 25% vio resultados reales, la brecha entre el piloto y la producción que se conoce como implementation gap (BCG, enero 2025).
Visto desde el teclado, esa brecha se compone de cosas concretas y bastante mundanas. No hay evaluación, así que nadie se atreve a cambiar nada por miedo a romper algo que no se sabría detectar hasta que un usuario lo reporte. El coste por llamada se descubre en la factura. Nadie definió qué pasa cuando el agente se equivoca sobre un cliente real, ni quién responde. Y el equipo que lo iba a usar no cambió de costumbres, porque cambiar de costumbres lleva más tiempo que construir y nadie presupuestó ese tiempo.
Ninguno de esos cuatro problemas se resuelve eligiendo mejor el modelo.
Preguntas frecuentes sobre cómo crear un agente de IA
- ¿Necesito entrenar un modelo para crear un agente de IA?
No. Prácticamente ningún agente en producción entrena un modelo desde cero. Lo habitual es llamar a un modelo existente por API y poner el trabajo en el contexto que le das, las herramientas que le expones y la evaluación que verifica su comportamiento. Si necesitas que hable el vocabulario de tu dominio, se afina un modelo abierto sobre tus ejemplos, y aun así conviene agotar antes las opciones de contexto y prompt.
- ¿Cuál es la diferencia entre un agente de IA y un chatbot?
Un chatbot responde a lo que le preguntas. Un agente puede usar herramientas, consultar sistemas y encadenar varios pasos por su cuenta hasta cumplir un objetivo, decidiendo en cada punto qué hacer a continuación. La diferencia práctica es que el agente actúa sobre sistemas reales, y por eso los permisos y la supervisión humana pasan a ser decisiones de arquitectura.
- ¿Qué lenguaje y qué skills necesito para construir agentes?
Python es el estándar y aparece en 6.044 de las 19.377 ofertas tech analizadas en España. Pero el dato que sorprende es el reparto: LangChain solo aparece en 569 ofertas, mientras Docker, Kubernetes y CI/CD superan las 2.800 cada uno. El framework de agentes se aprende en semanas; el despliegue y la operación son lo que diferencia un perfil que puede sostener un agente en producción.
- ¿Cuánto tarda en estar listo un agente de IA?
Un prototipo que responde bien a casos preparados sale en días. Un agente que aguanta tráfico real, con evaluación, control de coste y un plan para cuando el proveedor cambie de versión, se mide en semanas o meses según el número de sistemas que toque. La mayor parte de ese tiempo no se va en el modelo, se va en la integración y en las pruebas.
Si estás construyendo tu primer agente, el orden que ahorra tiempo es este: acota el problema, monta la recuperación, escribe la evaluación antes de optimizar nada y despliega pronto aunque sea pequeño. El modelo lo cambiarás tres veces por el camino y da igual.
En Shakers verificamos skills contra trabajo real, y esa es la puerta de entrada para trabajar por proyectos con perfiles de IA aplicada. Si has llevado un agente a producción y puedes contar qué falló y cómo lo resolviste, ese caso vale más que cualquier certificado.
