LLM, RAG, agentes, MCP y más: cómo entender de verdad el stack de la IA actual
La gente habla de IA como si fuera una caja mágica: escribes un prompt, pulsas Enter y aparece una respuesta brillante, un agente, una automatización o una app “inteligente”. Pero debajo de eso no hay magia. Hay una pila de conceptos, piezas y decisiones técnicas que conviene entender para no quedarse en la superficie.
Si quieres dar un paso más allá del uso básico de ChatGPT o Claude, necesitas ordenar ideas. LLM, contexto, embeddings, RAG, tools, agentes, MCP, frameworks, memoria, orquestación, APIs, costes, latencia y seguridad. No hace falta ser investigador, pero sí tener un mapa mental decente.
Este artículo va justo de eso: entender qué hace cada capa, cómo se relacionan entre sí y qué suele hacer falta de verdad para construir una IA útil o un agente que automatice trabajo real.
El primer error: pensar que todo es “la IA”
Cuando alguien dice “quiero hacer una IA”, casi nunca se refiere a una sola cosa. Puede querer:
- un chat que responda preguntas
- un asistente que lea documentación
- un bot que busque datos y rellene tareas
- una automatización que actúe sobre varias herramientas
- un agente que decida qué paso hacer después
Todas esas cosas usan IA, sí, pero no son la misma arquitectura.
Un chat simple puede vivir con un modelo y un prompt. Un sistema que responde con datos internos seguramente necesita RAG. Un flujo que consulta, decide y ejecuta acciones ya entra más en territorio de agentes y herramientas. Y si además quieres conectarlo de forma ordenada con servicios externos, aparece MCP o algún sistema propio de integración.
La clave es esta: un modelo no es lo mismo que un producto de IA.
Qué es un LLM realmente
Un LLM es un Large Language Model, un modelo entrenado con enormes cantidades de texto para predecir cuál es la siguiente palabra o token más probable dentro de una secuencia.
Eso parece poco glamuroso, pero de ahí sale muchísimo:
- responder preguntas
- resumir
- reescribir
- traducir
- extraer datos
- generar código
- clasificar texto
- razonar de forma aproximada
Lo importante es entender que el modelo no “sabe” las cosas como una persona. No tiene una base de datos interna consultable como si fuera Google. Tiene patrones aprendidos y una enorme capacidad para producir texto coherente.
Por eso:
- puede acertar mucho
- puede sonar segurísimo y estar equivocado
- puede razonar bastante bien en algunos contextos
- puede inventarse datos si no tiene el contexto correcto
El LLM es el motor de lenguaje. No es toda la solución.
Tokens, ventana de contexto y por qué importan tanto
Si quieres trabajar con IA en serio, este concepto importa más de lo que parece.
Los modelos no leen “texto” como tú. Lo convierten en tokens, fragmentos de texto que pueden ser palabras, trozos de palabras o símbolos. Todo lo que metes y todo lo que sale consume tokens:
- prompt del sistema
- instrucciones
- conversación previa
- documentos añadidos
- herramientas disponibles
- respuesta generada
La ventana de contexto es la cantidad de información que el modelo puede tener “delante” en una interacción.
Esto afecta directamente a:
- cuánto contenido puedes pasarle
- cuánto cuesta cada petición
- cuánta memoria conversacional real puedes mantener
- cuánto ruido metes en el prompt
- si el modelo empieza a perder foco
Mucha gente cree que construir IA es “darle mucho contexto”. En realidad, una parte importante del trabajo es darle el contexto justo.
Prompting: útil, pero no suficiente
El prompt sigue siendo importante, claro. Define:
- el rol del modelo
- el formato de salida
- restricciones
- estilo
- pasos de razonamiento o estructura
Pero el prompting por sí solo no resuelve los problemas grandes.
No arregla:
- falta de datos actualizados
- acceso a fuentes internas
- necesidad de ejecutar acciones
- validación de resultados
- control de permisos
- trazabilidad
El prompt es una capa. Muy importante, pero solo una capa.
Embeddings: cuando no quieres solo texto, sino buscar por significado
Aquí empieza a aparecer la parte que mucha gente usa sin saber bien qué hace.
Un embedding es una representación numérica de un texto. Convierte frases, párrafos o documentos en vectores matemáticos para poder comparar su cercanía semántica.
Eso permite cosas como:
- buscar contenido “parecido” aunque no use las mismas palabras
- agrupar información relacionada
- recuperar fragmentos relevantes para una pregunta
- construir un sistema RAG
Ejemplo simple:
Si alguien pregunta “¿cómo conecto mi dominio al hosting?”, un buscador literal depende mucho de que existan esas palabras exactas. Un sistema basado en embeddings puede encontrar también texto que hable de DNS, nameservers, SSL o registros A, aunque la frase no coincida al milímetro.
Los embeddings no responden por sí solos. Sirven para encontrar mejor el contexto que luego verá el modelo.
RAG: traer conocimiento externo al modelo
RAG significa Retrieval-Augmented Generation.
Traducido a algo práctico:
- el usuario hace una pregunta
- el sistema busca contenido relevante en una base documental
- esos fragmentos se meten en el contexto
- el modelo responde usando esa información
Eso sirve para que la IA no dependa solo de lo aprendido en su entrenamiento.
Cuándo tiene sentido usar RAG
- documentación interna
- base de conocimiento de empresa
- manuales técnicos
- políticas y procesos
- artículos o contenido propio
- catálogos y datos que cambian
Qué no hace mágicamente RAG
No convierte una base de datos caótica en conocimiento limpio.
Si el contenido está mal:
- mal troceado
- duplicado
- desactualizado
- contradictorio
- sin estructura
el sistema responderá peor.
RAG no es magia. Es una arquitectura para recuperar contexto útil antes de generar respuesta.
Tool calling: cuando el modelo necesita hacer cosas
Una IA útil no siempre tiene que responder solo con texto. A veces necesita ejecutar acciones:
- consultar una API
- buscar en una base de datos
- leer un archivo
- crear un ticket
- enviar un email
- lanzar un script
- consultar el tiempo
Ahí entra el concepto de tools o function calling.
El modelo recibe una lista de herramientas disponibles, con su nombre, descripción y parámetros esperados. Entonces puede decidir:
- responder directamente
- o pedir que se ejecute una herramienta concreta
Después el sistema ejecuta esa herramienta fuera del modelo, recoge el resultado y se lo devuelve para que siga.
Eso ya cambia mucho el tipo de producto que puedes montar, porque pasas de “modelo que habla” a “modelo que puede operar sobre el mundo”.
Qué es un agente y por qué se habla tanto de ellos
Aquí hay muchísimo humo, así que conviene bajarlo a tierra.
Un agente suele ser un sistema que combina:
- un modelo
- instrucciones
- herramientas
- capacidad de decidir el siguiente paso
- memoria o estado
- un bucle de ejecución
Es decir, no se limita a responder una vez. Puede:
- analizar la tarea
- elegir una herramienta
- ejecutar
- revisar el resultado
- decidir si necesita otro paso
- repetir hasta cerrar la tarea o llegar a un límite
Ejemplos:
- un agente que revisa documentación, busca ejemplos y redacta una respuesta técnica
- un agente que consulta una API, transforma datos y genera un informe
- un agente que recibe una incidencia y decide a qué sistema preguntar
Lo importante
Un agente no es “más listo” por definición. Es más orquestado.
Muchas veces la mejora no está en el razonamiento del modelo, sino en:
- tener herramientas adecuadas
- acotar bien el problema
- controlar el flujo
- validar mejor las salidas
Hay casos donde un flujo fijo gana a un agente libre.
Workflows vs agentes: no todo necesita autonomía
Esto es clave para no sobrecomplicar.
Un workflow es un flujo predefinido:
- llega una entrada
- se ejecuta el paso A
- luego B
- luego C
- se produce una salida
Un agente decide más cosas por el camino.
Regla práctica:
- si el proceso está claro y es repetible, un workflow suele ser mejor
- si la tarea exige exploración, decisión o uso variable de herramientas, un agente puede tener sentido
La moda ha hecho que mucha gente llame “agente” a cualquier automatización con un modelo metido en medio. Y no siempre lo es.
Memoria: lo que el modelo recuerda y lo que realmente guardas tú
Cuando se habla de agentes aparece enseguida la palabra memoria, pero conviene distinguir:
1. Memoria de conversación
El historial que se vuelve a enviar al modelo para mantener continuidad.
2. Memoria persistente
Datos guardados fuera del modelo:
- preferencias de usuario
- estado de tareas
- resultados previos
- contexto de una sesión
- resumen de interacciones
3. Memoria recuperada
Contenido que se trae en cada turno desde una base documental, muy parecido a RAG.
El modelo por sí mismo no “recuerda” de manera fiable entre sesiones salvo que tú construyas ese sistema.
MCP: por qué importa tanto ahora
MCP suele referirse a Model Context Protocol, una forma estandarizada de conectar modelos o agentes con herramientas, fuentes de datos y capacidades externas.
La idea importante no es memorizar el nombre, sino entender el problema que resuelve:
Hasta hace poco, cada integración de IA con archivos, bases de datos, documentación o servicios externos se resolvía de manera bastante ad hoc. Cada producto inventaba su forma.
MCP intenta ordenar eso para que un cliente o agente pueda hablar con “servidores” que exponen capacidades de forma consistente, por ejemplo:
- leer recursos
- listar herramientas
- ejecutar acciones
- acceder a contexto estructurado
Eso facilita construir entornos donde una IA no vive aislada, sino conectada a cosas reales de forma más mantenible.
Por qué esto es útil
- reduce integraciones improvisadas
- hace más portable el acceso a herramientas
- ayuda a separar cliente, modelo y fuentes de contexto
- vuelve más escalable el ecosistema de agentes
No es obligatorio para todo, pero sí es una pieza cada vez más relevante.
Skills, tools, connectors y otras capas alrededor
Cuando trabajas con asistentes o agentes modernos aparecen muchos nombres que se parecen, pero no son exactamente lo mismo.
Tools
Funciones o acciones ejecutables.
Connectors
Puentes con servicios externos, como Google Drive, GitHub, Slack, Notion o una API propia.
Skills
Bloques reutilizables de instrucciones, contexto, flujos o comportamientos especializados.
Resources
Archivos, documentos, esquemas o datos que se ponen a disposición del modelo o del agente.
En muchos sistemas modernos, el valor real está menos en “tener un LLM” y más en cómo le das acceso ordenado a capacidades externas.
LangChain, LlamaIndex y frameworks similares
Aquí también hay bastante confusión. Mucha gente los menciona como si fueran obligatorios.
No lo son.
Frameworks como LangChain o LlamaIndex ayudan a montar piezas habituales:
- cadenas de prompts
- agentes
- memoria
- RAG
- integración con modelos
- herramientas
- observabilidad o tracing
Son útiles si:
- quieres acelerar prototipos
- no quieres reinventar integración tras integración
- necesitas abstraer varios modelos o proveedores
Pero también pueden meterte capas de complejidad si el caso es pequeño.
Hay proyectos donde:
- API del modelo + buen backend + algo de RAG
es más que suficiente.
Y hay otros donde un framework sí te ahorra bastante trabajo.
La pregunta buena no es “¿qué framework está de moda?”, sino:
¿Mi problema necesita una abstracción adicional o todavía se entiende bien sin ella?
Qué lenguajes se usan para construir esto
No hay un único lenguaje obligatorio, pero algunos son especialmente frecuentes.
Python
Sigue siendo muy fuerte en:
- IA
- data
- ML
- pipelines
- prototipos rápidos
- ecosistema de librerías
JavaScript / TypeScript
Muy buenos para:
- productos web
- integraciones con frontend
- herramientas para navegador
- agentes conectados a apps SaaS
- ecosistema moderno de APIs y automatización
Otros
También puedes usar:
- Go para servicios rápidos y simples
- Java o C# en entornos enterprise
- Rust en casos muy concretos de rendimiento o infraestructura
Para mucha gente que viene de web, TypeScript es una puerta muy razonable para construir asistentes, tools y agentes conectados a productos reales.
Qué hace falta de verdad para crear un agente útil
Aquí conviene bajar de las palabras a las piezas concretas.
Para construir algo serio, normalmente necesitas:
1. Un modelo
El motor de razonamiento y generación.
2. Un backend
Donde vivirán:
- tus prompts
- tus reglas
- tus herramientas
- tus límites
- tu lógica de orquestación
3. Herramientas o integraciones
Las acciones que el sistema puede ejecutar.
4. Datos o contexto
RAG, base documental, base de datos, APIs o estado de usuario.
5. Guardrails
Restricciones y validaciones para evitar respuestas o acciones peligrosas.
6. Observabilidad
Saber:
- qué prompt se envió
- qué tool llamó
- cuánto costó
- cuánto tardó
- dónde falló
7. Evaluación
No basta con “parece que va bien”.
Necesitas probar:
- precisión
- consistencia
- seguridad
- coste
- latencia
- tasa de error
El stack mínimo de un proyecto de IA con sentido
Si lo simplificamos mucho, un stack bastante realista podría ser este:
- interfaz web o chat
- backend en TypeScript o Python
- acceso a un modelo por API
- base de datos o almacén documental
- embeddings y búsqueda semántica si hace falta RAG
- tools para ejecutar acciones
- logs, métricas y tracing
En algunos casos añadirás:
- cola de trabajos
- autenticación
- permisos por usuario
- caché
- sistema de evaluación
- memoria persistente
Eso ya se parece bastante más a un producto real que a “un prompt bonito”.
Los problemas de fondo: coste, latencia, permisos y fiabilidad
Aquí es donde se separa la demo del producto.
Coste
Cada llamada al modelo cuesta. Si además haces RAG, tools, reintentos y cadenas largas, el coste sube rápido.
Latencia
Si el modelo tarda, luego llama a una tool, luego vuelve al modelo y luego consulta otra fuente, la respuesta puede volverse lenta.
Permisos
Un agente que puede leer o ejecutar cosas necesita límites claros. No quieres darle acceso total a todo.
Fiabilidad
El modelo puede interpretar mal una instrucción, elegir la tool equivocada o producir una salida mal formada.
Por eso, construir IA útil no es solo “que responda bien”. Es conseguir que el sistema sea:
- controlable
- observable
- seguro
- mantenible
Qué debería aprender alguien que quiere pasar del uso a la construcción
Si quieres dar ese salto, este orden tiene bastante sentido:
1. Bases de APIs y backend
Porque casi todo esto vive conectado a servicios.
2. JSON, estructuras de datos y validación
Imprescindible para tools, salidas estructuradas y automatización.
3. Buen prompting
No como truco, sino como diseño de instrucciones.
4. Tokens, contexto y costes
Para no construir sistemas absurdos.
5. RAG y embeddings
Para trabajar con conocimiento real.
6. Tool calling y flujos
Para que el sistema haga cosas, no solo hable.
7. Agentes y orquestación
Cuando ya entiendes lo anterior.
8. Observabilidad y evaluación
Porque si no mides, solo estás improvisando.
El gran resumen: menos humo, más mapa mental
Detrás de la IA actual no hay una única pieza milagrosa. Hay capas.
- el LLM genera y razona
- el prompt orienta
- el contexto condiciona
- los embeddings ayudan a buscar por significado
- el RAG trae conocimiento externo
- las tools permiten actuar
- los agentes orquestan pasos
- MCP ayuda a conectar capacidades de forma más ordenada
- frameworks como LangChain pueden acelerar, pero no sustituyen el criterio
Si entiendes ese mapa, ya no ves “la IA” como una caja negra. Empiezas a verla como lo que es: un sistema de piezas combinables con sus límites, costes y decisiones de arquitectura.
Y ahí es donde de verdad empieza lo interesante.
No cuando preguntas cosas a un chat, sino cuando entiendes qué estás construyendo por detrás.