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 de experiencia eran la tarjeta de entrada a la industria; pero en un campo donde incluso los gigantes aún están en fase de prueba y error pública, 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 la capacidad de discernir qué vale la pena aprender y seguir produciendo cosas realmente útiles.

A continuación, 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. Los benchmarks que optimizaste, tras ser superados, son rápidamente reemplazados por otros nuevos. Antes, nos entrenaban para avanzar por una ruta tradicional: una pila tecnológica, con un conjunto de temas y niveles; una serie de experiencias laborales, con años y títulos; avanzando lentamente paso a paso. 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 tomado una decisión impopular pero correcta, que luego se demostró acertada. Esa capacidad de juicio se beneficia del interés compuesto. 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 o en dos años. Quien gane en el largo plazo será aquel que desde temprano haya elegido 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 trabajo en una empresa en modo stealth, liderando tecnología. 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 de las grandes empresas 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 de usuarios detecta el problema, entonces la idea de que «hay un mapa estable debajo» es ficticia. Todos todavía estamos explorando. La oportunidad para startups surge porque incluso los gigantes no tienen la respuesta. Personas que no programan están colaborando con agentes, entregando cosas que en martes un doctor en aprendizaje automático consideraría imposibles, y entregándolas en viernes.

Lo más interesante de este momento es que cambia nuestra percepción de la «experiencia». La ruta tradicional valora la experiencia: títulos, puestos iniciales, avanzados y 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 para todos. Un joven de 22 años que publica un demo de un agente y un ingeniero senior de 35, ya no solo difieren en años de dominio técnico. Ambos enfrentan la misma hoja en blanco. Para ellos, lo que realmente genera beneficios a largo plazo es la voluntad de entregar continuamente, y esa pequeña parte de habilidades duraderas que no se vuelven obsoletas en un trimestre.

Este es el núcleo de la reconstrucción del artículo. A continuación, propongo un método de juicio: qué habilidades fundamentales vale la pena que inviertas, y qué lanzamientos puedes simplemente ignorar. Lo que te sirva, tómalo; lo que no, déjalo.

Filtros verdaderamente efectivos

No puedes seguir cada semana los nuevos lanzamientos, y no deberías. 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 es solo 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 primitivo fundamental, como un protocolo, un modo de memoria, o un método sandbox, probablemente sí. Los productos envoltorio tienen una vida media corta; los primitives fundamentales pueden durar años.

¿Algún referente respetado 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 experimentar.

¿Adoptarlo implica abandonar 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 forzarte a migrar.

¿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 prueba te permite saltarte el 90% de los lanzamientos sin ansiedad. Pero también es la que más rechazo genera, porque saltarse algo da la sensación de quedarse atrás. La realidad, sin embargo, es otra.

¿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 de regresión en línea. Con evaluación, los datos te dirán si, en una carga de trabajo específica, GPT-5.5 es mejor que Opus 4.7, por ejemplo.

Si solo tomas una cosa de este artículo, que sea: cada vez que algo nuevo se lanza, escribe qué necesitas ver en seis meses para creer que realmente importa. Luego, vuelve a revisar en ese plazo. La mayoría de las veces, la respuesta ya está en los datos, y tu atención se dirigirá a lo que realmente puede generar beneficios a largo plazo.

Las habilidades que sustentan estas pruebas son más difíciles de nombrar que las propias pruebas. Es una habilidad para «no seguir la moda». La tendencia en Hacker News puede hacer que un marco sea popular en 14 días, y en 60 días, la mitad de los que lo apoyan ya no lo mantienen. Los que no participan en esas modas ahorran energía, y la dirigen a cosas que, tras la fiebre, siguen siendo relevantes y resistentes a la obsolescencia. La moderación, la observación y la frase «en seis meses sabré» son habilidades profesionales reales en este campo. Todos leen los anuncios, pero pocos saben cómo no reaccionar ante ellos.

Qué aprender

Conceptos, patrones, formas de las cosas. Lo que realmente genera beneficios a largo plazo 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 volver a aprender superficialidades una y otra vez.

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 colocas en la ventana de contexto.

Debes internalizar que: el contexto es estado. Cada token innecesario 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 activamente resumen, comprimen y recortan el contexto. Gestionan versiones de las descripciones de herramientas, almacenan en caché las partes estáticas y rechazan las partes variables. La forma en que ven la ventana de contexto es como un ingeniero experimentado que gestiona memoria.

Una forma concreta de sentir esto es abrir el trace completo de un agente en producción, revisar el contexto en el primer paso y en el séptimo, y contar cuántos tokens aún están en uso. La primera vez que haces esto, probablemente te sentirás incómodo. 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 cifras la importancia de la aislamiento del contexto 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 capacidades 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 errores 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. Tras leerlo, añade observaciones a tus propias herramientas 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 esto.

Modo orquestador-subagente

Las discusiones sobre multi-agentes en 2024 y 2025 convergieron en una solución integrada que ahora todos adoptan. Los sistemas ingenuos de múltiples agentes, donde varios agentes escriben en un estado compartido, fracasan catastróficamente por acumulación de errores. La escala de un solo agente puede ser mayor de lo que imaginas. 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 ahora estandarizan este modo. Los subagentes tienen contextos pequeños y enfocados, sin modificar el estado compartido. La escritura la realiza 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 el límite del contexto o la latencia por llamadas secuenciales a herramientas se vuelvan un problema, considera usar orquestador y subagentes. 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 fallos, y usarlos como conjunto de regresión. Cada fallo nuevo que se detecta, se añade. La evaluación subjetiva puede usar LLM como juez, y las verificaciones automáticas, coincidencias exactas o checks programáticos. Antes de cambios en prompt, modelo o herramienta, correr la suite de pruebas. Un informe de Spotify indica que su capa de juez intercepta aproximadamente el 25% de las salidas malas antes de llegar al usuario. Sin ella, uno de cada cuatro resultados negativos llega a producción.

La mentalidad clave es: eval es como un test unitario que asegura que, en medio de cambios constantes, el agente no se desvíe de su función. Los modelos se actualizan, los frameworks cambian, los proveedores dejan de soportar endpoints. Tu eval es lo único que te dice si el agente sigue funcionando bien. Sin eval, estás confiando en un sistema con objetivos móviles.

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

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

Para cualquier agente que realice tareas múltiples, una 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. Adoptar este marco hace que las disciplinas de harness se desplieguen naturalmente: checkpoints, recuperación, validación de subagentes, sandboxing.

Una enseñanza más profunda es que, en cualquier agente de producción que justifique el gasto computacional, el trabajo del harness supera al del modelo. El modelo decide la próxima acción, el harness la valida, la ejecuta en sandbox, captura la salida, decide qué feedback dar, 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 puede producir 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 el harness. El modelo es solo un componente.

Comprender MCP conceptualmente

No basta con aprender a llamar al servidor MCP. Hay que entender su modelo. MCP establece una separación clara entre capacidades del agente, 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 limitadas de MCP, y ahorras tiempo en evaluarlos uno por 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»: cada vez más cercano a la realidad que a la sátira.

La sandboxing es un primitive fundamental

Cada agente de codificación en producción corre en sandbox. Cada agente en navegador ha enfrentado prompt injection indirecto. Cada agente multiinquilino ha tenido bugs en permisos en algún momento. La sandboxing debe considerarse una infraestructura 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, esas funciones son necesarias, y su verbosidad corresponde a esas necesidades.

Si usas principalmente TypeScript, Mastra es la opción más madura. Es el marco con el modelo mental más claro en este ecosistema.

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

Para trabajos nativos del 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 orquestadores heterogéneos; están optimizados para sus casos 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. El registry de MCP ya ha superado un umbral: en la mayoría de los casos, ya hay un servidor listo para usar, sin necesidad 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: preferencias del usuario, historial ligero. 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 ciclos de días o semanas. La mayoría no lo necesita, pero quienes sí, lo valoran mucho.

Error común: antes de resolver el problema 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 instrumentación con OpenTelemetry en múltiples lenguajes, sin vendor lock-in.

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, el costo es mucho menor que añadirlas después de un despliegue ciego.

Entorno de ejecución y sandbox

E2B 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. 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.

Modelos

Seguir benchmarks es agotador y, en la mayoría de los casos, poco útil. Desde abril de 2026, en términos prácticos:

·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 las cargas, Sonnet ofrece la mejor relación costo-rendimiento.

·GPT-5.4 y GPT-5.5 son para capacidades de razonamiento en CLI/terminal, o cuando ya usas infraestructura de OpenAI.

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

·Cuando el costo importa más que el rendimiento máximo, y las tareas son bien definidas y con límites claros, 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

Constantemente te aconsejarán aprender y usar estas cosas, pero en realidad no es necesario. Saltarlas 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 es útil para demos, pero los ingenieros que construyen sistemas en producción ya están migrando fuera. Puedes usarlo para prototipos, pero no para producción a largo plazo.

Microsoft Semantic Kernel, salvo que estés muy integrado en el stack empresarial de Microsoft y tus clientes valoren eso.
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 general para agentes, ni debe serlo.

Usar agentes de escritura de código independientes 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 tendencia real es «ingeniería con agentes supervisados, 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.

Marketplaces y tiendas de agentes.
Desde 2023, algunos prometen esto, pero nunca han ganado tracción real en empresas. Las empresas prefieren agentes verticales específicos o construir los propios. No diseñes tu negocio en torno a un marketplace.

Cuidado con plataformas horizontales «build any agent».
Ejemplos como Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio pueden ser útiles en el futuro, pero ahora son caóticos, lentos y la relación coste-beneficio suele favorecer 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 prefieren usar benchmarks internos y análisis de postmortem. Desconfía de los saltos en métricas numéricas.

Arquitecturas ingenuas de multi-agentes paralelos.
Cinco agentes en chat con memoria compartida parecen impresionantes en demos, pero en producción fallan. 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 productos de agentes.
El mercado se mueve hacia modelos basados en resultados y uso. Cobrar por asiento 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 de agentes» a lo grande. 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 depende de si mejora ese resultado, y desde el primer día esa es tu meta de evaluación.

Este paso es crucial porque limita todas las decisiones posteriores. Con un resultado claro, «qué marco usar» deja de ser una cuestión filosófica; eliges el que más rápido entregue ese resultado. «Qué modelo usar» ya no es una discusión de benchmarks, sino la elección del modelo que tu evaluación demuestra 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 específicos lo requieran.

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 se recuperan. Y ese agente, en producción, les enseña más que dos años de lectura.

Antes de desplegar, configura tracing y evals. Usa Langfuse o LangSmith, y conecta todo. Si es necesario, crea un pequeño conjunto de datos dorados, unas 50 muestras anotadas en una tarde. No puedes mejorar lo que no puedes medir. Añadir esto después cuesta unas 10 veces más.

Comienza con un ciclo simple: 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 almacenamiento en archivos o bases de datos para estado. Prueba con un grupo reducido de usuarios, revisa 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 prompt, modelo o herramienta debe pasar por evals antes de desplegar. La mayoría subestima esto, 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 la API básica no sea suficiente, incorpora uso de computación o navegador. No diseñes esas cosas antes de que los fallos las exijan; déjalas surgir de los fallos.

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

Desde el primer día, monitorea la economía del agente: costo por acción, tasa de cache hits, ciclos de reintento, distribución de llamadas a modelos. Un PoC puede parecer barato, pero si no monitoreas, cuando escale 100 veces, el costo se disparará. Un PoC de 0.50 USD por ejecución puede costar 50,000 USD mensuales en escala media. Sin prever esto, llegarás a una reunión con el CFO que no te gustará.

Reevalúa modelos cada trimestre, no cada semana. Fija un ciclo trimestral. Al final, corre tu suite de evals con el modelo más avanzado. Si los datos indican que hay que cambiar, hazlo. Así, aprovechas los avances sin perderte en cambios constantes.

Cómo detectar las tendencias

Aquí algunos signos claros de 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 envoltorios; puede interoperar con tus sistemas existentes, no 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ó.

Signos de ruido: 30 días después, solo hay videos demo, sin casos reales; los benchmarks parecen demasiado perfectos; usan términos como «autonomous», «agent OS» o «build any agent» sin límites claros; la documentación asume que eliminarás tracing, autenticación y configuración existentes; los stars crecen, pero los commits y releases no; en Twitter hay mucho movimiento, en GitHub menos.

Un hábito semanal útil: dedicar 30 minutos los viernes a revisar el campo. Leer tres cosas: el blog de Anthropic, las notas de Simon Willison, Latent Space. Si hay un postmortem, lee uno o dos más. Lo importante, no lo perderás.

Qué observar en los próximos meses

Lo que valdrá la pena en los próximos dos trimestres no es que ganen, sino que aún no está claro si son señales reales o solo ruido.

El modelo de fork paralelo de Replit Agent 4.
Es uno de los primeros en intentar «varios agentes en paralelo» sin que el estado compartido sea un problema. Si escala bien, el modo orquestador-subagente puede cambiar.

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 solo funciona en verticales específicos.

Las skills como capa de encapsulación de capacidades.
El aumento de archivos 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 de calidad de Claude Code en abril de 2026 y su análisis.
Un líder del sector lanzó una versión con un 47% de retroceso en rendimiento, detectado por usuarios y monitoreo interno. Esto muestra que incluso en los mejores, la evaluación en producción aún no está madura. Si esto impulsa más inversión en evals en línea, será un paso saludable.

La voz como interfaz predeterminada de atención al cliente.
Sierra superó en 2025 el uso de texto. Si esto se extiende, la latencia, interrupciones y llamadas en tiempo real serán problemas de primera clase, y muchas arquitecturas deberán cambiar.

La brecha en capacidades de modelos open source.
DeepSeek-V3.2 soporta thinking-into-tool-use, Qwen 3.6 y ecosistemas open source. Los costos en tareas específicas cambian, y los modelos cerrados no serán siempre superiores.

Cada uno de estos signos puede responder a la pregunta: «¿Qué necesito ver en seis meses para creer que esto es importante?» 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. Empresas como Sierra, Harvey y Cursor, en sus respectivos campos, eligieron objetivos estrechos, establecieron disciplina, y dejaron que el ruido pasara.

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

Reflexiona sobre 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 genere beneficios compuestos. Vas a la escuela, obtienes un título, avanzas en la escalera. Pasas dos años aquí, tres allá, y tu currículum se vuelve tu llave. La premisa es que la industria es estable.

Pero en el campo de los agentes, no hay un «otro lado» estable. Las empresas en las que quieres trabajar pueden tener solo seis meses. Los frameworks que usan, solo 18 meses. 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 el campo. No hay escalera, porque la construcción está en constante cambio. Cuando la escalera falla, la única opción es hacer algo diferente: publicar en línea, dejar que el trabajo hable por sí mismo. Es una estrategia contra la intuición, que evita la certificación de experiencia. Pero en un campo en movimiento, es la única forma de beneficios a largo plazo.

Así se ve el 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 menos, y algunos ni programan. Personas que no programan están colaborando con agentes, entregando software real. Los doctores en ML pueden ser superados por quienes eligen primitives sólidos y actúan rápido. La puerta está abierta. La mayoría todavía busca cómo entrar.

La habilidad más importante ahora no es «crear agentes», sino la disciplina para discernir qué trabajos pueden generar beneficios compuestos en un campo superficialmente cambiante. Ingeniería de contexto, diseño de herramientas, modo orquestador-subagente, evaluación, pensamiento en harness: todas esas habilidades generan beneficios a largo plazo. 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 generan beneficios a largo plazo, 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 te obliguen, amplía el alcance. Reevalúa modelos cada trimestre. Lee tres cosas los viernes.

Este es tu playbook. El resto es gusto, velocidad y paciencia para no perseguir lo irrelevante.

Construye cosas. Súbelas a internet. La era premia a quienes hacen, no solo a quienes describen. Ahora es la mejor oportunidad para ser esa persona que realmente crea.

[Enlace al original]

Haz clic para conocer las vacantes de律动BlockBeats

Únete a la comunidad oficial de律动BlockBeats:
Telegram suscripción: https://t.me/theblockbeats
Telegram grupo: https://t.me/BlockBeats_App
Twitter oficial: https://twitter.com/BlockBeatsAsia