La portabilidad de los tool calls es una mentira. He pasado la semana probando por qué un agente que funciona perfecto en Claude se rompe de forma catastrófica al pasarlo a un modelo abierto.
Esta edición te llevas la auditoría técnica de los 4 fallos sistémicos que encontré en LiteLLM, Qwen y Llama 4, y cómo evitar que tus agentes entren en bucles infinitos.
Entremos en el postmortem.
La portabilidad de tool calls entre modelos de IA no funciona en la práctica
He auditado function calling en LiteLLM, Qwen 3.6, Gemma 4 y Llama 4. Encontré 4 bugs sistémicos que rompen agentes al cambiar de proveedor: parsing incorrecto, bucles infinitos por mismatch de roles, y validación de schemas rechazada antes de llegar al modelo. Esto no es un problema de modelos — es un problema de capas de abstracción que intentan unificar protocolos incompatibles.
LiteLLM tiene 48.000 estrellas en GitHub. Es el gateway estándar de facto para llamar a más de 100 LLMs desde un único código de agente. Si tu agente funciona con LiteLLM, debería funcionar con Claude, GPT, Qwen, Gemma o cualquier modelo local.
Teóricamente. En la práctica, la capa de traducción de tool calls es donde todo se rompe.
Pasé la semana auditando function calling en modelos abiertos. El resultado no es un bug aislado. Es un desgaste de interoperabilidad sistemático. Cada modelo tiene su propia convención de roles, cada proveedor cloud su propia validación de schemas, y cada capa de abstracción introduce sus propios bugs de traducción.
Empecé por Qwen 3.6:35b-a3b, que debería ser uno de los mejores modelos abiertos en tool calling. Ollama devuelve tool_calls correctamente (verificado con curl directo). Pero LiteLLM los parsea como None y devuelve el texto en content. El modelo llamó a la función. Tu código no lo sabe. Issue #24091 abierto desde marzo, sin fix.
Luego fue Gemma 4. Este modelo entra en bucle infinito de tool calls. Llama a la misma herramienta una y otra vez, ignorando el resultado. La causa raíz es elegante en su simplicidad: Gemma 4 espera el rol tool_responses para los mensajes de resultado. LiteLLM estandariza todo a tool (formato OpenAI). El modelo no reconoce el resultado como válido y repite la llamada.
El fix es una línea:
tool_role = "tool_responses" if "gemma4" in model.lower() else "tool"Google ADK ya lo implementó en su integración con LiteLLM (PR #5655). LiteLLM tiene un PR equivalente (#28533) bloqueado por revisión.
El mismo problema fue reportado de forma independiente por Google ADK (#5650). No es un bug de una sola librería. Es una incompatibilidad de protocolo entre el estándar OpenAI y el chat template de Gemma 4.
Y luego está Bedrock. Llama 4 Maverick en AWS rechaza las definiciones de herramientas antes de que el modelo genere cualquier output. Bedrock fuerza JSON Schema draft 2020-12 estricto, y el formato que LiteLLM envía para tool calls compatibles con OpenAI no pasa la validación. Curiosamente, los modelos Nova de Amazon aceptan las mismas definiciones sin problema. El fallo es específico de Llama 4.
Incluso cuando el modelo es capaz de hacer tool calling, la infraestructura de routing puede rechazar las definiciones antes de llegar al modelo.
Mi lectura: la portabilidad real de tool calls entre modelos baratos y frontier sigue siendo un problema no resuelto a nivel de infraestructura. No es un problema de modelos. Es un problema de capas de abstracción que intentan unificar protocolos incompatibles.
Cómo evitar que tus agentes se rompan al cambiar de modelo
La solución no es esperar a que LiteLLM, Bedrock o cada proveedor arreglen todos los casos borde. Si vas a usar modelos abiertos con herramientas, asume que la portabilidad no existe por defecto.
Mi checklist mínimo ahora es este:
Testea tool calling por proveedor, no solo por modelo.
Qwen en Ollama, Qwen vía LiteLLM y Qwen servido por otro proveedor no son el mismo sistema. El modelo puede saber llamar a una herramienta, pero la capa intermedia puede parsear mal la respuesta.Guarda siempre el raw response del modelo.
No confíes únicamente enmessage.tool_calls. Si el parser falla, el tool call puede estar encontenty tu agente lo tratará como texto normal.Mantén adaptadores por familia de modelo.
“Compatible con OpenAI” no significa compatible en la práctica. Gemma, Qwen, Llama y Claude tienen convenciones distintas para roles, schemas y mensajes de resultado.Añade un detector de bucles de herramientas.
Si el modelo llama tres veces seguidas a la misma tool con los mismos argumentos, corta la ejecución. No lo dejes quemar tokens indefinidamente.Valida los schemas contra el proveedor final.
Que una definición funcione en OpenAI no significa que Bedrock, Vertex o un runtime local la acepten. El schema debe probarse donde realmente va a ejecutarse.
La abstracción útil no es “una API universal para todos los modelos”. Es una capa propia de compatibilidad que sepa cuándo cada modelo deja de comportarse como OpenAI.
Build Log — (22–29 Mayo 2026)
TusPorras (Web/App Store / Play Console)
Centrados en los últimos detalles de desarrollo para TusPorras, como mail marketing, últimas optimizaciones SEO y ASO, y capatación de usuario a través de LinkBuilding. La porra del Mundial 2026 está a la vuelta de la esquina.
Herramienta de la semana: Semble
Semble — Librería de code search optimizada para agentes IA.
La utilizo para que mis agentes indexen repositorios locales en milisegundos sin disparar la latencia ni el coste de tokens. En lugar de usar el clásico combo grep + read (que consume una barbaridad), Semble actúa como un servidor MCP que permite al agente buscar código relevante de forma semántica y léxica de forma casi instantánea.
Lo uso a diario. Es increíblemente rápido (indexación en ~250ms) y no requiere GPU ni APIs externas. El único "pero" es que, al depender de embeddings locales, requiere una configuración inicial limpia en tu entorno para que no muerda el rendimiento de tu CPU.
Es ideal para developers que trabajan con agentes locales; si solo usas el chat de Claude en la web, no te aporta nada.
Una cosa
Si has perdido tiempo debuggeando un agente que funciona en un modelo y no en otro, probablemente sea el mismo problema: la capa de abstracción, no el modelo.
Respóndeme a este email con un solo modelo que te haya dado problemas de tool calling esta semana. Me interesa saber dónde más está rompiéndose.
P.D. — Si conoces a alguien que construye agentes con modelos abiertos, pásale esta edición. Le vas a ahorrar horas de debugging.