Claude Code 2.1.144, Cursor Composer 2.5, Stainless, Notion, Vercel AI SDK y Cloudflare Mesh

[NOVA]: Soy NOVA.

[ALLOY]: Y yo soy ALLOY, y esto es AgentStack Daily. Hoy empezamos con la superficie de código que más tocan los constructores de agentes todos los días: el Claude Code CLI, con la versión 2.1.144.

[NOVA]: Esta es una versión de mantenimiento, y precisamente por eso va al frente. Apunta a las superficies donde los agentes desatendidos realmente fallan: sesiones en segundo plano y separadas, comportamiento de inicio en una red mala, la capa de transporte MCP, e higiene de llamadas a herramientas. No nuevas características por sí mismas. Eliminación de modos de falla.

[ALLOY]: Después del resumen del lanzamiento, cinco movimientos más que cambian cómo los constructores eligen, conectan y ejecutan sus herramientas. Cursor lanzó Composer 2.5, un modelo de agente de código sobre una base Kimi K2.5 a roughly un décimo del costo por token de frontier. Anthropic adquirió Stainless, el servicio que convertía especificaciones de API en bibliotecas de cliente tipadas para una larga lista de laboratorios de IA. Notion convirtió su espacio de trabajo en un runtime alojado donde ejecutan agentes. El Vercel AI SDK reescribió su adaptador de LangChain y LangGraph. Y Cloudflare puso networking de cero-confianza e identidad bajo el ciclo de vida del agente con Mesh.

[NOVA]: La pregunta práctica en los tres es la misma. ¿Cuál de estos cambios hace el trabajo de agentes más confiable, más recuperable, y más fácil de confiar cuando la ejecución es larga, desatendida, o cruza un límite hacia la API de alguien más?

[ALLOY]: Así que nos manteremos concretos, y nos manteremos en lo que un constructor debería hacer realmente: ciclos de vida de sesiones, paginación de transporte, timeouts en redes degradadas, formación de recompensas para modelos que usan herramientas, fidelidad del harness, y el límite tipado entre un agente y los servicios que llama. ...

[NOVA]: Vale la pena decir de entrada por qué una versión puntual de una herramienta de línea de comandos ocupa el frente del episodio en lugar de un lanzamiento llamativo de modelo. El Claude Code CLI es, para muchos equipos, el runtime real donde ejecutan sus agentes. Genera sesiones, mantiene herramientas, habla con servidores MCP, corre en segundo plano, y se recupera cuando algo sale mal. Cuando esa capa cambia cómo se comporta bajo falla, mueve más trabajo real de agente que un número de benchmark.

[ALLOY]: Y la 2.1.144 es casi entièrement trabajo de modo de falla. Un bloqueo de inicio eliminado. Una lista de herramientas truncada corregida. Un tipo de imagen que solía romper una conversación ahora manejado. Sesiones en segundo plano que se caían en una carpeta protegida ahora estables. Nada de eso es glamoroso. Todo es la diferencia entre una ejecución de agente que completa desatendida y una que silenciosamente se detiene a las tres de la mañana.

[NOVA]: Esa es la lente para todo el bloque de lanzamiento. No qué hay de nuevo para exhibir, sino qué solía fallar y ya no falla, y qué debería cambiar un constructor en cómo despliega agentes por causa de esto.

[ALLOY]: Exacto, y vamos a seguir ربط cada corrección a una decisión concreta de constructor: cuándo usar sesiones en segundo plano, cómo cablear MCP, qué probar antes de enviar un agente desatendido. El lanzamiento solo es útil si cambia cómo operas.

[NOVA]: Resumen de lanzamiento de Agent-stack: Claude Code CLI 2.1.144. Empezamos con el inicio. ...

[NOVA]: La corrección de inicio es el ejemplo más claro de por qué este lanzamiento importa más para agentes que para personas. Antes de la 2.1.144, si el endpoint de API era inalcanzable, el CLI podía bloquearse por hasta setenta y cinco segundos antes de hacer algo útil. Eso pasa detrás de un portal cautivo, un firewall corporativo, o una VPN que no ha terminado de conectar.

[ALLOY]: Un humano lo pega y simplemente espera, quizás se queja. Un agente lo pega de manera muy diferente. Un trabajo programado, una ejecución por lotes desatendida, o una sesión en segundo plano en una red inestable convierte un bloqueo de setenta y cinco segundos en un atasco, un timeout más arriba en la pila, o una ventana de ejecución perdida. La corrección limita las llamadas de canal lateral a quince segundos.

[NOVA]: El principio general para constructores es que la resiliencia de inicio en una red degradada es una propiedad de confiabilidad del agente, no una nicidad cosmética. Cualquier cosa que un agente haga desatendido tiene que asumir que la red a veces está mal en exactamente el momento en que el proceso inicia. Una herramienta que falla rápido y continúa es más confiable que una herramienta que espera cortésmente por algo que no viene.

[ALLOY]: Hay un patrón concreto de constructor aquí. Si despliegas agentes que inician en un horario, deberías tratar el inicio del proceso como un paso que puede ser lento o parcialmente degradado, y deberías probarlo así. El caso de uso a simular no es el camino feliz. Es el portal cautivo, la VPN medio conectada, el DNS que resuelve lentamente. Antes de este lanzamiento el movimiento correcto era agregar tu propio watchdog de inicio. Después de él, el runtime falla rápido por sí mismo, pero todavía deberías verificar eso contra tu propio despliegue.

[NOVA]: Ese es un buen marco. La lección para el constructor es cablear una asunción de salud de inicio en cómo envías agentes desatendidos, y usar este lanzamiento como la cosa que hace que esa asunción se cumpla en lugar de algo que tenías que agregar.

[ALLOY]: El segundo bloque es MCP, el transporte de Protocolo de Contexto de Modelo, y este es el que no saltaría. Antes de este lanzamiento, los servidores MCP que paginan su respuesta de lista de herramientas solo devolvían la primera página. Piensa en lo que eso significa para un agente. El agente se conecta a un servidor de herramientas, pregunta qué herramientas existen, y silenciosamente obtiene una lista parcial.

[NOVA]: Ese es el peor tipo de bug, porque nada da error. El agente no crashea. Simplemente no puede hacer algo que se supone que debía poder hacer, y la ejecución parece un fallo de razonamiento cuando en realidad es un bug de transporte. Pasarías una tarde culpando al modelo por no usar una herramienta que nunca se le dijo que existía.

[ALLOY]: Exactamente. Una brecha de capacidad silenciosa es mucho más difícil de debuggear que un crasheo fuerte. La corrección es que las respuestas paginadas de lista de herramientas ahora siguen a través de cada página, así que el agente ve el conjunto completo de herramientas. Para un constructor que ejecuta un despliegue grande de MCP con decenas de herramientas, esto es la diferencia entre un agente que puede usar todo tu conjunto de herramientas y uno que solo puede usar lo que cabía en la página uno.

[NOVA]: Hay una corrección relacionada para imágenes MCP: una imagen con un tipo MIME no soportado, como un SVG, solía romper la conversación. Ahora se guarda y referencia en su lugar, así que un tipo de contenido extraño no envenena toda la sesión. Si construyes un agente que maneja imágenes proporcionadas por usuarios o capturas de pantalla, eso es un cambio real de robustez, porque no controlas qué tipo de contenido aparece.

[ALLOY]: Y hay una corrección de diagnosticabilidad en la misma área. El comando list para servidores MCP solía reportar silenciosamente que no había servidores cuando la configuración no podía ser analizada. Ahora reporta el problema real. Ese es el mismo tema de nuevo: una respuesta incorrecta silenciosa es reemplazada por una explícita y accionable, que es la propiedad que quieres cuando operas una flota y necesitas triar rápido.

[NOVA]: El patrón de constructor para MCP después de esta versión es: enumera tus herramientas como una verificación en tiempo de despliegue, no como una esperanza. Antes de enviar un agente que depende de un servidor de herramientas, haz que el agente liste las herramientas y afirme que el conjunto completo esperado está presente. Esta versión hace que esa afirmación sea confiable, porque la lista ya no se trunca silenciosamente. Incorpóralo en cómo validas un despliegue.

[ALLOY]: El tercer y más grande bloque son las sesiones en segundo plano y desconectadas. La cantidad de correcciones individuales aquí te dice dónde ha estado realmente el dolor operacional. Las sesiones en segundo plano ahora soportan resume, así que una sesión iniciada en segundo plano aparece junto a las interactivas y puede ser retomadas. Los avisos de finalización ahora incluyen la duración transcurrida, así que un agente que corrió por tres horas lo reporta.

[NOVA]: Ese detalle de duración transcurrida suena menor y no lo es. Si operas agentes de larga duración, la duración es una señal principal. Una tarea que normalmente toma veinte minutos y de repente tomó tres horas te está diciendo algo incluso si tuvo éxito. Mostrar la duración al completar le da al operador una señal de anomalía barata sin construir instrumentación separada.

[ALLOY]: Hay un grupo de correcciones de estabilidad específicas de plataforma que importan para flotas desatendidas. Las sesiones en segundo plano que se caían en macOS cuando el proyecto vivía bajo una carpeta protegida por Full Disk Access están corregidas. En Windows, el desplazamiento, la rueda del mouse y el atajo de navegación en sesiones en segundo plano adjuntas ahora funcionan, y cerrar la terminal mientras está adjunta ya no crashea la sesión.

[NOVA]: Ese de macOS es una trampa clásica del entorno de despliegue. El agente funciona en tu máquina y crashea en el host de build porque el host de build pone el proyecto bajo una carpeta protegida. La lección general para constructores es que la estabilidad de sesiones en segundo plano es sensible al entorno, así que el lugar donde pruebas tiene que coincidir con el lugar donde despliegas. Esta versión elimina una instancia específica de eso, pero el patrón vale la pena internalizarlo.

[ALLOY]: Y uno sutil de corrección: las sesiones reanudadas ahora mantienen el modelo que estaban usando, en lugar de heredar la elección de modelo de alguna otra sesión. Si reanudas un agente de larga duración y este silenciosamente cambia de modelo, tu comportamiento, costo y latencia cambian debajo de ti, y puede que no lo notes hasta que la salida se vea diferente.

[NOVA]: Ese es un peligro real de producción para cualquiera que ejecute una mezcla de modelos entre sesiones. Un modelo barato que silenciosamente se promociona a uno caro estalla tu modelo de costos. Uno caro que se degrada a uno barato silenciosamente degrada la calidad. La identidad del modelo tiene que ser una propiedad estable de una sesión, y esta versión la hace estable.

[ALLOY]: También hay una corrección donde Edit y Write se rehusaban con un error de aislamiento de worktree justo después de que una sesión se detachara. Ese es el tipo de cosa que hace que el trabajo en segundo plano se sienta poco confiable: desadjuntas una sesión esperando que siga trabajando, y lo primero que intenta hacer falla por una carrera del guard de aislamiento. Eliminar eso hace que el ciclo de vida detach-ejecuta-reanuda-wake sea algo en lo que realmente puedes construir.

[NOVA]: Seamos precisos sobre ese ciclo de vida, porque es el corazón de esta versión para un constructor. Una sesión en segundo plano se crea, luego se desadjunta de la terminal, puede ser retirada cuando está inactiva, despertada cuando se necesita, y recreada si se detiene. Cada una de esas transiciones es un lugar donde el estado puede perderse o corromperse. Esta versión endurece varias de ellas a la vez, por eso merece la lectura completa.

[ALLOY]: Y el caso de uso de constructor que depende de ese ciclo de vida es el que todos quieren: iniciar una tarea de agente larga, irse, dejarla correr, volver y reanudarla sin perder el hilo. Antes de esta versión ese patrón era lo suficientemente frágil que muchos equipos lo evitaban y mantenían las sesiones adjuntas. Después de ella, el trabajo de larga duración detached es algo en lo que realmente puedes diseñar.

[NOVA]: La cuarta área es la higiene de llamadas a herramientas, y es más importante de lo que suena. Dos cambios destacan. Las vistas de head y tail de un archivo ahora satisfacen la verificación de leer-antes-de-editar. Y los resultados vacíos de herramientas de búsqueda como grep, git grep o git diff ya no se reportan como fallos de herramienta.

[ALLOY]: Desempaqueta el de leer-antes-de-editar. La CLI enforcing an invariant that the agent must read a file before editing it, which prevents blind edits. But if the agent looked at a file using a head or tail view, that previously did not count, so a legitimate edit got blocked. Now those views satisfy the invariant. The guarantee is preserved, but a false block is removed.

[NOVA]: Y la corrección de resultado de búsqueda vacío es una corrección de comportamiento disfrazada de una cosmética. Si un agente ejecuta una búsqueda, obtiene cero coincidencias, y el harness reporta eso como un fallo de herramienta, el agente reacciona a un fallo que no ocurrió. Reintenta, cuestiona, o toma un peor camino, porque "sin coincidencias" es un resultado válido e informativo, no un error. Eliminar el fallo espurio elimina el comportamiento espurio del agente.

[ALLOY]: Ese es un patrón recurrente en esta versión que vale la pena nombrar para constructores. Las señales de fallo falsas no son gratis. Un agente que cree que una operación exitosa falló tomará decisiones para compensar un problema que no existe. Limpiar lo que cuenta como éxito y fallo en el límite de la herramienta directamente limpia el razonamiento del agente, lo que significa menos turnos desperdiciados y menor costo en cada ejecución que despliegas.

[NOVA]: Un cambio más concreto: el selector de modelo ahora es de alcance de sesión, con un default separado para sesiones nuevas. Cambiar el modelo para una tarea ya no silenciosamente lo cambia para todo. Hay una corrección relacionada para usuarios en Bedrock y Vertex que no podían seleccionar una opción Opus de largo contexto desde el selector. El tema es el mismo: la elección de modelo debe ser explícita y local, no un efecto secundario global accidental que te persigue en el siguiente despliegue.

[ALLOY]: Entonces, ¿cuál es la postura de actualización, como lista de verificación real de constructor? Instala 2.1.144, y luego ejercita las superficies cambiadas en lugar de asumirlas. Inicia una sesión en segundo plano, desadjúntala, revívela y reanúdala, y confirma que mantiene su modelo. Apúntala a un servidor MCP que pagina su lista de herramientas y confirma que el conjunto completo es visible. Pasa un tipo de imagen no soportado a través de una herramienta MCP y confirma que la conversación sobrevive.

[NOVA]: Y ejecútalo una vez en una red donde el endpoint de la API es brevemente inalcanzable, y confirma que el inicio ya no se congela. El valor de una versión de mantenimiento es completamente condicional. Solo vale algo si los modos de fallo que elimina son los que tus agentes realmente estaban encontrando. Si ejecutas mucho trabajo desatendido en segundo plano, varios de estos casi certamente te estaban afectando, y la respuesta correcta es redesplegar y volver a probar esos caminos exactos, no asumir que la actualización es invisible.

[ALLOY]: Antes de dejar la versión, un grupo más que merece la atención de un constructor: comportamiento de respawn y wake. Una sesión en segundo plano detenida que recreabas podía reportarse como detenida incluso después de que estuviera corriendo de nuevo, y abrir una sesión desde la lista de agentes podía colgarse si el servicio en segundo plano no respondía. Ambos están corregidos. Si construyes cualquier tipo de supervisor que rearranque agentes, probablemente estabas precisamente paliando estos con reintentos y timeouts.

[NOVA]: Ese es el patrón que vale la pena nombrar. Muchos equipos construyen un proceso de niñera alrededor de agentes desatendidos: observa si está detenido, rearranca, verifica de nuevo, alerta si no vuelve. Cada uno de esos pasos depende de que el runtime reporte el estado honestamente. Cuando respawn dice detenido mientras el proceso realmente está corriendo, tu supervisor o hace double-spawn o se rinde. El reporte honesto de estado es lo que hace que un supervisor que despliegas sea realmente seguro.

[ALLOY]: Y hay una corrección de observabilidad más tranquila aquí: las sesiones en segundo plano completadas o detenidas que no lograban activarse brevemente se marcaban permanentemente como un fallo de arranque. Eso es un falso positivo que envenena tu señal operativa. Si alertabas sobre fallos de arranque, recibías notificaciones por sesiones que estaban bien. Eliminar eso hace que la señal de fallo signifique lo que piensas, que es el punto completo de tener la señal.

[NOVA]: Así que el resumen del operador para 2.1.144 es que hace que el ciclo de vida desatendido sea honesto. Generar, desconectar, jubilar, despertar, regenerar y reanudar ahora reportan un estado en el que puedes construir un supervisor, hablar con MCP sin truncamiento silencioso, y arrancar sin detenerse en una red mala. Esa es exactamente la superficie de la que dependes cuando despliegas agentes que funcionan sin supervisión humana.

[ALLOY]: Ese es el bloque de lanzamiento. Una versión de punto, pero densa, concentrada exactamente en la superficie de agente desatendido que los constructores envían a producción. Ahora a un tipo diferente de cambio: no el runtime, sino el modelo dentro de él. ...

[NOVA]: Cursor Composer 2.5 aterrizó el 18 de mayo. Es un modelo de agente de codificación construido sobre una base Kimi K2.5, con post-entrenamiento más pesado, enfocado específicamente en sesiones de codificación autónomas más largas. Empecemos con los números que reporta Cursor, luego veamos cómo fue entrenado, porque el método de entrenamiento es la parte más interesante para un constructor que decide qué enviar a producción.

[ALLOY]: Los benchmarks reportados: SWE-Bench Multilingüe subiendo de 73.7 a 79.8 por ciento, Terminal-Bench de 61.7 a 69.3 por ciento. En Terminal-Bench 2.0 empata con Opus 4.7 y queda detrás de GPT-5.5. El precio estándar es cincuenta centavos por millón de tokens de entrada y dos dólares cincuenta por millón de tokens de salida. El titular es ese precio: aproximadamente una décima parte de Opus 4.7 por token, con rendimiento de benchmarks de codificación comparable.

[NOVA]: Los benchmarks primero, con la cautela habitual. SWE-Bench y Terminal-Bench son señales reales, pero son suites saturadas donde los modelos frontier se agrupan dentro de unos pocos puntos, y las diferencias en los harness pueden dominar la brecha del modelo en tipos de tareas específicas. Trata los números como "esto está en la conversación", no "esto está decidido". Volveremos a lo que un constructor debería medir en realidad.

[ALLOY]: El entrenamiento es donde hay algo que realmente explicar. Cursor reporta tres cambios. Primero, aprendizaje por refuerzo con retroalimentación textual. En lugar de solo una recompensa al final de la ejecución, el modelo recibe pistas localizadas en el punto de una llamada de herramienta fallida.

[NOVA]: Eso es un cambio de asignación de crédito, y importa específicamente para agentes de horizonte largo. Imagina una sesión de codificación con cincuenta llamadas a herramientas. Si la única señal es pasar o fallar al final, el modelo tiene casi ninguna información sobre cuál llamada fue el error. La recompensa se extiende por toda la trayectoria. La retroalimentación textual localizada en la llamada fallida da una señal nítida apuntando al comportamiento exacto que salió mal.

[ALLOY]: La asignación de crédito es el problema central difícil en entrenar agentes que toman secuencias largas de acciones. Cuanto más largo el horizonte, más débil se vuelve una sola recompensa terminal, porque hay más acciones compartiendo la culpa por un resultado. Acercar la retroalimentación a la acción que causó el fallo es una de las pocas cosas que ayudan de manera confiable, y es exactamente el régimen en el que opera un agente de codificación autónomo cuando lo despliegas en trabajo real.

[NOVA]: Segundo cambio: veinticinco veces más tareas sintéticas, incluyendo puzzles de reconstrucción tras eliminación de características. Ese es un objetivo inteligente. Tomas código funcional, eliminas una característica, y le pides al modelo que la reconstruya. La verdad fundamental es exacta, la dificultad es ajustable, y fuerza al modelo a razonar sobre cómo se integra un codebase en lugar de hacer pattern-matching de un fragmento.

[ALLOY]: La generación de tareas sintéticas es cómo logras suficiente volumen y cobertura de dificultad para entrenar un agente de codificación sin estar bottlenecked por tareas del mundo real escasas con señales de recompensa limpias. El encuadre del puzzle de reconstrucción es bueno porque tiene una verificación de corrección inequívoca, que es exactamente lo que necesita el aprendizaje por refuerzo para evitar el hacking de recompensas. Una recompensa vaga se presta para hacer trampa; una recompensa de reconstruir-exacto no.

[NOVA]: Tercer cambio: infraestructura de entrenamiento a escala MoE. Cursor cita optimizadores Muon fragmentados y HSDP de malla dual. El detalle debajo de eso es que el entrenamiento de mezcla de expertos a escala necesita que el estado del optimizador y el layout de paralelismo estén fragmentados cuidadosamente, o los costos de memoria y comunicación dominan. Eso es trabajo de infraestructura, pero es lo que hace que la economía del entrenamiento del resto sea factible.

[ALLOY]: Y el cuarto detalle, que creo que los constructores no deben skipear, es que el aprendizaje por refuerzo se ejecutó dentro de sesiones reales de Cursor usando el mismo harness que usa el modelo desplegado. Entrenamiento fiel al harness.

[NOVA]: Explica por qué eso es load-bearing para cualquiera que envía agentes. El comportamiento de un agente de codificación se moldea tanto por su harness como por sus pesos. Cómo se presentan las herramientas al modelo, cómo vuelven los errores, cómo se recorta el contexto, cómo se manejan los reintentos, cómo se estructura el loop. Si entrenas el modelo en un harness y lo envías en otro diferente, introduces un shift de distribución. El síntoma es un modelo que funciona bien en benchmarks pero se siente peor en producción de lo que prometían los números.

[ALLOY]: Ejecutar el aprendizaje por refuerzo dentro del harness desplegado cierra esa brecha. El modelo aprende la interfaz real a la que se enfrentará, no un substitute de entrenamiento idealizado. Para cualquiera que haya enviado un agente y lo haya visto underperformar sus evaluaciones, eso es un ataque directo a un fallo de constructor muy común.

[NOVA]: Lo que nos lleva a la conclusión, y es principalmente sobre economía y cómo cambia lo que despliegas por defecto. Cuando un modelo alcanza rendimiento de codificación cercano al frontier a aproximadamente una décima parte del costo por token, la matemática de ejecutar muchas sesiones autónomas largas cambia. Trabajo que solo justificaba un modelo caro para unas pocas tareas de alto valor puede convertirse en el valor por defecto para trabajo rutinario de agentes.

[ALLOY]: Pero, y esta es la cautela importante, paridad de benchmark no es paridad de workflow. Terminal-Bench y SWE-Bench miden algo real, pero no miden tu distribución de tareas, tus herramientas, tus tamaños de contexto, o cómo se comporta un modelo en una sesión genuinamente larga en tu harness. El movimiento correcto es una comparación controlada en tu propio trabajo real, no un swap de tabla de benchmarks.

[NOVA]: Concretamente, aquí está el patrón de constructor para evaluarlo. Toma una muestra representativa de las tareas de codificación de horizonte largo que tus agentes realmente ejecutan en producción. Ejecútalas a través de tu modelo existente y a través de Composer 2.5 en tu propio harness, no el del vendedor. Compara no solo la tasa de éxito sino el costo por tarea completada, el número de llamadas a herramientas, el comportamiento de recuperación en fallo, y cómo se degrada la calidad a medida que la sesión se alarga.

[ALLOY]: Ese último punto, la degradación en sesiones largas, es el caso de uso que los benchmarks sistemáticamente sub-testan. La mayoría de las tareas de benchmark son cortas relativas a una ejecución real de agente. Si despliegas agentes que trabajan durante una hora, te importa menos una tasa de éxito de un solo disparo y más si el modelo sigue siendo coherente en la llamada de herramienta número doscientos. Construye eso en la comparación deliberadamente.

[NOVA]: La ventaja de costo es lo suficientemente real como para que si se sostiene en tu distribución, cambia tu modelo por defecto para trabajo rutinario de agentes. Si no lo hace, has aprendido algo específico sobre tu propia carga de trabajo en lugar de confiar en una tabla. Cualquier resultado es útil; el movimiento incorrecto es hacer swap basado en el titular y descubrir la brecha en producción.

[NOVA]: Vamos a ir un nivel más profundo en el cálculo de costos, porque ahí es donde esto se vuelve relevante para tomar decisiones. Un décimo del precio por token no significa un décimo del costo de una tarea. Los agentes no tienen un consumo fijo de tokens; un modelo más débil puede hacer más llamadas a herramientas, más reintentos y usar más tokens para completar el mismo trabajo, o fallar y obligar a un retroceso a un modelo caro. Así que la métrica que importa para un constructor es el costo total por tarea completada, incluyendo los fallos que retroceden, no el precio de lista por millón de tokens.

[ALLOY]: Eso replantea la evaluación. Si Composer 2.5 completa tus tareas en un número comparable de turnos respecto a tu modelo actual, la ventaja de precio fluye casi directamente a tu factura, y eso es un cambio grande para cualquiera que ejecute agentes a escala. Si toma significativamente más turnos o falla más seguido y retrocede, la brecha efectiva se reduce. No puedes saber cuál es sin ejecutar tu propia distribución, y por eso la tabla de benchmarks es el inicio de la pregunta, no la respuesta.

[NOVA]: También hay un patrón de despliegue que esto habilita y que vale la pena mencionar: enrutamiento por niveles. Usa el modelo más barato como predeterminado para trabajo rutinario de agentes, y escala a un modelo de frontera solo cuando el más barato falla una verificación o alcanza un umbral de confianza. Un modelo que está al nivel de frontera a un décimo del costo es un muy buen nivel predeterminado, porque los casos en que no es lo suficientemente bueno son exactamente los casos para los que está tu ruta de escalamiento.

[ALLOY]: Y el detalle de infraestructura debajo del entrenamiento, el optimizador Muon fragmentado y el HSDP de malla dual, es relevante para los constructores solo indirectamente, pero es la indirección relevante: es la razón por la que este punto de precio es posible a esta calidad. El entrenamiento eficiente de mezcla de expertos es lo que permite a un laboratorio publicar números al nivel de frontera a una fracción del costo de servicio. La economía que se te ofrece es derivada de ese trabajo de infraestructura, por eso el precio no es un líder de pérdidas temporal que deberías asumir que desaparecerá.

[ALLOY]: Y ten en cuenta el punto sobre la fidelidad del harness cuando leas los benchmarks de cualquier modelo, no solo de este. Un número producido en el harness del laboratorio es un límite superior de lo que verás en el tuyo, a menos que tu harness coincida con el de ellos. La brecha entre esos dos es donde realmente viven la mayoría de las historias de "el modelo empeoró cuando lo desplegamos". Trata tu propio harness como parte del modelo. ...

[NOVA]: La tercera historia es la adquisición de Stainless por Anthropic, anunciada el 18 de mayo. Stainless es una empresa de herramientas para desarrolladores cuyo servicio convierte una especificación de API en SDKs listos para producción y mantenidos automáticamente en Python, TypeScript, Go, Kotlin y Java. Era utilizada por una larga lista de laboratorios de IA y empresas de infraestructura. Anthropic planea discontinuar los productos Stainless alojados, incluyendo el generador de SDKs. Los clientes existentes conservan los SDKs ya generados, pero pierden el acceso futuro al servicio alojado.

[ALLOY]: En la superficie parece un titular de adquisición. La razón por la que es una historia de stack de agentes es lo que un SDK realmente es dentro de un sistema de agentes. Explica eso en detalle, porque es fácil pasarlo por alto.

[NOVA]: Un SDK es el límite tipado que un agente cruza cada vez que llama a una API externa. Cuando un agente invoca una herramienta que envuelve un servicio, la corrección de esa llamada depende enteramente de que el cliente coincida con la API en vivo. Los endpoints correctos. Las formas correctas de solicitud y respuesta. Los tipos de error correctos. El comportamiento correcto de paginación y reintento. El SDK no es una capa de conveniencia sobre la API. Para un agente, es el contrato.

[ALLOY]: Así que un pipeline que convierte una especificación en ese cliente, y lo mantiene sincronizado mientras la especificación cambia, es infraestructura que está directamente debajo de la capa de herramientas del agente. No es una preocupación secundaria. Para cualquiera que construye agentes que tocan servicios externos, es una pieza que soporta carga.

[NOVA]: Y eso apunta al modo de fallo que vale la pena entender: la deriva de spec a SDK. Supón que la especificación de la API cambia, pero el cliente generado no se actualiza. Ahora tienes un cliente que compila, parece correcto, y silenciosamente no coincide con la API en vivo. Un campo se movió. Un enum ganó un valor. Un endpoint cambió su paginación.

[ALLOY]: Para un desarrollador humano eso aparece como un reporte de bug y alguien investiga. Para un agente autónomo aparece como una llamada a herramienta que devuelve algo que el agente no esperaba. Y el agente no se detiene ahí. Razona alrededor del resultado inesperado, a menudo incorrectamente, y el error se propaga a lo que sea que el agente haga después. Un cliente desactualizado no se anuncia a sí mismo. Simplemente hace que el agente esté silenciosamente equivocado, que es el tipo de error más caro de depurar después de que has enviado a producción.

[NOVA]: Ese es exactamente el problema que la generación automatizada de SDKs basada en especificaciones existe para resolver: mantener el límite tipado honesto a través de muchos lenguajes sin mantener manualmente cada cliente. Los clientes escritos a mano en múltiples lenguajes se desactualizan porque los humanos no pueden mantener cinco SDKs en diferentes lenguajes perfectamente sincronizados con una especificación en movimiento. La generación desde la especificación es cómo haces que el límite sea lo suficientemente confiable para desplegar un agente encima de él.

[ALLOY]: Así que para los equipos que dependían del generador alojado, la pregunta práctica es qué lo reemplaza. Hay tres opciones generales, cada una con sus propios compromisos, y elegir es en sí mismo una decisión de constructor. Una: generadores OpenAPI de código abierto. Mantienes la generación basada en especificaciones, pero tú posees la cadena de herramientas y su fidelidad de tipos varía. Dos: SDKs publicados por el proveedor. Menos mantenimiento, pero dependes del ritmo de lanzamiento del proveedor y su cobertura de lenguajes.

[NOVA]: Tres, y esta es la más relevante para los constructores de agentes: envuelve la API detrás de una capa de herramientas, como un servidor MCP, para que el agente hable con un contrato interno estable en lugar de un cliente regenerado. Eso mueve el problema de la deriva a un lugar controlado que tú operas. El agente ve una interfaz de herramienta estable; el servidor MCP absorbe los cambios en la API subyacente. Es más trabajo levantar, pero te da una sola costura que gestionar en lugar de deriva dispersa en cada cliente que usan tus agentes.

[ALLOY]: Cada opción sacrifica fidelidad de tipos, carga de mantenimiento y qué tan rápido los cambios de especificación se propagan al agente. No hay una elección gratuita aquí, pero hay una mala, que es no decidir y dejar que un cliente generado sin mantenimiento se desvíe lentamente mientras los agentes siguen desplegándose encima de él.

[NOVA]: También hay un punto más amplio, más allá de la migración de un solo equipo. Esto es concentración de suministro. Cuando un laboratorio de modelos posee una dependencia de generación de código en la que los laboratorios competidores y los proveedores de infraestructura estaban construyendo, eso es un solo punto de riesgo estratégico y técnico sentado debajo de muchos clientes de herramientas de agentes en toda la industria.

[ALLOY]: Vale la pena saber, concretamente, de dónde viene tu generación de cliente de herramientas, quién la controla y cuál es tu plan de respaldo si ese control cambia. Eso solía ser un detalle de integración que podías ignorar. Para sistemas de agentes, donde el SDK es el límite de la herramienta, es una decisión de arquitectura con un perfil de riesgo, y pertenece en la misma revisión que cualquier otra dependencia crítica que despliegues.

[NOVA]: El patrón de constructor que surge de esto es tratar la ruta de especificación a cliente como infraestructura monitoreada. Fija la versión de especificación de la que se generaron tus clientes. Compara la especificación en vivo contra ella en un horario. Trata una deriva como una alerta, no como un descubrimiento que haces cuando un agente empieza a comportarse de manera extraña en producción. Eso convierte un modo de fallo silencioso en uno visible que puedes actuar antes de que se envíe.

[ALLOY]: El resumen es que esto es pequeño en superficie y grande en implicación. Traer la generación de SDKs internally es un movimiento sólido para el adquirente. Para todos los que construyen agentes encima de estas APIs, es una invitación a tratar la deriva de spec a cliente como un modo de fallo de agente de primera clase, a conocer tu plan de respaldo antes de que lo necesites, y a cablear la detección de deriva en cómo operas. ...

[ALLOY]: Notion lanzó su Plataforma de Desarrolladores el 13 de mayo, y el encuadre que importa para los constructores es el cambio de un espacio de trabajo que los agentes leen a un espacio de trabajo en el que los agentes operan. Hay cinco piezas concretas. Workers, un sandbox de código alojado sin servidores que provisionar. Una API de Agentes Externos. Sincronización de bases de datos. Webhooks bidireccionales. Y una herramienta de línea de comandos para autenticación, despliegue y automatización.

[NOVA]: Empecemos con los Workers, porque los tiempos de ejecución de código alojado son la idea fundamental. Escribes la lógica, la despliegas en un entorno aislado (sandbox) gestionado, y está en vivo sin infraestructura que operar. Para un desarrollador de agentes, ese es un lugar para poner las partes deterministas de un flujo de trabajo junto a los datos sobre los que actúan, en lugar de configurar y supervisar tu propio servicio para cada integración.

[ALLOY]: Y la pieza que se combina con eso son las herramientas de Worker deterministas. En lugar de una llamada a herramienta mediada por LLM, un agente personalizado invoca un Worker que ejecuta código predecible con una ejecución eficiente en tokens. Esa distinción es la útil para asimilar. Una llamada a herramienta mediada por un modelo es flexible pero probabilística. Una herramienta Worker es determinista. El patrón de construcción es usar el modelo para el juicio y un Worker para los pasos que deben ser exactos cada vez.

[NOVA]: La API de Agente Externo es la superficie multivendedor. Permite que agentes de terceros, los nombrados siendo Claude Code, Cursor y Codex, operen como participantes de primera clase en el espacio de trabajo en lugar de integraciones añadidas. Para un desarrollador, eso significa que no estás forzado a usar el agente de un solo proveedor para obtener un comportamiento nativo del espacio de trabajo; puedes traer el agente que ya despliegas.

[ALLOY]: La sincronización de bases de datos y los webhooks bidireccionales cierran el ciclo. La sincronización mantiene un sistema de registro externo actualizado dentro del espacio de trabajo sin infraestructura que gestionar. Los webhooks permiten que cualquier aplicación active un Worker, que ejecuta lógica y actúa de vuelta en el espacio de trabajo o llama a otras APIs. Eso es un activador de agente basado en eventos, que suele ser lo que realmente quieres en producción en lugar del sondeo.

[NOVA]: El compromiso a considerar, y es el importante, es el límite de confianza. Ejecutar agentes de terceros y código personalizado dentro de un espacio de trabajo que contiene datos reales de la empresa significa que el modelo de gobernanza está haciendo un trabajo fundamental. La respuesta de Notion es confianza progresiva, revisión humana opcional, ejecución en entorno aislado (sandbox) y visibilidad unificada en toda la actividad del agente. Un desarrollador debe tratar ese límite como algo a diseñar deliberadamente, no como un valor predeterminado a heredar, porque el radio de impacto de un agente con mal comportamiento aquí son los datos operativos reales de tu empresa.

[ALLOY]: Así que la conclusión para el desarrollador es que este es un tiempo de ejecución de agente real, no una superficie de plugin. Usa Workers deterministas para los pasos exactos, la API de Agente Externo para mantener tu agente existente, webhooks de eventos para activar el trabajo, y piensa detenidamente en el límite de confianza antes de desplegar cualquier cosa que pueda escribir. ...

[NOVA]: El Vercel AI SDK reescribió su adaptador de LangChain y LangGraph, y la razón por la que esto es más que una nota de paquete es que casi nadie ejecuta un solo framework de principio a fin. Prototipas en una pila y despliegas en otra, y el punto donde falla es la interoperabilidad del formato de mensajes y el formato de stream. El código de conexión escrito a mano entre frameworks es exactamente donde las pilas mixtas se deterioran.

[ALLOY]: El nuevo adaptador es específico al respecto. Hay una función para convertir objetos de mensaje del AI SDK al formato de mensaje base de LangChain, y otra para mensajes que ya has pasado por la conversión de mensaje del modelo. Hay una función que transforma los streams del modelo de LangChain, la salida de LangGraph y los resultados de eventos de stream granulares en el stream de mensajes de UI del AI SDK. Y hay un transporte que conecta un cliente de navegador directamente a un despliegue de LangSmith o LangGraph.

[NOVA]: Hablemos primero de la normalización del stream, porque el streaming es donde la interoperabilidad suele fallar silenciosamente. Un agente construido sobre un framework emite eventos con su propia forma. Una UI construida sobre otro framework espera una forma diferente. Si el puente tiene pérdidas, pierdes los límites de las llamadas a herramientas, los pasos intermedios o las actualizaciones a nivel de token, y la UI se degrada a un indicador de carga. Normalizar la salida de LangGraph y los eventos de stream granulares en un único formato de stream para la UI significa que el frontend puede renderizar un agente que no creó sin una capa de traducción personalizada.

[ALLOY]: La pieza de transporte es la otra reducción real en partes móviles. Un transporte de chat que se comunica directamente desde el navegador a un grafo desplegado elimina la ruta de backend personalizada que los equipos suelen escribir solo para hacer de proxy entre una UI y un despliegue de LangGraph. Menos saltos, menos código de conexión a medida, una cosa menos que operar.

[NOVA]: La perspectiva del desarrollador aquí es la interoperabilidad como infraestructura, no como conveniencia. Si construyes agentes en una pila mixta, el adaptador entre frameworks no es un extra. Es la costura que decide si tu pila se mantiene coherente o se fragmenta en conectores únicos que se deterioran cada uno a su propio ritmo. Un puente mantenido y tipado con un manejo adecuado de streams y eventos es lo que te permite elegir el mejor framework por capa en lugar de estar encerrado en uno.

[ALLOY]: Y el ángulo de la observabilidad vale la pena mencionarlo. Los eventos de stream granulares que fluyen limpiamente significan que puedes ver los pasos intermedios de un agente construido sobre otro framework en tu propia UI y herramientas. Para depurar ejecuciones largas de agentes, esa visibilidad a menudo es la diferencia entre un problema solucionable y una caja negra. ...

[ALLOY]: La última historia es Cloudflare Mesh, parte del impulso de Cloudflare en la nube de agentes, que aplica redes privadas de confianza cero e identidad a cómo los agentes acceden a los servicios y entre sí. También hay cambios en las herramientas de desarrollo con fecha, como la eliminación el 18 de mayo del flag obsoleto de desarrollo remoto para objetos durables respaldados por clave-valor, que es el tipo de pequeño cambio de paridad que silenciosamente decide si un agente se comporta igual en desarrollo y producción.

[NOVA]: El enfoque para los desarrolladores es el cambio en dónde se ejecutan los agentes. Cuando un agente era un solo proceso en una laptop, la red era un detalle de implementación. Cuando son muchos workers en entornos aislados (sandboxed) que llaman a servicios internos y externos, la red entre ellos se convierte en una superficie de ataque y un límite de políticas al mismo tiempo. Ese es el problema para el que se construye una malla con identidad.

[ALLOY]: El principio concreto es la identidad por agente con credenciales con ámbito en lugar de claves ambientales compartidas. Si cada agente comparte una clave amplia, un solo agente comprometido o con mal comportamiento tiene el radio de impacto de toda la clave. Si cada agente tiene su propia identidad con permisos con ámbito, la política de red puede vincularse a esa identidad, y puedes comprender exactamente a qué tiene permitido acceder un agente.

[NOVA]: Y esa política tiene que seguir el ciclo de vida. Un agente nace, actúa y se retira. Si las credenciales y el alcance de la red se otorgan ampliamente al nacer y nunca se limita su ámbito, un agente de larga ejecución o desvinculado acumula acceso que no necesita. Vincular la política a la identidad a lo largo del camino de nacimiento-acción-retiro es cómo mantienes el alcance de red de un agente alineado con lo que realmente está haciendo en ese momento.

[ALLOY]: El detalle de la paridad en desarrollo de los objetos durables es menor, pero sigue el mismo tema. El comportamiento local versus remoto para los workers con estado tiene que coincidir, o obtendrás un agente que funciona en desarrollo y falla en producción por razones que no tienen nada que ver con su lógica. La paridad en la capa de estado y de red es parte de hacer que el comportamiento del agente sea reproducible.

[NOVA]: La recomendación para el desarrollador es directa. Trata la red del agente como algo que diseñas con identidad y política con ámbito, no como algo que los agentes heredan con un acceso ambiental amplio. A medida que pasas de un proceso local a una flota de workers en entornos aislados (sandboxed), la política de red es parte de la postura de seguridad del agente, no una infraestructura que puedes aplazar. ...

[ALLOY]: Aterricemos esto en lo que realmente hay que hacer. Seis movimientos, seis prioridades concretas para el desarrollador.

[NOVA]: Para Claude Code, instala la versión 2.1.144 y valida directamente las superficies cambiadas en lugar de darlas por sentadas. Desvincula, activa, reinicia y reanuda una sesión en segundo plano y confirma que mantiene el modelo correcto. Apúntalo a un servidor MCP que pagine su lista de herramientas y confirma que el conjunto completo es visible. Introduce un tipo de imagen no compatible a través de una herramienta MCP. Ejecútalo en una red degradada y confirma que el inicio ya no se bloquea. Una versión de mantenimiento solo vale la pena si verificas que las fallas eliminadas eran las que afectaban a los agentes que despliegas.

[ALLOY]: Para la selección de modelos, trata a Composer 2.5 como un candidato para evaluar dentro de tu propio harness, en tus propias tareas de sesiones prolongadas, no como un drop-in. Compara el costo total por tarea completada y la degradación en sesiones prolongadas, no solo las tasas de aprobación generales, y considera un patrón de enrutamiento de默认值 económica con escalamiento a frontera si funciona bien en tu distribución.

[NOVA]: Para clientes de herramientas, audita de dónde proviene tu SDK o generación de cliente. Si dependías de un generador alojado que está cerrando, decide ahora entre generadores de OpenAPI, SDKs de proveedores, o envolver la API detrás de un contrato interno estable como un servidor MCP, y fija y compara el spec para que la desviación sea una alerta, no una sorpresa en producción.

[ALLOY]: Para agentes de workspace, trata la API de Agente Externo de Notion como una superficie multivendedor para que conserves el agente que ya tienes implementado, usa Workers determinísticos para pasos que deben ser exactos, y diseña el límite de confianza antes de permitir que algo escriba.

[NOVA]: Para stacks mixtos, usa el adaptador reescrito de Vercel para conectar LangGraph y el AI SDK con manejo adecuado de streams y eventos en lugar de crear conectores personalizados que se vuelven obsoletos. Y para redes de agentes, adjunta identidad por agente y política limitada al ciclo de vida spawn-act-retire en lugar de depender de acceso ambiente amplio.

[ALLOY]: El hilo conductor en los seis es el mismo tipo de madurez operativa. El runtime está endureciendo la superficie de sesiones desatendidas que los builders implementan. La capa de modelos está haciendo que la codificación cercana a la frontera sea lo suficientemente económica como para cambiar los valores por defecto. Y las capas de herramientas, workspace, interoperabilidad y red están todas consolidándose, lo que hace que los límites entre un agente y todo lo que toca sean cosas que tienes que poseer deliberadamente en lugar de heredar.

[NOVA]: Ese es el trabajo que hace que los agentes sean más fáciles de lanzar, depurar y confiar. Menos espectáculo, más confiabilidad. Eso suele ser donde está el progreso real, y es lo que realmente cambia cómo construyes.

[ALLOY]: Los enlaces de fuentes y las notas del episodio están disponibles en Toby On Fitness Tech punto com.

[NOVA]: Eso es AgentStack Daily. Soy NOVA.

[ALLOY]: Y yo soy ALLOY. Volveremos pronto.