Agentes IA y Automatización

En "Cómo construir un sistema multiagente" dijimos que hay que instrumentar cada traspaso antes de añadir agentes; la tecnología que sostiene esa instrumentación en producción es la observabilidad de IA. Hace visible lo que los LLM y agentes hacen realmente en producción (qué modelo con qué prompt, qué herramientas y búsquedas, qué se devolvió y cuánto tiempo y dinero costó) para que puedas rastrear hasta la causa. La diferencia decisiva frente al monitoreo habitual: la IA puede devolver 200 OK en 50ms y aun así alucinar con seguridad, así que la mayoría de los fallos de IA son fallos de calidad (alucinación, recuperación débil, respuestas inseguras, tareas incompletas, mal uso de herramientas, regresiones tras cambiar el prompt), no de infraestructura. La observabilidad se apoya en tres pilares: trazas (una petición como un árbol de spans que muestra llamadas a LLM, herramientas, recuperación y cadenas de razonamiento; la estrella de la observación de IA), métricas (latencia, coste, tokens, tasa de errores, throughput) y logs (detalle por evento). El estándar del sector OpenTelemetry y sus convenciones GenAI capturan prompts, respuestas, uso de tokens y llamadas a herramientas/agentes en un esquema neutral que se puede enviar a Datadog/Grafana. La distinción más confundida es observabilidad frente a evaluación (evals): la observabilidad muestra qué pasó (fácil de medir, pero no dice si la respuesta es correcta), mientras que las evals miden si la respuesta es buena (precisión, fundamentación, seguridad) y requieren evaluación explícita. Como el coste y la latencia son fáciles de medir pero la calidad de la respuesta no, las herramientas de 2026 combinan la visualización de trazas con la puntuación de salidas y alertas de degradación. Las métricas se dividen en operativas (coste, latencia, tokens, tasa de errores) y de calidad (alucinación, fundamentación/faithfulness, lo más crítico en RAG, seguridad, cumplimiento de la tarea), con detección de alucinaciones mediante LLM-as-a-judge, similitud semántica y puntuaciones de groundedness. Herramientas principales: LangSmith (LangChain), Langfuse (autoalojable de código abierto), Arize Phoenix (depuración de RAG), MLflow (ciclo de vida), AgentOps (agentes) y OpenTelemetry (el estándar). Empieza capturando trazas (compatibles con OpenTelemetry), visualiza las métricas operativas y luego conecta las evals antes de pasar a producción. En los sistemas multiagente la observación es esencial, ya que los fallos se esconden en cadenas de varios pasos visibles solo en una traza de la sesión completa. Observar más evaluar es lo que hace que la IA sea de calidad de producción. Las figuras y los rasgos se citan de materiales públicos, a modo orientativo.

Tras comprender el concepto en "¿Qué es un sistema multi-agente?", esta es la continuación práctica. Usando el estándar de facto de 2026, el patrón supervisor, recorre una construcción de 5 pasos para principiantes. El principio clave: construye primero con un solo agente y añade más de forma mínima solo al topar con un límite (cerca del 80% de los casos se resuelven con uno; usar multi para trabajo simple de un único carril infla el coste 3-10x y, según investigación de Google, baja la precisión −39-70% en tareas secuenciales). Tres señales para pasar a multi: división por especialización, paralelismo y separación de decisiones. El patrón supervisor (el supervisor recibe la tarea global, la descompone, la delega en workers especializados y agrega los resultados) es donde han convergido los subagentes de Claude Code, LangGraph Supervisor y los handoffs de OpenAI Agents SDK, porque tiene el soporte de frameworks más amplio, un modo de fallo conocido (delegación excesiva, acotada por un tope de iteraciones) y es fácil de auditar. Los 5 pasos: 1) descompón la tarea con claridad desde el principio; 2) define workers con un rol + herramientas + formato de salida (3-5 máximo); 3) diseña el supervisor, enumerando explícitamente los nombres de workers a los que puede llamar (tope estricto) y dedicándole el máximo tiempo; 4) decide el handoff y el reparto de contexto, pasando solo lo necesario (el estándar es A2A); 5) instrumenta cada handoff antes de añadir agentes, pon topes a iteraciones/tokens/coste y configura evals y guardrails. El pseudocódigo independiente del framework muestra las definiciones de workers, un supervisor con tope estricto y un bucle de ejecución acotado por iteraciones. Errores comunes y soluciones: delegación excesiva (tope + limitar workers que se llaman), inflado de tokens (compartir solo lo necesario + caché), inestabilidad (mantener 3-5 + salida fija), caída de precisión en secuencial (volver a un solo agente) y punto de fallo desconocido (observabilidad). La lección compartida: los prompts, el diseño de herramientas y el arnés de evals deciden el éxito más que el framework. Construye pequeño, mide y amplía solo cuando compensa. Las cifras se citan de materiales públicos e investigación, dependientes del contexto.

«Repartir entre varios agentes un trabajo complejo que un solo agente de IA no puede manejar»: esa es la idea detrás de los sistemas multiagente. Esta guía para principiantes expone el funcionamiento, los patrones principales y los frameworks más relevantes y, sobre todo, la regla de decisión real sobre cuándo usar varios agentes y cuándo basta con uno, sin exageraciones. Un sistema multiagente hace que varias IA con roles especializados trabajen juntas en una sola tarea grande; frente a un agente único que lo hace todo (suficiente para ~80% de los casos, barato y fácil de depurar), reparte el trabajo por especialidad para ejecutarlo en paralelo y verificarlo de forma cruzada, a costa de mayor coordinación y uso de tokens. Los cuatro patrones de orquestación dominantes son: orchestrator-worker (un líder descompone, reparte workers en paralelo y sintetiza; el más usado, con rastro de auditoría), traspaso secuencial, conversación en grupo (los agentes debaten con un selector que elige quién habla) y máquina de estados en grafo (agentes como nodos, transiciones como aristas, estado explícito). Los frameworks se consolidaron en 2026 en LangGraph (mayor presencia en producción), CrewAI (curva de aprendizaje más baja, prototipado), AutoGen/AG2 (debate y verificación, investigación) y OpenAI Swarm (traspasos ligeros). Pero no es una panacea: las tareas complejas y multidominio logran hasta +23% en razonamiento, pero en tareas secuenciales una investigación de Google halló −39-70% frente a un solo agente, el mismo cómputo dado a uno solo a menudo iguala o gana, y 7 de cada 10 implementaciones añadieron coste sin ROI con ~15x de tokens (ROI medio 2.5-3.5x, cuartil superior 4-6x cuando se acierta). El camino recomendado: construye primero con uno solo, identifica un techo concreto, añade un equipo mínimo de 2-3 con el patrón con líder y un tope de coste, y mide si la ganancia justifica el aumento. A2A (protocolo de comunicación) y MCP (conexión con herramientas) son tecnología base que sostiene lo multiagente. Uno solo para el 80%, multiagente solo para las partes difíciles. Las cifras se citan de encuestas e investigación y son orientativas y dependientes de las condiciones.

Ahora que los agentes de IA son algo cotidiano, el siguiente reto es cómo lograr que colaboren entre sí. Si MCP conecta un agente con sus herramientas, A2A (Agent2Agent) conecta un agente con otro agente: un estándar abierto para que IAs creadas sobre distintos proveedores y frameworks se descubran, se comuniquen y cooperen mediante una convención común. Google lo publicó en abril de 2025, lo donó a la Linux Foundation ese junio y alcanzó la v1.0 en 2026. Esta guía para principiantes explica qué es A2A (con la analogía de la etiqueta de una alianza comercial), por qué hace falta (agentes especializados que se pasan el trabajo en relevo: un agente de planificación, uno de reserva de hotel y uno de pago), en qué se diferencia de MCP (MCP es vertical, agente ↔ herramientas; A2A es horizontal, agente ↔ agente; apilar ambos es la configuración estándar de dos capas), cómo funciona (una Agent Card —un JSON «tarjeta de visita» en /.well-known/agent-card.json— sirve para descubrir capacidades, luego una Task lleva la solicitud a través de estados como working, input-required y completed, y un Artifact devuelve el resultado, todo sobre HTTP, Server-Sent Events y JSON-RPC 2.0, con los agentes manteniendo ocultas sus interioridades) y su situación e implementación (a abril de 2026, más de 150 organizaciones en producción, más de 22.000 estrellas en GitHub, SDK en cinco lenguajes —Python, JavaScript, Java, Go, .NET— con Microsoft, Salesforce, SAP y ServiceNow participando). La regla mnemotécnica: conectar con herramientas = MCP, conectar con pares = A2A.

Construiste un sistema RAG pero la calidad de búsqueda es mediocre: justo ahí es donde ayuda el reranking. El reranking vuelve a puntuar por su relevancia respecto a la consulta los candidatos reunidos de forma aproximada por la búsqueda por embeddings (vectorial) y los reordena, conservando solo los mejores; este único paso puede cambiar drásticamente la calidad de las respuestas de un sistema RAG. Esta guía para principiantes cubre qué es el reranking (con la analogía de una primera criba y una entrevista final), por qué hace falta (la búsqueda por embeddings vectoriza la consulta y los documentos por separado, así que juzga la relevancia solo de forma tosca, y un mal orden reduce directamente la calidad de las respuestas; la investigación reporta en torno a un 40% de mejora de precisión en RAG al añadir reranking, y superponerlo a la hybrid search es el estándar de 2026), cómo funciona la recuperación en dos etapas («reunir amplio» con la rápida búsqueda por embeddings para el recall, luego «acotar con criterio» con el reranker para la precisión, y entregar los mejores al LLM), por qué un reranker es más preciso (un bi-encoder vectoriza la consulta y el documento por separado y es rápido pero aproximado; un cross-encoder los introduce juntos y produce una puntuación de relevancia de 0–1, preciso pero pesado, así que reúnes con el rápido bi-encoder y acotas con el preciso cross-encoder) y los modelos e implementación (tipo API como Cohere Rerank, Voyage y Jina; open-source como BGE reranker, mixedbread y FlashRank; y puntuación con LLM como RankLLM: basta con recuperar 50–100 y acotar a los 5 mejores). El principio: reunir amplio, acotar con criterio y afinar las cantidades con evaluaciones de IA.

Una vez que sabes construir aplicaciones de IA, la siguiente etapa es ejecutarlas de forma segura. Los LLM pueden ser engañados por entradas maliciosas, filtrar datos confidenciales o afirmar disparates con seguridad; el mecanismo de seguridad que evita esto son las barreras de protección (guardrails) de IA, ya una parte esencial de la producción en 2026, cuando los incidentes de agentes de IA ocurren de verdad. Las barreras de protección son reglas y filtros que contienen las entradas peligrosas y las salidas indeseables, revisando la entrada del usuario antes de que llegue al LLM y la respuesta antes de que vuelva: una capa de seguridad independiente, separada del propio modelo. Las principales amenazas son la inyección de prompts (la mayor), los jailbreaks, la filtración de datos (datos confidenciales, PII, el prompt del sistema) y las alucinaciones o salidas dañinas. La protección funciona en dos capas: barreras de entrada (detectar inyecciones y jailbreaks, detectar/enmascarar PII, restringir temas, sanear) y barreras de salida (filtrar contenido dañino, evitar filtraciones, comprobar alucinaciones, validar el formato). La inyección de prompts —situada como la más crítica en el OWASP LLM Top 10— se presenta en forma directa (un usuario escribe «ignora todas las instrucciones anteriores») e indirecta (órdenes ocultas en una página web o un documento de RAG), y la inyección indirecta no se bloquea solo con RAG, por lo que los documentos recuperados necesitan su propia comprobación. Esta guía para principiantes también cubre las herramientas (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard y las funciones de seguridad cloud de Azure, AWS y OpenAI) y los principios prácticos de defensa en profundidad, mínimo privilegio, aprobación humana y monitorización continua.

RAG, la búsqueda semántica y las recomendaciones dependen todas de un trabajador silencioso: el embedding (vector). Un embedding es el significado de un texto (o una imagen) convertido en una secuencia de números: un vector. La palabra "perro" se convierte en una lista de cientos a miles de números que actúan como "coordenadas del significado", de modo que las palabras con significado cercano quedan próximas ("perro" y "cachorro" están cerca; "perro" y "coche" están lejos), y la cercanía se cuantifica con medidas como la similitud del coseno. Ejemplo famoso: "rey − hombre + mujer ≈ reina". Gracias a esto, una máquina puede juzgar si el significado es cercano aunque los caracteres no coincidan. Esta guía para principiantes cubre qué es un embedding (un "mapa del significado"), por qué la cercanía mide el significado (dimensiones y similitud del coseno), para qué se usa (RAG, búsqueda semántica, clasificación y deduplicación, recomendaciones y multimodal), cómo elegir un modelo de embedding (tipo API como OpenAI text-embedding-3, Cohere, Gemini, Voyage; open source como BGE-M3, Nomic, Qwen3; además de Matryoshka, que puede reducir 3.072 dimensiones a 1.024 conservando alrededor del 95% de la calidad a aproximadamente un tercio del costo), y las bases de datos vectoriales (Pinecone, Weaviate, Qdrant, Chroma, pgvector) con un inicio en tres pasos (elegir un modelo, vectorizar y guardar documentos, vectorizar la pregunta y buscar). Los embeddings son la base para implementar RAG.

Afinaste tus prompts, añadiste conocimiento con RAG y quizá hiciste fine-tuning: entonces, ¿cómo confirmas que realmente mejoró? Aquí toman protagonismo las AI evals, y para 2026 la evaluación es tan esencial que la llaman "infraestructura". Las AI evals consisten en medir sistemáticamente la calidad de las salidas de un LLM (precisión, alucinaciones, adherencia al formato, tono) con una vara de medir fija en lugar de hacerlo a ojo; sin ellas, la mejora es solo una corazonada. Hay dos métodos: la evaluación basada en código para ítems medibles mecánicamente (coincidencia exacta, formato, palabras requeridas o prohibidas — rápida, barata y estable) y LLM-as-judge para los subjetivos (usar un LLM potente como árbitro para puntuar salidas, mediante comparación pairwise o puntuación de una sola salida). El principio: mide con código todo lo que el código pueda medir. LLM-as-judge tiene sesgos de verbosidad, posición y preferencia por sí mismo; las soluciones son usar una familia de modelo distinta como calificador, intercambiar el orden y calificar dos veces, incluir la concisión en la rúbrica y calibrar contra el juicio humano. Las escalas gruesas (pass/fail o 1–3) superan a la fina de 1–10. En la práctica, ejecuta tres niveles — chequeos de código instantáneos en cada cambio, pruebas de regresión nocturnas con LLM-as-judge y monitoreo continuo en producción — con herramientas como DeepEval, Promptfoo y RAGAS para CI más Braintrust, LangSmith y Arize para monitoreo. Empieza reuniendo 10 buenas salidas y 10 malas y puntuándolas.

En una era en la que la IA escribe el código, la habilidad de mayor valor está pasando de "escribir código" a "escribir la especificación", y la práctica que recoge ese cambio es el spec-driven development (SDD). El SDD coloca la especificación en el centro del proyecto como fuente de verdad, y un agente de IA deriva de ella el diseño, el desglose y la implementación en lugar de programar de inmediato. La clave es que cada paso deja un documento (a menudo Markdown) que el paso siguiente lee. Esta guía para principiantes cubre qué es el SDD (la especificación es canónica; el código es un derivado), por qué importa ahora (previene el "muro de los tres meses" de deuda técnica del vibe coding y la deriva de requisitos en la fase de diseño —GitHub informa de aproximadamente un orden de magnitud menos de ciclos de "regenerar desde cero", cifra reportada por el propio proveedor—), los cuatro pasos básicos (Specify → Plan → Tasks → Implement), las herramientas principales (GitHub Spec Kit con más de 90.000 estrellas y más de 30 agentes compatibles, AWS Kiro con su flujo Requirements → Design → Tasks y router Auto, además de BMAD, OpenSpec, Tessl, Google Antigravity y Cursor), cuándo usarlo frente al vibe coding (un híbrido: vibe para explorar, spec-driven para entregar, con revisión humana obligatoria) y cómo probarlo hoy mismo. En la era de la IA, quienes destacan son los que saben definir con precisión qué construir, no los que escriben código más rápido.

El centro de gravedad del trabajo con IA se está desplazando de la ingeniería de prompts a la ingeniería de contexto. Tomando prestada la definición de Anthropic, la ingeniería de contexto es "el conjunto de estrategias para seleccionar y mantener el conjunto óptimo de tokens (información) que le entregas al modelo durante la inferencia": abarca no solo el prompt, sino todo lo que hay en la ventana de contexto, es decir, el system prompt, las herramientas, el historial de la conversación y los datos externos. Importa por el "context rot" (degradación del contexto): cuantos más tokens añades, más baja en realidad la precisión. El estudio de Chroma de 2025 probó 18 modelos líderes (GPT, Claude, Gemini y más) y todos se degradaron a medida que crecía la entrada, siendo la información en el medio de los contextos largos especialmente fácil de ignorar ("lost in the middle"). Esta guía para principiantes explica qué es la ingeniería de contexto y cómo se relaciona con la ingeniería de prompts, por qué ocurre el context rot (la atención es un presupuesto finito), qué hay realmente dentro del contexto, seis técnicas esenciales (instrucciones a la altura adecuada, selección de herramientas, recuperación just-in-time, compactación o compresión por resumen, notas como memoria externa y aislamiento con subagentes), su relación con RAG y Claude Skills, y hábitos que puedes usar hoy como empezar una sesión nueva cuando cambia el tema y pegar solo los puntos clave. La idea central: conservar únicamente los tokens más pequeños y con mayor señal.

Una guía para principiantes sobre las Claude Skills (Agent Skills), el mecanismo que acaba con la pesadez de volver a explicarle a Claude el mismo procedimiento una y otra vez. Una Skill empaqueta instrucciones, scripts y referencias en una sola carpeta, centrada en un archivo SKILL.md que contiene un nombre, una descripción y los pasos. La mayor parte del tiempo Claude lee solo la breve descripción de cada skill, y despliega el cuerpo únicamente cuando tu petición coincide con ella: un diseño llamado divulgación progresiva que mantiene tu contexto ligero incluso con decenas de skills instaladas. Este artículo cubre qué son las Skills, por qué importan (se acabó volver a pegar prompts), cómo escribir un SKILL.md y una estructura de carpetas mínima, cómo crear una (con la skill-creator oficial o a mano, soltándola en .claude/skills, con la recarga instantánea de enero de 2026), en qué se diferencian del MCP (conectividad) y de los subagentes (aislamiento de contexto), el estándar abierto que ya adoptaron Codex CLI, Cursor, Gemini CLI y GitHub Copilot más allá de las apps de Claude, Claude Code, la API y el Agent SDK, además de usos concretos como la generación de documentos y la aplicación de reglas internas. Anunciado por Anthropic el 16 de octubre de 2025 y calificado de «quizá algo más importante que el MCP» por Simon Willison.

"Le pedí algo a una IA y abrió el navegador, lo buscó por su cuenta e incluso rellenó un formulario por mí." En 2026 esto ya no es una demo preparada: los navegadores agénticos (ChatGPT Atlas, Claude for Chrome, Gemini/Chrome, Perplexity Comet) llegaron todos a la vez. Así que, ¿hasta dónde pueden automatizar realmente? La realidad se divide con nitidez en tres niveles. (1) Investigación = lista para producción: en WebVoyager (sitios reales) los mejores agentes alcanzan el 89-98%, casi saturando el benchmark, y como una acción errónea cuesta poco, es por aquí por donde empezar a delegar. (2) Rellenar formularios = factible pero verifica: la introducción de datos está soportada, pero los agentes pueden etiquetar mal los campos o pulsar el envío equivocado, así que "la IA redacta, una persona envía" es lo seguro, y muchos productos como Atlas piden confirmación antes de acciones importantes. (3) Reserva/pago = mejor hazlo tú: los agentes tropiezan con CAPTCHA, checkouts complejos de JavaScript, autenticación de dos factores y gestión de sesiones, y en WebArena (tareas complejas de varios pasos) hasta los mejores rondan el ~47-68% frente al ~78% de referencia humana; la verdadera razón por la que OpenAI cerró el Operator independiente (2025/8/31) fue la falta de fiabilidad del checkout. El artículo primero plantea los dos enfoques (navegador/extensión de consumidor frente a API/OSS de desarrollador), luego mapea los protagonistas de 2026 (Atlas como navegador dedicado que no puede ejecutar código ni leer contraseñas por diseño; Claude for Chrome como panel lateral de extensión; el Project Mariner de Google terminó el 2026/5/4 e integrado en Gemini/Chrome; Operator pasó a ChatGPT Agent y al Agents SDK; el OSS browser-use con más de 78k estrellas). Explica los cuatro muros que hacen fallar la reserva (defensas antibots, checkout complejo, 2FA, el coste de deshacer), y profundiza en la mayor trampa: la inyección indirecta de prompts (se demostró que Perplexity Comet era vulnerable al robo de credenciales zero-click y lo corrigió en febrero de 2026; el éxito del ataque del 23.6% antes de las defensas baja al ~11% con defensas básicas y al ~1% con las más fuertes, sin llegar nunca a cero). Cierra con cinco principios de seguridad (empezar en solo lectura, que una persona apruebe envíos/pagos, no entregar contraseñas, no ejecutar en sitios no confiables, mínimo privilegio en un perfil dedicado). Un excelente compañero de investigación; las acciones que mueven dinero, hazlas tú mismo. Las cifras se citan de materiales públicos y anuncios como referencias orientativas.