Título original: What to Learn, Build, and Skip in AI Agents (2026)
Autor original: Rohit
Traducción: Peggy, BlockBeats

Nota del editor: El campo de los Agentes de IA está entrando en una fase de explosión de herramientas y falta de consenso.

Cada semana aparecen nuevos marcos, nuevos modelos, nuevos benchmarks y productos con «10 veces más eficiencia», pero las preguntas realmente importantes ya no son «cómo mantenerse al día con todos los cambios», sino «cuáles cambios realmente valen la pena».

El autor opina que, en un contexto donde las pilas tecnológicas se reescriben constantemente, lo que puede generar beneficios a largo plazo no es perseguir el marco más reciente, sino habilidades más fundamentales: ingeniería de contexto, diseño de herramientas, sistemas de evaluación, modo orquestador-subagente, pensamiento en sandbox y harness. Estas habilidades no se vuelven obsoletas rápidamente con la renovación de modelos, sino que se convierten en la base para construir Agentes de IA confiables.

El artículo además señala que los Agentes de IA también están cambiando el significado de «experiencia». Antes, los títulos académicos, niveles y años en la industria eran la tarjeta de entrada; pero en un campo donde incluso los gigantes aún están probando y equivocándose públicamente, el currículum ya no es la única prueba. Lo que haces y entregas se vuelve cada vez más importante.

Por eso, este texto no solo discute qué aprender, qué usar y qué saltarse en los Agentes de IA en 2026, sino que también advierte: en una era de cada vez más ruido, la habilidad más escasa es saber qué vale la pena aprender y seguir produciendo cosas realmente útiles.

Aquí está el texto original:

Cada día surge un nuevo marco, un nuevo benchmark, un nuevo producto con «10 veces más eficiencia». La cuestión ya no es «cómo puedo seguir el ritmo», sino: qué señales son realmente confiables y qué solo son ruido disfrazado de urgencia.

Cada hoja de ruta, un mes después de su publicación, puede quedar obsoleta. El marco que dominaste el trimestre pasado ya es viejo. El benchmark que optimizaste fue superado rápidamente por uno nuevo. Antes, nos entrenaban para seguir una ruta tradicional: una pila tecnológica, un conjunto de temas y niveles; una serie de experiencias laborales, años y cargos; avanzar paso a paso lentamente. Pero la IA ha reescrito ese lienzo. Hoy, con un prompt bien diseñado y un juicio estético suficiente, una sola persona puede entregar en un sprint lo que antes requería un ingeniero con dos años de experiencia.

Las habilidades profesionales siguen siendo importantes. Nada puede reemplazar haber visto un sistema colapsar, haber ajustado memoria en medio de la noche, o haber optado por una solución aburrida pero correcta, que luego se demuestra que fue la adecuada. Esa capacidad de juicio se beneficia con el tiempo. Pero lo que ya no crece de forma compuesta como antes, es la familiaridad superficial con las APIs de los marcos de moda, que puede cambiar en seis meses. Quien gane en dos años será aquel que haya elegido desde temprano habilidades duraderas y haya dejado pasar el ruido.

En los últimos dos años, he estado construyendo productos en este campo, recibiendo ofertas con salarios superiores a 250,000 dólares anuales, y ahora dirijo tecnología en una empresa en modo stealth. Si alguien me pregunta: «¿Qué debería aprender ahora?», esto es lo que le diría.

No es una hoja de ruta. El campo de los Agentes aún no tiene un destino claro. Los laboratorios grandes también están en iteración pública, devolviendo los problemas a millones de usuarios, escribiendo análisis y corrigiendo en línea. Si el equipo detrás de Claude Code lanza una versión que causa un 47% de retroceso en rendimiento, y solo se da cuenta cuando la comunidad la descubre, entonces la idea de que «hay un mapa estable debajo» es ficticia. Todos estamos explorando. La oportunidad de las startups radica en que incluso los gigantes no tienen la respuesta. Personas que no saben programar están colaborando con agentes, entregando cosas que en un viernes, un doctor en aprendizaje automático consideraría imposibles para un martes.

Lo más interesante de este momento es que cambia nuestra percepción de la «experiencia». La ruta tradicional valora la experiencia: títulos, cargos iniciales, avanzados, senior, y la acumulación lenta de niveles. Cuando el campo no cambia drásticamente en sus fundamentos, esto tiene sentido. Pero ahora, el suelo bajo los pies se mueve a la misma velocidad. La diferencia entre un joven de 22 años que publica un demo de un agente y un ingeniero senior de 35, ya no es solo la experiencia en la pila tecnológica. Ambos enfrentan la misma hoja en blanco. Para ellos, lo que realmente puede crecer de forma compuesta es la voluntad de entregar continuamente y las habilidades básicas que no se vuelven obsoletas en un trimestre.

Esa es la idea central de todo el artículo. A continuación, propongo un método para juzgar: qué habilidades fundamentales vale la pena invertir, y qué lanzamientos puedes simplemente ignorar. Toma lo que te sirva, deja lo que no.

Filtros verdaderamente efectivos

No puedes seguir cada semana los nuevos lanzamientos, y no deberías intentarlo. Lo que necesitas no es un flujo de información, sino filtros.

En los últimos 18 meses, cinco preguntas han sido efectivas para evaluar nuevas incorporaciones a tu pila tecnológica. Antes de integrar algo nuevo, pásalo por estas cinco preguntas.

¿Sigue siendo importante en dos años?
Si solo es una capa superficial de un modelo de vanguardia, un parámetro CLI, o una versión de Devin, la respuesta casi siempre será no. Si es un primitive fundamental, como un protocolo, un modo de memoria, o un método de sandbox, probablemente sí. Los productos envoltorio tienen una vida media corta; los primitives fundamentales pueden durar años.

¿Alguna persona respetada ya ha construido un producto real basado en ello y ha compartido honestamente su experiencia?
No valen artículos de marketing, sino análisis retrospectivos. Un blog titulado «Probamos X en producción y esto salió mal» vale más que diez anuncios. Las señales útiles en este campo siempre vienen de quienes han dedicado un fin de semana a ello.

¿Adoptarlo implica eliminar tus mecanismos actuales de tracing, reintentos, configuración o autenticación?
Si es así, es un marco que intenta convertirse en plataforma. La tasa de fracaso de estos marcos es aproximadamente del 90%. Los primitives buenos deben integrarse en tus sistemas existentes, no forzar migraciones.

¿Qué pasa si lo ignoras seis meses?
Para la mayoría de los lanzamientos, no pasa nada. En seis meses sabrás más, y el producto ganador será más claro. Esta pregunta te permite saltarte el 90% de los lanzamientos sin ansiedad, porque en realidad no te estás quedando atrás.

¿Puedes medir si realmente mejora tu agente?
Si no, solo estás adivinando. Sin sistemas de evaluación, dependes de la intuición, y eso puede llevar a problemas en producción. Con evaluación, los datos te dirán si, en una carga de trabajo concreta, GPT-5.5 o Opus 4.7 funciona mejor.

Si solo aprendes una cosa de este artículo, que sea: cada vez que salga algo nuevo, escribe qué necesitas ver en seis meses para creer que es importante. Luego, vuelve a revisar. La mayoría de las veces, la respuesta ya está en los datos, y tu atención se dirigirá a lo que realmente puede crecer de forma compuesta.

Las habilidades que hay detrás de estas preguntas son más difíciles de nombrar que las propias preguntas. Es una habilidad de «no seguir la moda». La tendencia que está en auge en Hacker News puede tener un equipo de fans que parecen muy inteligentes, pero en seis meses, la mitad de esas herramientas ya no se mantienen, y sus seguidores se cambian a la próxima tendencia. Quien no participa ahorra energía y la dirige a lo que, tras la moda, sigue siendo útil y resistente al paso del tiempo. La disciplina de ser cauto, esperar, y decir «en seis meses sabré» es la verdadera habilidad profesional en este campo. Todos leen anuncios, pero pocos saben cómo no reaccionar ante ellos.

Qué aprender

Conceptos, patrones, la forma de las cosas. Lo que realmente genera beneficios compuestos son estas habilidades. Son las que atraviesan cambios de modelos, marcos y paradigmas. Comprenderlas profundamente te permite aprender cualquier herramienta en un fin de semana. Saltarte estas habilidades significa estar siempre reaprendiendo superficialidades.

Ingeniería de Contexto

En los últimos dos años, el cambio más importante ha sido que «Prompt Engineering» ahora se llama «Context Engineering». Este cambio es real, no solo un cambio de término.

El modelo ya no es solo un sistema al que le das una instrucción inteligente. Se convierte en un sistema en el que necesitas armar un contexto funcional en cada paso. Ese contexto incluye instrucciones del sistema, esquemas de herramientas, documentos recuperados, salidas previas, estado del scratchpad, y un historial comprimido. La conducta del agente emerge de todo lo que pones en la ventana de contexto.

Debes internalizar que: el contexto es estado. Cada token inútil reduce la calidad del razonamiento. La corrupción del contexto es una falla real en producción. Cuando llegas a la octava de diez tareas, el objetivo original puede estar enterrado en las salidas de las herramientas. Los equipos que entregan agentes confiables resumen, comprimen y recortan el contexto activamente. Gestionan versiones de las descripciones de herramientas, almacenan en caché las partes estáticas y rechazan las partes variables. Ven la ventana de contexto como un ingeniero experimentado ve la memoria: como un recurso limitado y valioso.

Una forma concreta de sentir esto es: abre el trace completo de un agente en producción. Mira el contexto en el primer paso y en el séptimo. Cuenta cuántos tokens todavía están en uso. La primera vez que hagas esto, probablemente te sentirás incómodo. Pero luego, lo corregirás, y el mismo agente, sin cambiar modelo ni prompt, será mucho más confiable.

Si solo lees un artículo relacionado, lee «Effective Context Engineering for AI Agents» de Anthropic. Luego, revisa su análisis sobre sistemas de investigación multi-agente, que muestra con números cuán importante es aislar contextos a medida que el sistema escala.

Diseño de herramientas

Las herramientas son el punto de contacto entre el agente y tu negocio. El modelo selecciona herramientas según su nombre y descripción, y decide cómo reintentar según los errores. La compatibilidad del contrato de la herramienta con la forma en que los LLMs expresan sus intenciones determina el éxito o fracaso del sistema.

Cinco a diez herramientas bien nombradas valen más que veinte mediocres. Los nombres deben ser frases verbales en inglés natural. La descripción debe indicar claramente cuándo usarlas y cuándo no. Los mensajes de error deben ser retroalimentación que el modelo pueda usar para actuar. «Superar el límite de 500 tokens, resuma antes de intentar» es mucho mejor que «Error: 400 Bad Request». Un equipo de investigación reportó que solo reescribir los mensajes de error redujo en un 40% los ciclos de reintento.

«Writing tools for agents» de Anthropic es un excelente punto de partida. Después de leerlo, ajusta tus propias herramientas con observaciones y analiza los patrones de uso reales. La mayor mejora en confiabilidad del agente suele venir del lado de las herramientas. Muchos ajustan prompts sin prestar atención a dónde está el verdadero leverage.

Modo Orquestador-Subagente

Las discusiones sobre multi-agentes en 2024 y 2025 convergieron en una solución ahora ampliamente adoptada. Los sistemas ingenuos de múltiples agentes, donde varios agentes escriben en un estado compartido, fracasan catastróficamente porque los errores se acumulan. La única forma viable en producción es un agente orquestador que delega tareas limitadas y de solo lectura a subagentes aislados, y luego combina sus resultados.

El sistema de investigación de Anthropic funciona así. Los subagentes de Claude Code también. Spring AI y otros frameworks están estandarizando este modo. Los subagentes tienen contextos pequeños y enfocados, sin modificar el estado compartido. La escritura la gestiona el orquestador.

Aunque «Don’t Build Multi-Agents» de Cognition y «How we built our multi-agent research system» de Anthropic parecen ideas opuestas, en realidad solo usan diferentes términos para describir lo mismo. Ambos artículos valen la pena.

Por defecto, usa un solo agente. Solo cuando ese agente alcance límites reales, considera usar un modo orquestador-subagente: por ejemplo, por restricciones en la ventana de contexto, latencias por llamadas secuenciales a herramientas, o tareas heterogéneas que se beneficien de un contexto enfocado. Construir esto antes de sentir la necesidad solo añade complejidad innecesaria.

Evals y conjuntos de datos dorados

Todo equipo que entrega agentes confiables tiene eval. Sin eval, no se puede confiar en el agente. Es la práctica con mayor apalancamiento en este campo, y la que más subestimada está en muchas empresas.

La práctica efectiva es: recopilar traces en producción, marcar los fallos, y usarlos como un conjunto de regresión. Cada fallo nuevo que se despliega, se añade. La parte subjetiva se evalúa con un LLM como juez, y la parte objetiva con coincidencias exactas o verificaciones programadas. Antes de cambios en prompts, modelos o herramientas, ejecuta el suite de pruebas. Un blog de Spotify reportó que su capa de juez intercepta aproximadamente el 25% de las salidas del agente antes de llegar al usuario. Sin ella, uno de cada cuatro resultados malos llega a producción.

La mentalidad clave es: eval es como un test unitario que asegura que, en medio de cambios constantes, el agente sigue cumpliendo su función. Los modelos se actualizan, los frameworks cambian, los proveedores dejan de soportar ciertos endpoints. Tu eval es lo único que te dice si el agente aún funciona. Sin ella, estás confiando en un sistema con objetivos móviles y sin garantías.

Frameworks de eval, como Braintrust, Langfuse evals, LangSmith, son útiles, pero no son el cuello de botella. La verdadera limitación es si tienes un conjunto de datos anotados desde el inicio. Comienza a hacerlo desde el primer día, con unas 50 muestras anotadas a mano en una tarde. No hay excusas.

Usa el sistema de archivos como estado, y el ciclo Think-Act-Observe

Para cualquier agente que realice tareas múltiples y reales, la arquitectura duradera es: pensar, actuar, observar, repetir. El sistema de archivos o almacenamiento estructurado es la fuente de verdad. Cada acción se registra y puede ser reproducida. Claude Code, Cursor, Devin, Aider, OpenHands, goose, todos convergen en esto, por una razón.

El modelo en sí es sin estado. El framework que lo ejecuta debe ser con estado. El sistema de archivos es un primitive con estado que todos entienden. Al adoptar este marco, las disciplinas de harness se despliegan naturalmente: checkpoints, recuperación, validación de subagentes, sandboxing.

Una enseñanza más profunda es que: en cualquier agente productivo, el trabajo que hace harness supera al del modelo. El modelo decide la próxima acción, harness la valida, la ejecuta en sandbox, captura la salida, decide qué retroalimentar, cuándo detenerse, cuándo hacer checkpoint, cuándo crear subagentes. Cambiar el modelo por otro de igual calidad no altera la funcionalidad. Pero si el harness es peor, incluso el mejor modelo generará un agente que olvida lo que está haciendo.

Si tu sistema es más complejo que una simple llamada a una herramienta, la inversión más valiosa está en harness. El modelo es solo un componente.

Entendiendo MCP desde el concepto

No basta con aprender a llamar al servidor MCP. Hay que entender su modelo. MCP establece una separación clara entre capacidades, herramientas y recursos, y proporciona un esquema escalable de autenticación y transmisión. Una vez que comprendes esto, otros «marcos de integración de agentes» parecen versiones simplificadas de MCP, y ahorras tiempo en evaluarlos uno a uno.

La Linux Foundation ahora gestiona MCP. La mayoría de los principales proveedores de modelos lo soportan. Es como el «USB-C de la IA», y cada vez más cercano a la realidad que a la sátira.

La sandboxing es un primitive fundamental

Todo agente de codificación en producción corre en sandbox. Todos los agentes en navegador han enfrentado prompt injection indirecto. Todos los agentes multiinquilino, en algún momento, han tenido bugs en permisos. La sandboxing debe considerarse una primitive básica, no una función adicional que se añade tras la solicitud del cliente.

Aprende los conceptos básicos: aislamiento de procesos, control de salidas de red, gestión de claves, límites de autenticación entre agente y herramientas. Los equipos que solo añaden esto tras auditorías de seguridad, suelen perder oportunidades. Los que lo integran desde la primera semana, facilitan la aprobación en procesos de compra corporativos.

Qué usar para construir

Estas son las opciones concretas a abril de 2026. Cambiarán, pero no demasiado rápido. En esta capa, elige lo «aburrido pero estable».

Capa de orquestación

LangGraph es la opción predeterminada en producción. Aproximadamente un tercio de las grandes empresas que operan agentes lo usan. Su abstracción refleja la realidad de los sistemas de agentes: estado tipificado, límites condicionales, flujos de trabajo persistentes, checkpoints con revisión humana. Es verboso, pero cuando un agente entra en producción, necesitas ese control, y su verbosidad corresponde a esas necesidades.

Si usas principalmente TypeScript, Mastra es la opción más clara. Es la que tiene el modelo mental más transparente en este ecosistema.

Si prefieres Pydantic y quieres que la seguridad de tipos sea una prioridad, Pydantic AI es una opción sólida y de greenfield. Lanzada en 2025, tiene buen impulso.

Para trabajos nativos de proveedor, como uso de computación, voz o interacción en tiempo real, usa el SDK de Claude Agent o OpenAI Agents en nodos de LangGraph. No intentes que sean un orquestador heterogéneo; están optimizados para sus escenarios específicos.

Capa de protocolos

MCP, sin duda.

Integra tus herramientas como un servidor MCP. La integración externa también debe seguir este esquema. La registry de MCP ya ha superado un umbral: en la mayoría de los casos, ya puedes usar un servidor existente en lugar de construir uno desde cero. En 2026, seguir escribiendo plumbing personalizado es casi un desperdicio.

Capa de memoria

Al elegir un sistema de memoria, no te dejes llevar por la moda, sino por el grado de autonomía del agente.

Mem0 funciona bien para personalización conversacional ligera: preferencias del usuario, historial breve. Zep es para sistemas de diálogo en producción, especialmente cuando el estado evoluciona y requiere seguimiento de entidades. Letta es para agentes que necesitan mantener coherencia en días o semanas. La mayoría no lo necesita, pero quienes sí, lo valoran mucho.

Error común: antes de tener problemas de memoria, implementas un marco de memoria completo. Comienza con lo que puede caber en la ventana de contexto, y añade una base de vectores solo cuando entiendas claramente qué fallos quieres solucionar.

Observabilidad y evals

Langfuse es la opción open source predeterminada. Puede autoalojarse, bajo licencia MIT, cubre tracing, gestión de versiones de prompts y evals básicos con LLM como juez. Si usas LangChain, la integración con LangSmith es más estrecha. Braintrust es para flujos de trabajo de evaluación investigativa, especialmente en comparaciones rigurosas. OpenLLMetry / Traceloop son para stacks multilenguaje con instrumentación OpenTelemetry neutral.

Necesitas tener tanto tracing como evals. Tracing responde a «¿qué hizo exactamente el agente?», y evals a «¿mejoró o empeoró respecto a ayer?». Sin ambas, no pongas en producción. Configúralas desde el inicio, mucho más barato que hacerlo a posteriori.

Runtime y sandbox

E2B es para ejecución de código en sandbox general. Browserbase con Stagehand para automatización en navegador. Anthropic Computer Use para control de escritorio a nivel de sistema operativo real. Modal para tareas cortas y puntuales.

Nunca ejecutes código sin sandbox. Un agente vulnerado por prompt injection, si se ejecuta en producción, puede causar un desastre difícil de controlar y que no quieres explicar.

Modelos

Seguir benchmarks es agotador y, en la mayoría de los casos, poco útil. Desde ahora, hasta abril de 2026:

·Claude Opus 4.7 y Sonnet 4.6 son ideales para llamadas confiables, tareas de múltiples pasos y recuperación elegante de fallos. Para la mayoría de cargas, Sonnet ofrece la mejor relación costo-rendimiento.

·GPT-5.4 y GPT-5.5 son para quienes necesitan capacidades de razonamiento en CLI o terminal, o ya trabajan en infraestructura OpenAI.

·Gemini 2.5 y 3 son para contextos largos o tareas multimodales intensas.

· Cuando el costo importa más que el rendimiento máximo, especialmente en tareas con límites claros y definiciones estrechas, considera DeepSeek-V3.2 o Qwen 3.6.

Considera los modelos como componentes intercambiables. Si tu agente solo funciona con uno, no es una ventaja competitiva, sino un problema. Usa evals para decidir qué modelo desplegar, y reevalúa cada trimestre, no cada semana.

Qué saltarse

Siempre te aconsejarán aprender y usar estas cosas, pero en realidad no es necesario. Saltárselas tiene un costo muy bajo y ahorra mucho tiempo.

AutoGen y AG2, no para producción.
El framework de Microsoft ha pasado a ser mantenido por la comunidad, con ritmo de publicación lento y una abstracción que no se ajusta a las necesidades reales de los equipos productivos. Está bien para exploración académica, pero no para productos.

CrewAI, no para construir sistemas productivos nuevos.
Se ve mucho porque sirve para demos, pero los ingenieros que construyen en producción ya lo están dejando. Puedes usarlo para prototipos, pero no para una implementación a largo plazo.

Microsoft Semantic Kernel, solo si ya estás muy integrado en el stack empresarial de Microsoft y tu cliente también.
No es la dirección que está tomando el ecosistema.

DSPy, solo si estás optimizando prompts a gran escala.
Tiene valor filosófico, pero su audiencia es limitada. No es un marco universal para agentes, ni debe considerarse como tal.

Usar un agente de código independiente como arquitectura.
Code-as-action es una línea de investigación interesante, pero aún no es la norma en producción. Encontrarás problemas de herramientas y seguridad, que tus competidores probablemente no enfrentan.

Promoción de «agente autónomo».
AutoGPT y BabyAGI ya están muertos en su forma de producto. La industria ahora habla de «ingeniería agentic»: supervisado, con límites y evaluación. Quienes aún venden «agentes que no requieren mantenimiento después del despliegue» en 2026, venden tecnología de 2023.

App stores y marketplaces de agentes.
Desde 2023, algunos prometen esto, pero nunca han ganado tracción real en empresas. Las empresas prefieren agentes verticales ligados a resultados específicos o construir los suyos propios. No diseñes tu negocio en torno a un sueño de app store.

Cuidado con plataformas horizontales «build any agent».
Ejemplos: Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio. Pueden ser útiles en el futuro, pero ahora son caóticas y lentas. La decisión suele ser: construir un agente estrecho o comprar uno vertical. Salesforce Agentforce y ServiceNow Now Assist son excepciones, porque ya están integrados en los flujos de trabajo existentes.

No sigas los rankings de SWE-bench o OSWorld.
Investigadores de Berkeley en 2025 documentaron que casi todos los benchmarks públicos pueden ser manipulados sin resolver realmente las tareas subyacentes. Ahora, los equipos confían más en benchmarks internos y en análisis de postmortem. Desconfía de los saltos en métricas unidimensionales.

Arquitecturas ingenuas de multi-agentes paralelos.
Cinco agentes en chat con memoria compartida parecen impresionantes en una demo, pero en producción se desmoronan. Si no puedes dibujar en una servilleta un esquema claro de orquestador y subagentes, con límites de lectura y escritura, no pongas en marcha.

No uses precios por asiento en nuevos productos de agentes.
El mercado se mueve hacia modelos basados en resultados y uso. Cobrar por usuario solo reduce tus ganancias y envía una señal de que no confías en tu producto.

La próxima tendencia que veas en Hacker News.
Espera seis meses. Si sigue siendo importante, lo notarás. Si no, te ahorras una migración innecesaria.

Cómo avanzar

Si no solo quieres «seguir a los agentes», sino realmente adoptarlos, este orden funciona. Es aburrido, pero efectivo.

Primero, elige un resultado importante. No empieces con un proyecto de plataforma horizontal. Escoge algo que tu negocio ya valore y que puedas medir: reducir tickets de soporte, generar un primer borrador de revisión legal, filtrar leads entrantes, preparar informes mensuales. El éxito del agente se mide por si mejora ese resultado, y ese será tu objetivo de evaluación desde el principio.

Este paso es crucial porque define todas las decisiones siguientes. Con un resultado concreto, «qué marco usar» deja de ser una cuestión filosófica y pasa a ser una elección basada en qué puede entregarlo más rápido. «Qué modelo usar» ya no es solo una discusión de benchmarks, sino una decisión basada en qué evals prueban que funciona en esa tarea específica. «¿Necesitamos memoria, subagentes, harness personalizado?» Deja de ser una hipótesis y solo se añade cuando los fallos reales lo requieren.

Los equipos que omiten este paso terminan con plataformas horizontales que nadie necesita. Los que lo toman en serio, entregan agentes estrechos pero que en un trimestre ya generan retorno. Y ese agente, en producción, les enseña más que dos años de leer artículos.

Antes de desplegar, configura tracing y evals. Usa Langfuse o LangSmith, y conecta todo. Si es necesario, crea un pequeño dataset dorado: 50 muestras anotadas a mano en una tarde. No hay excusas: no puedes mejorar lo que no puedes medir. Agrega este sistema después, pero el costo será unas 10 veces mayor que hacerlo desde el inicio.

Comienza con un ciclo simple de un solo agente. Usa LangGraph o Pydantic AI. Modelos como Claude Sonnet 4.6 o GPT-5. Da al agente de tres a siete herramientas bien diseñadas. Usa archivos o bases de datos para el estado. Prueba con un grupo reducido de usuarios y revisa los traces.

Considera al agente como un producto, no solo un proyecto. Fallará de formas imprevistas, y esas fallas serán tu hoja de ruta. Usa traces reales en producción para construir un conjunto de regresión. Cada cambio en prompts, modelos o herramientas debe pasar por evals antes de desplegar. La mayoría subestima esta inversión, pero la confiabilidad proviene de aquí.

Solo cuando hayas «ganado» la capacidad de escalar, introduce subagentes. Cuando la ventana de contexto no sea suficiente, añade memoria. Cuando los APIs básicos fallen, incorpora uso de computación o navegación. No diseñes esas cosas por adelantado; deja que los fallos te las muestren.

Elige infraestructura simple y estable. Usa MCP para herramientas, E2B o Browserbase para sandbox, Postgres para estado, y los sistemas existentes para autenticación y observabilidad. La infraestructura rara vez decide el resultado; la disciplina sí.

Desde el primer día, monitorea la economía del agente: costo por acción, tasa de aciertos, reintentos, distribución de llamadas a modelos. Un PoC puede parecer barato, pero si no monitoreas, en escala puede costar millones. Un ejemplo: una ejecución de 0.50 USD puede escalar a 50,000 USD mensuales si no controlas los costos.

Reevalúa modelos cada trimestre, no cada semana. Usa tu eval suite para probar los modelos más recientes al final de cada trimestre. Si los datos indican que hay que cambiar, hazlo. Así, aprovechas los avances sin perder estabilidad.

Cómo detectar tendencias

Aquí algunos signos que indican que algo puede ser una señal real: un equipo respetado publica un postmortem con cifras, no solo anuncios; es un primitive fundamental, no solo un envoltorio; puede interoperar con tus sistemas existentes, no solo reemplazarlos; su pitch explica qué fallos resuelve, no solo qué capacidades abre; lleva tiempo en el mercado, y alguien ha escrito sobre qué no funcionó.

Por otro lado, señales de ruido: 30 días después solo hay videos demo, sin casos en producción; benchmarks que suben sin razón aparente; uso indiscriminado de términos como «autonomous», «agent OS» o «build any agent»; documentación que asume que eliminarás tracing, autenticación y configuración existentes; crecimiento en estrellas sin aumento en commits o contribuyentes; velocidad en Twitter sin respaldo en GitHub.

Un hábito semanal útil: dedicar 30 minutos los viernes a revisar el campo. Lee tres cosas: el blog de Anthropic, las notas de Simon Willison, Latent Space. Si hay un postmortem esa semana, lee uno o dos más. Lo demás puedes saltártelo. Lo que realmente importa, no lo perderás.

Qué observar en los próximos meses

Los próximos dos trimestres, no se trata solo de que algo gane, sino de si es una verdadera señal: «¿Qué necesito ver en seis meses para creer que esto importa?». Esa es la prueba. Sigue las respuestas, no solo los anuncios.

Replit Agent 4 y su modelo de forking paralelo.
Es uno de los primeros en intentar que varios agentes trabajen en paralelo sin compartir estado, y que funcione a escala. Si funciona, puede cambiar el modo en que se usan los orquestadores y subagentes.

Madurez de los precios basados en resultados.
Sierra y Harvey ya validaron en nichos estrechos. La pregunta es si se extenderá a otros ámbitos o seguirá siendo una solución vertical.

Las skills como capa de encapsulación de capacidades.
El aumento de archivos como AGENTS.md y directorios de skills en GitHub indica una tendencia a estandarizar capacidades. ¿Se convertirán en un estándar como MCP? Es una pregunta abierta.

El retroceso en calidad de Claude Code en abril de 2026 y su análisis.
Un líder del sector lanzó una versión que causó un 47% de retroceso en rendimiento, y fue la comunidad quien lo detectó primero. Esto muestra que incluso en los mejores, la evaluación en producción aún no está madura. Si esto impulsa a la industria a invertir en mejores evals en línea, será positivo.

La voz como interfaz predeterminada de atención al cliente.
Sierra ya tiene más interacción por voz que por texto. Si esto se extiende, problemas como latencia, interrupciones y llamadas en tiempo real se convertirán en prioridades, y muchas arquitecturas tendrán que cambiar.

La brecha en capacidades de agentes open source.
Modelos como DeepSeek-V3.2 y Qwen 3.6, que soportan thinking-into-tool-use y ecosistemas más amplios, están cerrando la diferencia. Los costos en tareas específicas cambian rápidamente. La supremacía de modelos cerrados no será eterna.

Cada uno de estos puntos puede responder a la pregunta: «¿Qué necesito ver en seis meses para creer que esto importa?». Esa es la prueba. Sigue las respuestas, no solo los anuncios.

Apuestas contra la intuición

Cada marco que no adoptes es una migración que no tendrás que hacer en el futuro. Cada benchmark que ignores, es un trimestre de concentración. Las empresas que están ganando ahora —Sierra, Harvey, Cursor— han optado por objetivos estrechos, disciplina aburrida, y dejan que el ruido pase.

La ruta tradicional es: escoger una pila tecnológica, dominarla durante años, y avanzar paso a paso. Cuando esa pila dura una década, funciona. Pero ahora, las pilas cambian cada trimestre. Los verdaderos ganadores no optimizan la maestría en una pila, sino el gusto, los primitives y la velocidad de entrega. Construyen cosas pequeñas, aprenden entregando. La obra misma es la experiencia.

Reflexiona en esto, porque es lo que realmente quiere decir el artículo. La mayoría de nosotros trabaja bajo la suposición de que el mundo será estable lo suficiente para que la experiencia compuesta tenga sentido: estudiar, obtener títulos, escalar. Pasar dos años aquí, tres allá, y que el currículum abra puertas. La premisa es que la industria es estable.

Pero en el campo de los agentes, no hay un «otro lado» estable. Las empresas que quieres unirte pueden tener solo seis meses. Los frameworks que usan, solo un año y medio. Los protocolos, solo dos años. La mitad de los artículos más citados tienen autores que hace tres años ni estaban en esto. No hay una escalera que subir, porque el edificio está en constante cambio. Cuando la escalera falla, la única opción es hacer algo y ponerlo en línea, dejando que el trabajo hable por ti. Es una ruta contra la intuición, que evita los sistemas de certificación de experiencia. Pero en un campo en movimiento, es la única forma de crecer de forma compuesta.

Es la visión del campo desde adentro. Incluso los gigantes iteran públicamente, publican análisis, corrigen en línea. Los equipos que entregan lo más interesante en 18 meses, quizás hace un año ni estaban en esto. Personas que no programan, colaboran con agentes, entregan software real. Los doctores en ML pueden ser superados por quienes eligen primitives sólidos y actúan rápido. La puerta ya está abierta. La mayoría todavía busca cómo entrar.

La habilidad más importante ahora no es «crear agentes», sino la disciplina de saber qué trabajo puede crecer de forma compuesta en un entorno cambiante. Ingeniería de contexto, diseño de herramientas, modo orquestador-subagente, evaluación, harness: todas esas habilidades crecen de forma compuesta. Cuando puedas distinguirlas, las nuevas publicaciones semanales dejarán de ser presión y pasarán a ser ruido que puedes ignorar.

No necesitas aprender todo. Solo las habilidades que crecen de forma compuesta, y saltarte las que no. Escoge un resultado, conecta tracing y evals antes de desplegar. Usa LangGraph o herramientas similares. Usa MCP. Pon el runtime en sandbox. Comienza con un solo agente. Solo cuando los fallos reales te obliguen, amplía el alcance. Reevalúa modelos cada trimestre. Los viernes, lee tres cosas.

Este es tu playbook. Lo demás es gusto, velocidad de entrega, y paciencia para no perseguir lo irrelevante.

Construye cosas. Ponlas en línea. La era premia a quienes hacen cosas, no solo a quienes las describen. Ahora es la mejor oportunidad para ser esa «persona que realmente hace cosas».