Gemini Flash 3.6, hooks y Liquid AI: el coste real de los encoders en producción

Google acaba de mover ficha en el tablero de los agentes en producción, y la jugada merece más análisis del que le están dando los titulares. La actualización de los Agentes Gestionados en la API de Gemini —con Flash 3.6 y soporte para hooks— no es solo una nota de release: es una declaración de intenciones sobre quién quiere controlar la capa de orquestación en el desarrollo de agentes empresariales.

Flash 3.6 y hooks: lo que realmente importa para ingeniería de producto

El anuncio de Google sobre Managed Agents en la API de Gemini tiene dos patas. La primera, Flash 3.6, es una evolución incremental del modelo que ya conocíamos: más rápido, con mejor latencia para tareas de razonamiento corto. No hay un salto de capacidades disruptivo —a estas alturas del año, Flash es el caballo de batalla de los equipos que necesitan throughput alto a coste razonable, no el modelo de cabecera para razonamiento complejo.

La segunda pata, los hooks, es donde está la chicha estratégica. Los hooks permiten inyectar lógica personalizada en puntos concretos del ciclo de vida del agente: antes de que el modelo llame a una herramienta, después de recibir una respuesta, en puntos de validación. Para cualquier equipo que haya sufrido el infierno de los agentes autónomos en producción —alucinaciones en cadena, llamadas a herramientas incorrectas, bucles infinitos— esto es infraestructura real, no marketing.

A diferencia de lo que sugiere el anuncio oficial, el verdadero reto para los equipos de producto españoles no es adoptar Flash 3.6. Es decidir si confían a Google la capa de orquestación de sus agentes o mantienen control propio con frameworks como LangGraph o Temporal. Los hooks reducen la fricción para quedarse dentro del ecosistema Google, que es exactamente el objetivo del movimiento.

Para las empresas que buscan una agencia especializada en agentes autónomos, esta actualización cambia el punto de entrada: ahora puedes desplegar lógica de negocio compleja sin necesidad de mantener tu propio servidor de orquestación, siempre que aceptes el lock-in implícito.

Liquid AI y los encoders que corren en CPU: la propuesta es más seria de lo que parece

Mientras Google consolida su posición en orquestación, Liquid AI lleva semanas haciendo movimientos más silenciosos pero potencialmente más disruptivos para ciertos verticales. Sus dos nuevos encoders bidireccionales —LFM2.5-Encoder-230M y LFM2.5-Encoder-350M— vienen con un dato que no se ve todos los días: el modelo de 230M completa un pase completo de 8.192 tokens en CPU en aproximadamente 28 segundos.

28 segundos en CPU puede sonar lento si estás acostumbrado a pensar en latencia de inferencia GPU. Pero hay que reencuadrar el problema. Para casos de uso de clasificación de documentos, búsqueda semántica en batch, o enriquecimiento asíncrono de datos —que son el pan de cada día de la automatización empresarial— no necesitas respuesta en milisegundos. Necesitas que el coste de infraestructura no te mate.

El modelo de 350M alcanza el cuarto lugar en benchmarks combinados de GLUE, SuperGLUE y multilingüe entre 14 modelos evaluados. Eso lo sitúa en territorio competitivo frente a encoders como DeBERTa o los modelos de la familia BGE, que hasta ahora dominaban en aplicaciones de retrieval y clasificación. Y con contexto nativo de 8K tokens, elimina uno de los principales cuellos de botella de los encoders tradicionales para documentos largos.

El ecosistema de agencias de IA en Barcelona está especialmente activo en proyectos de procesamiento documental para sectores como legal y seguros —verticales donde el coste de inferencia GPU en producción es un problema estructural. Un encoder que funciona razonablemente bien en CPU abre la puerta a despliegues on-premise sin la complejidad de gestionar clústeres GPU, algo que muchos departamentos de TI medianos llevan pidiendo desde hace dos años.

La taxonomía que nadie explica bien: prompts, bucles y grafos como capas de ingeniería

El artículo de MarkTechPost sobre ingeniería de prompts, bucles y grafos toca un punto de confusión genuina en el mercado, aunque lo resuelve de forma algo académica. Vale la pena dar la versión pragmática para equipos que están construyendo ahora.

La ingeniería de prompts es la capa más superficial: optimizas la instrucción que recibe el modelo. Tiene un techo bajo porque no controlas el flujo de ejecución. La ingeniería de bucles —lo que habitualmente se llama agentic loop o ReAct— añade control sobre cuándo el modelo llama a herramientas y cómo procesa las respuestas iterativamente. Es donde viven la mayoría de los agentes en producción hoy. La ingeniería de grafos es la capa de orquestación completa: defines explícitamente los estados, las transiciones y las condiciones de salida del sistema.

Lo relevante para un CTO que está evaluando capacidades de equipo: la distancia en complejidad entre estas capas no es lineal. Pasar de prompts a bucles requiere principalmente entender la arquitectura de agentes y manejo de estado. Pasar de bucles a grafos requiere pensar en términos de sistemas distribuidos y tolerancia a fallos. Son perfiles distintos, y confundirlos en las descripciones de empleo —como hace la mayoría del mercado ahora mismo— genera equipos mal dimensionados para el problema real.

Las agencias de IA en Madrid que están reclutando perfiles técnicos en este momento deberían usar esta taxonomía en sus procesos de selección. No es lo mismo contratar a alguien que optimiza prompts que a alguien que diseña grafos de estado tolerantes a fallos.

MoonEP y el open source para MoE: relevante, pero para quién exactamente

Moonshot AI publicó MoonEP bajo licencia MIT como parte del Kimi K3 Open Day. La biblioteca optimiza la comunicación entre expertos en modelos Mixture-of-Experts distribuidos a gran escala. Técnicamente interesante. El problema es la audiencia real: si estás entrenando modelos MoE a escala suficiente para que MoonEP sea relevante, no necesitas leer este artículo para saber que existe. Y si no llegas a esa escala, MoonEP no te aplica.

Dicho esto, el movimiento de Moonshot de abrir este tipo de infraestructura de entrenamiento es consistente con la presión que ejerce el ecosistema open source chino sobre los proveedores occidentales. Cada pieza de infraestructura que se publica bajo MIT reduce el coste de entrada para labs que quieran entrenar sus propios modelos MoE, lo que a medio plazo presiona los márgenes de los proveedores de modelos propietarios.

Para una consultoría de IA que asesora a grandes corporaciones sobre estrategia de modelos, la lectura correcta de MoonEP no es técnica sino competitiva: el coste de tener capacidad propia de entrenamiento sigue bajando, y la decisión de comprar vs. construir se va a revisar en más empresas de las que parece en los próximos doce meses.

Pangram 4 y la detección de texto IA: el negocio del miedo a escala

Pangram afirma que su detector Pangram 4 comete un solo falso positivo por cada 24.000 documentos, con una tasa de detección del 99,66% del texto generado por IA. Los números son llamativos. La parte que no está en el titular es que los precios de API aumentarán entre dos y diez veces.

Ese rango de incremento —2x a 10x— es una señal de que el modelo de pricing todavía no ha encontrado su equilibrio. Una empresa que sube precios en ese rango o bien está corrigiendo una subvaloración inicial agresiva para ganar mercado, o bien está apostando a que el lock-in de sus clientes actuales absorbe el impacto. En cualquier caso, para equipos que han integrado detección de texto IA en flujos de moderación de contenido o procesos de auditoría, este es el momento de evaluar alternativas antes de que la factura cambie.

La resistencia a herramientas humanizadoras que menciona Pangram es el punto técnicamente más relevante del anuncio: el gato y el ratón entre generadores y detectores va a seguir acelerándose, y cualquier empresa que ponga detección de IA como control de calidad crítico en sus procesos debería tener un plan B por diseño, no por accidente.

El mercado de automatización con IA en España va a tener que incorporar esta variable en sus arquitecturas: los sistemas de validación de contenido que hoy son un nice-to-have se convertirán en infraestructura crítica en verticales regulados como financiero, legal o sanitario. La cadena de farmacias en Vermont que implementa IA para eficiencia operativa es el tipo de caso que, trasladado al contexto europeo con GDPR y normativa sanitaria encima, exige un nivel de trazabilidad y auditabilidad que la mayoría de las implementaciones actuales no contemplan desde el diseño.

La convergencia entre hooks en APIs de agentes, encoders CPU-friendly y detectores de contenido más precisos apunta hacia el mismo destino: 2026 es el año en que la infraestructura de agentes en producción madura de verdad. Quien esté construyendo ahora con estas piezas tiene ventaja; quien espere a que el mercado se estabilice llegará tarde a una ventana que se cierra más rápido de lo que la mayoría anticipa.

Temas relacionados en agentes.ai

Si quieres aplicar lo que lees en tu empresa, estos son puntos de partida útiles dentro de agentes.ai:

• Directorio de agencias de agentes de voz
• Agencias de IA en Barcelona y en Bilbao
• Explora el directorio completo de agencias de IA
• Sigue las últimas noticias de IA en tiempo real