Breaking changes en agentes IA: qué revisar antes de actualizar

Hay una diferencia grande entre un agente que funciona y un agente que sigue funcionando en tres meses. Dos releases de esta semana lo dejan claro, y lo interesante es que ninguno falla por tu código. Fallan por lo que hay debajo de tu código.

El modelo por defecto cambió, y tu agente no te va a avisar

El SDK openai-agents-python llegó a la versión 0.20.0 y su modelo por defecto ahora es gpt-5.6-luna. Las notas aclaran que los modelos explícitos, los overrides a nivel de ejecución y la variable OPENAI_DEFAULT_MODEL siguen mandando por encima.

Léelo de nuevo, porque es más grave de lo que parece. Si tienes un agente en producción que nunca declaró su modelo, el día que actualices el SDK ese agente empieza a pensar con otro. No hay error, no hay warning, no hay línea que cambiar. Cambian los costos, cambia la latencia, y cambia el comportamiento en el borde que te costó semanas afinar.

Un default no es una comodidad. Es una decisión que alguien más va a tomar por ti, más adelante, sin consultarte.

El que te rompe no está en tu requirements

La misma release trae el caso de manual. Ahora soporta el SDK de MCP en Python tanto en v1 como en v2, y ahí viene la letra chica: si tienes autenticación HTTP propia para MCP, o fábricas de clientes, tienes que usar los tipos que corresponden a la versión mayor que tengas instalada. Si no quieres pensar en eso, pineas mcp<2 y te quedas tranquilo.

Fíjate dónde vive ese problema. No está en tu requirements.txt, está dos niveles más abajo, en una dependencia que tú nunca elegiste a mano. Es exactamente el tipo de cosa que revienta un viernes sin que nadie haya tocado el código.

La misma versión suma RunState.add_input(), que te deja inyectar input del usuario de forma durable antes de reanudar una llamada al modelo, y arregla varios casos donde la aprobación de herramientas no se respetaba al retomar una ejecución con contexto. Si tienes flujos con aprobación humana, esos arreglos te importan.

Actualizar el motor te cambia el suelo

Si sirves modelos localmente, vLLM v0.27.0 trae soporte completo para Kimi K3, con kernels y frontends en Python y Rust, y expande Model Runner V2 a cargas que no son de generación: pooling para embeddings y clasificación, BGE-M3, clasificación de tokens. Bueno si armas retrieval o reranking con modelos propios.

Pero el cambio que importa no está en el modelo, está en el entorno. Sube a PyTorch 2.13.0, torchvision 0.28.0 y Triton 3.7.1, y la release lo marca explícitamente como breaking. Los backends de XPU y CPU también suben. Si tienes el ambiente pineado, esto no es un pip install --upgrade de viernes por la tarde.

Las tres reglas

Ninguno de estos cambios es un error de los mantenedores. Los dos proyectos hicieron lo correcto: avisaron. El problema está del otro lado, y es de disciplina, no de herramientas.

Declara el modelo siempre, aunque haya un default. El default es de ellos, no tuyo.

Pinea las versiones, incluidas las transitivas. Lo que te rompe casi nunca está en la primera capa.

Monitorea los changelogs de lo que sostiene tu agente. Enterarte por el incidente es la forma cara de enterarse.

La ingeniería del agente no está solo en el prompt. Está en el arnés que lo sostiene cuando todo lo demás cambia debajo.

Fuentes: openai-agents-python v0.20.0 y vLLM v0.27.0. Verificadas contra las notas originales antes de publicar.