Contactar Agendar llamada

Categoría: Agentes de IA

  • Memoria de agentes: olvidar bien importa mas que recordar

    Memoria de agentes: olvidar bien importa mas que recordar

    La memoria de agentes guiada por esquemas parte de una idea incomoda: la mayoria de sistemas de memoria fallan no porque recuerden poco, sino porque recuerdan mal. El debate habitual gira en torno a maximizar el recall, cuando el verdadero cuello de botella es decidir que olvidar y como estructurar lo que se conserva. La propuesta consiste en definir esquemas explicitos antes de generar la memoria, acotando que tipos de entidades, campos y relaciones puede extraer el modelo. Un cambio de enfoque que, sobre el papel, parece menor pero altera la economia completa de un agente con estado.

    Por que recordarlo todo es un mal objetivo

    El patron dominante en muchos sistemas de memoria consiste en extraer entidades y relaciones sin restricciones desde texto libre. El resultado es un grafo de conocimiento que crece sin control y que, en la practica, acaba comportandose como un costoso vector store generico: almacena mucho, recupera con ruido y aporta poco mas que una busqueda semantica corriente. El articulo que analizamos sostiene que esa obsesion por el recall ignora el problema central, que es la estructura. Si todo entra sin filtro, nada esta realmente organizado.

    La memoria de agentes hereda asi un vicio conocido en gestion de datos: confundir volumen con utilidad. Un grafo poblado por extraccion libre mezcla hechos relevantes con detalles irrelevantes, duplica entidades mal normalizadas y dificulta el versionado. Cuando llega el momento de consultar, el agente no sabe que busca porque nunca se definio que importaba. La extraccion sin esquema delega esa decision al modelo en tiempo de generacion, justo donde menos control se tiene. El planteamiento alternativo invierte el orden: primero se decide la forma, despues se rellena.

    Esquemas explicitos: la analogia con function calling

    La solucion propuesta es usar esquemas explicitos, por ejemplo modelos Pydantic, que definan los tipos de entidades, sus campos, las relaciones permitidas y las restricciones de cada una antes de generar nada. La logica es la misma que opera en el function calling: al acotar el espacio de salida, el modelo sabe exactamente que tiene que buscar y rellenar, en lugar de inventar una estructura sobre la marcha. La memoria de agentes deja de ser un vertedero semantico para convertirse en un repositorio tipado y predecible.

    Las ventajas son concretas. Acotar la salida reduce el ruido, porque el modelo descarta lo que no encaja en el esquema. Facilita el versionado, ya que un esquema es un contrato explicito que se puede evolucionar de forma controlada. Y permite gestionar mejor la granularidad temporal y la evolucion del grafo de conocimiento: se decide que se actualiza, que se sobrescribe y que se conserva como historico. Frente a la extraccion libre, donde cada ejecucion produce un grafo ligeramente distinto, el esquema impone consistencia. Esa consistencia es la que convierte un grafo de conocimiento en algo consultable y mantenible a largo plazo.

    Como pueden aplicar esto las empresas hoy

    La recomendacion practica es empezar pequeno. En lugar de modelar todo el dominio de golpe, conviene definir unos pocos tipos de entidades y aristas que capturen la mayor parte de la logica del negocio, y refinar el esquema a medida que aparecen errores o necesidades reales en produccion. Para una PYME que esta montando un agente de soporte, un CRM conversacional o un asistente interno, esto evita el error mas caro: invertir semanas en un grafo de conocimiento sobreingenierizado que nadie consulta bien. Si vas a construir memoria de agentes, define primero tres o cuatro entidades clave (cliente, producto, incidencia, contrato) y sus relaciones, valida que el modelo las rellena bien y crece desde ahi.

    Sobre ROI: un esquema explicito reduce coste de tokens al extraer solo lo relevante, baja el coste de mantenimiento al hacer el grafo versionable y mejora la precision de las respuestas del agente. Que evitar: no caer en la extraccion libre por comodidad inicial, y no confundir un grafo de conocimiento con una base vectorial disfrazada. Si tu sistema de memoria solo hace busqueda semantica, no necesitas un grafo; necesitas honestidad sobre que problema resuelves.

    Analisis Blixel

    Llevamos un par de anos viendo equipos que tratan la persistencia de un agente como un problema de almacenamiento cuando en realidad es un problema de diseno de datos de toda la vida. Aqui no hay magia nueva: hay modelado de dominio aplicado a un contexto donde un LLM hace de extractor. Y eso es buena noticia, porque significa que las disciplinas que ya conocemos (definir entidades, restricciones, contratos, versionado) siguen siendo el camino. La trampa del vector store generico disfrazado de grafo es real y la hemos visto en clientes que pagaban infraestructura compleja para obtener resultados que una busqueda semantica les daba mas barato. El consejo de empezar con pocos tipos de entidad es el mas valioso del articulo, aunque tambien el mas ignorado: hay una tentacion fuerte de modelar el dominio entero antes de tener un solo usuario. No lo hagas. El esquema correcto se descubre observando los fallos en produccion, no en una pizarra. Donde matizamos: el enfoque por esquemas anade rigidez, y para dominios muy abiertos o exploratorios esa rigidez puede limitar mas de lo que ayuda. No es una bala de plata, es una decision de ingenieria con sus contrapartidas. La clave esta en saber si tu agente opera sobre un dominio acotado (donde el esquema brilla) o sobre uno impredecible (donde quiza necesites un hibrido). Como casi todo en este campo, la respuesta depende del caso, no de la moda.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Agentes de IA autonomos: donde poner los limites

    Agentes de IA autonomos: donde poner los limites

    Los agentes de IA autonomos han dejado de pedir permiso para cada paso. Claude Fable 5 puede ejecutar tareas durante horas, mantener un objetivo a lo largo de varios dias y tomar decisiones intermedias sin volver a consultar al usuario. Es un salto operativo real, pero tambien un cambio en quien asume el riesgo. Cuando un sistema actua solo durante una jornada entera, la pregunta deja de ser que puede hacer y pasa a ser que no debe hacer bajo ninguna circunstancia. Ese es el debate de fondo.

    Que ha pasado y por que importa

    Claude Fable 5 se presenta como un agente capaz de sostener tareas largas: ejecutar procesos durante horas, recordar objetivos a lo largo de dias y actuar sin pedir confirmacion constante. En la practica, esto significa que un agente puede encadenar decisiones, llamar a herramientas, modificar ficheros o lanzar acciones sin que una persona revise cada paso. El atractivo es evidente: tareas que antes exigian supervision continua ahora pueden delegarse de forma mas completa.

    El reverso es igual de claro. Un agente con tanta libertad operativa puede ejecutar acciones no deseadas o imprevistas, sobre todo cuando interpreta mal una instruccion o encuentra un camino que el usuario no anticipo. El analisis del que partimos no celebra la autonomia sin matices: insiste en que el valor de los agentes de IA autonomos depende de los limites que se les imponen, no solo de lo que son capaces de hacer.

    Hasta ahora la mayoria de asistentes funcionaban en ciclos cortos: peticion, respuesta, validacion humana. La novedad es la persistencia. Un agente que recuerda y persiste en el tiempo acumula contexto, pero tambien acumula oportunidades de desviarse. Esa diferencia entre asistir y operar es la que cambia las reglas del juego.

    Implicaciones tecnicas y de control

    El texto propone una idea central: trabajar con agentes de IA autonomos exige trazar lineas explicitas. Tres categorias claras. Que esta permitido sin intervencion, que requiere aprobacion humana antes de ejecutarse y que esta prohibido de forma absoluta. Sin esa separacion, la autonomia se convierte en una caja negra que actua mas rapido de lo que cualquiera puede revisar.

    Para sostener esas lineas hacen falta mecanismos concretos. Los permisos granulares permiten autorizar acciones especificas en lugar de dar acceso total: leer pero no escribir, consultar pero no enviar, preparar pero no ejecutar. La auditoria de acciones registra cada paso que el agente da, de modo que una decision equivocada se pueda rastrear y revertir. Y el diseno responsable de agentes que persisten en el tiempo obliga a pensar que ocurre cuando el contexto se acumula durante dias.

    La conclusion del articulo es sobria: el futuro del trabajo con agentes dependera del equilibrio entre autonomia util y salvaguardas robustas. Ni autonomia total ni control que anule la utilidad. El punto medio es donde estos sistemas se vuelven realmente aprovechables sin convertirse en un pasivo.

    Como pueden aplicar esto las empresas hoy

    Antes de desplegar un agente autonomo, defina sus tres listas: acciones libres, acciones que exigen aprobacion humana y acciones prohibidas. Empiece por la lista de prohibiciones, no por la de capacidades. Para una PYME esto se traduce en arrancar con permisos granulares minimos y ampliarlos solo cuando el agente demuestre fiabilidad en tareas concretas, no al reves. Active la auditoria de acciones desde el primer dia: un registro completo de lo que el agente hizo es lo que le permitira revertir un error y, sobre todo, confiar en el sistema.

    En cuanto al ROI, mida el coste de la supervision que elimina frente al coste de un fallo no detectado. Los agentes de IA autonomos rinden cuando la tarea es repetitiva, tiene resultados verificables y un margen de error tolerable. Evite delegar acciones irreversibles (pagos, borrados, comunicaciones externas) sin un paso de aprobacion humana. Lo que no debe hacer es soltar un agente sobre un proceso critico solo porque la tecnologia lo permita: la persistencia que lo hace util es la misma que amplifica un error si nadie traza las lineas.

    Analisis Blixel

    La conversacion sobre estos sistemas suele equivocar el enfoque. Se discute cuanto pueden hacer, cuando lo importante es cuanto se les permite hacer. Un agente que opera durante horas sin supervision no es impresionante por la duracion, sino por la cantidad de decisiones que toma sin que nadie las vea. Ahi esta el riesgo y ahi esta la responsabilidad de quien lo despliega.

    La buena noticia es que los mecanismos para acotarlo ya existen y no son exoticos: permisos por accion, registros auditables, pasos de aprobacion en lo irreversible. Son practicas de ingenieria conocidas, solo que aplicadas a un actor que ya no es una persona. El error que veremos en muchas empresas sera el contrario al esperado: no recelar de la IA, sino confiar demasiado rapido. Dar acceso total porque configurar limites cuesta mas trabajo que activar la autonomia completa.

    Nuestra posicion es clara: la autonomia sin lineas explicitas no es eficiencia, es riesgo trasladado a futuro. El equilibrio del que habla el articulo no es un punto de llegada, es una disciplina diaria. Conviene tratar a estos agentes como se trata a un empleado nuevo con mucha capacidad y poco contexto: margen para trabajar, supervision sobre lo critico y un registro de todo lo que hace. La tecnologia ya esta lista para la autonomia; la pregunta es si la organizacion esta lista para gobernarla.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Agent-EvalKit: medir agentes de IA antes de produccion

    Agent-EvalKit: medir agentes de IA antes de produccion

    La herramienta para evaluar agentes de IA de forma estructurada acaba de tener un nuevo nombre propio: Agent-EvalKit. Su propuesta es sencilla pero necesaria: dar a empresas y desarrolladores un marco con metricas estandarizadas para medir el rendimiento de sus agentes antes de ponerlos delante de un cliente o de un proceso critico. En un momento en el que muchos equipos despliegan agentes sin pruebas serias, contar con un kit de evaluacion sistematico aborda uno de los huecos mas evidentes del desarrollo actual con modelos de lenguaje.

    Que es Agent-EvalKit y por que importa

    Agent-EvalKit es una herramienta pensada para evaluar agentes de IA de manera estructurada y repetible. Frente a las pruebas ad hoc que suelen hacer los equipos —probar un par de prompts, ver si la respuesta tiene buena pinta y pasar a produccion—, el kit ofrece metricas estandarizadas que permiten comparar distintos agentes bajo las mismas condiciones. El objetivo declarado es identificar fallos antes del despliegue y optimizar el funcionamiento del agente con datos en lugar de intuiciones.

    La herramienta valida el comportamiento del agente en diversos escenarios de uso, lo que ayuda a detectar casos en los que el sistema se desvia, alucina o ejecuta acciones incorrectas. Este tipo de validacion es especialmente relevante cuando un agente no solo responde texto, sino que invoca herramientas, consulta APIs o encadena varios pasos. El contexto es claro: durante el ultimo ano los agentes han pasado de demos a despliegues reales, y la falta de evaluacion rigurosa se ha convertido en el principal freno para llevarlos a entornos serios sin sustos.

    Implicaciones tecnicas de evaluar agentes de IA

    El reto de evaluar agentes de IA no es trivial. A diferencia de un modelo que devuelve una unica respuesta, un agente toma decisiones encadenadas: elige que herramienta usar, en que orden y con que datos. Un fallo en el segundo paso puede arrastrarse hasta el ultimo, y un test que solo mire la salida final no detecta donde se rompio la cadena. Por eso un kit con metricas estandarizadas que cubra distintos escenarios aporta visibilidad sobre puntos concretos del flujo, no solo sobre el resultado.

    La estandarizacion tambien tiene un valor de comparacion. Sin un marco comun, decir que un agente es mejor que otro es poco mas que una opinion. Con metricas homogeneas, un equipo puede comparar dos versiones de su propio agente, o decidir entre dos enfoques distintos, sobre la misma base. Aqui conviene ser realista: ninguna herramienta de evaluacion sustituye al criterio humano ni a las pruebas con usuarios reales. Lo que aporta Agent-EvalKit es reducir la incertidumbre y convertir parte del trabajo de validacion, hoy artesanal, en un proceso medible y repetible que se puede integrar en el ciclo de desarrollo.

    Como pueden aplicar esto las empresas hoy

    Para una PYME o un equipo de desarrollo, el primer paso practico es no esperar a tener el agente terminado para evaluarlo. Conviene definir, desde el principio, que escenarios son criticos para el negocio —los casos donde un fallo cuesta dinero o reputacion— y usar el kit para validar precisamente esos. Empezar por ahi rinde mas que medirlo todo. En cuanto al ROI, la cuenta es directa: el coste de pasar unas horas evaluando agentes de IA es minimo frente al coste de un agente que ejecuta acciones erroneas con clientes reales.

    Que evitar: tratar las metricas como una nota de aprobado y ya esta. Un buen numero en un escenario controlado no garantiza buen comportamiento ante entradas inesperadas. Tampoco tiene sentido adoptar el kit sin alguien que sepa interpretar los resultados y traducirlos en cambios concretos. Para equipos pequenos, la recomendacion es integrar la evaluacion en el flujo de trabajo —ejecutarla en cada cambio relevante— en lugar de hacerla una sola vez antes de lanzar. Asi se detectan regresiones cuando se ajusta un prompt o se cambia de modelo.

    Analisis Blixel

    Llevamos meses viendo equipos que montan un agente en una tarde y lo lanzan sin una sola prueba estructurada. Funciona en la demo, falla en el tercer caso real y nadie sabe por que. Ese patron explica por que una herramienta como esta llega en buen momento: el cuello de botella de los agentes ya no es construirlos, sino confiar en ellos. Y la confianza, en ingenieria, se construye midiendo. Dicho esto, conviene bajar las expectativas. Un kit de evaluacion no convierte un mal agente en uno bueno; solo te dice cuanto de malo es y donde. El trabajo duro —rediseñar el flujo, acotar las herramientas, ajustar el contexto— sigue siendo humano. Tampoco hay que caer en la trampa de optimizar para la metrica en vez de para el usuario: un agente que saca un 9 en el test y frustra a la gente real no sirve de nada. Nuestra postura es clara: cualquier equipo que tenga agentes en produccion o a punto de estarlo deberia incorporar evaluacion sistematica ya, sea con esta herramienta o con otra. No por moda, sino porque es la diferencia entre depurar con datos y depurar a ciegas. La pieza que faltaba en muchos stacks de agentes no era mas potencia, era saber si lo que tienes funciona de verdad.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Como hacer que un LLM devuelva JSON fiable

    Como hacer que un LLM devuelva JSON fiable

    La generacion de salida estructurada con LLM ha dejado de ser un truco de prompts para convertirse en una disciplina de ingenieria. Una nueva coleccion de recetas practicas dentro del proyecto fw-ai reune patrones de integracion, definicion de esquemas y validacion programatica para que un modelo autoregresivo devuelva JSON y otras estructuras fiables. El planteamiento es directo: combinar prompts claros, esquemas explicitos y verificacion externa para que el output deje de ser una loteria. Para cualquier equipo que construye aplicaciones sobre modelos de lenguaje, este enfoque es la diferencia entre una demo y un sistema en produccion.

    Que recoge la guia y por que importa

    El repositorio funciona como un recetario aplicado: muestra ejemplos de integracion con LLMs, patrones de uso y buenas practicas de ingenieria de prompts y de diseno de flujos. El nucleo del material es la generacion de salida estructurada con LLM apoyada en herramientas externas, como validadores y esquemas, que controlan y verifican lo que produce el modelo. En lugar de confiar en que el texto generado tenga la forma correcta, el sistema impone esa forma y la comprueba antes de usarla.

    La logica es coherente con como funcionan los modelos: un LLM predice tokens, no garantiza estructuras. Pedirle JSON en el prompt ayuda, pero no asegura que el resultado sea valido ni que respete los campos esperados. Por eso el material insiste en definir esquemas, parsear la respuesta y rechazar o reintentar cuando no cumple. Es un cambio de mentalidad: pasar de tratar al modelo como oraculo a tratarlo como un componente mas dentro de una tuberia con contratos claros y puntos de verificacion.

    Implicaciones tecnicas de validar el output

    El valor real de la generacion de salida estructurada con LLM aparece cuando se combinan tres capas: un prompt que describe el formato esperado, un esquema que define los campos y tipos, y una validacion que comprueba la respuesta. Si el modelo devuelve algo malformado, el flujo puede reintentar, corregir o degradar de forma controlada. Esa combinacion convierte respuestas impredecibles en datos consumibles por el resto del software sin parches manuales.

    La guia tambien ilustra patrones de orquestacion y composicion de llamadas a modelos. En lugar de una unica peticion gigante, se encadenan pasos: extraer, estructurar, validar y, si hace falta, refinar. Este diseno reduce errores acumulados y facilita depurar donde falla el sistema. Para los equipos, la consecuencia practica es que la fiabilidad deja de depender del prompt perfecto y pasa a residir en la arquitectura. Un esquema bien definido es mas mantenible que un prompt de tres parrafos que nadie se atreve a tocar, y la validacion programatica detecta regresiones que la inspeccion visual nunca pillaria.

    Como pueden aplicar esto las empresas hoy

    Si una empresa ya usa modelos para extraer datos de facturas, clasificar tickets o rellenar formularios, este enfoque es aplicable de inmediato. El primer paso es definir un esquema claro para cada salida que el negocio consume: campos, tipos y valores obligatorios. El segundo, anadir validacion automatica que rechace cualquier respuesta que no encaje, con un reintento controlado antes de escalar a un humano. La generacion de salida estructurada con LLM bien implementada reduce el trabajo manual de revision y los errores que se cuelan en sistemas posteriores.

    Sobre el ROI: el ahorro no viene del modelo, sino de eliminar la correccion manual de outputs rotos y de poder integrar las respuestas directamente en bases de datos o APIs. Que evitar: confiar solo en el prompt sin validacion, montar orquestaciones de muchos pasos cuando uno basta, y elegir esquemas tan rigidos que el modelo nunca acierte. Empezar pequeno —un caso de extraccion con esquema y validacion— y medir tasa de respuestas validas antes de escalar es mas sensato que reescribir todo el flujo de golpe.

    Analisis Blixel

    Durante demasiado tiempo se ha vendido el prompt perfecto como la solucion a la fiabilidad de los modelos, y es una promesa que no se sostiene. Un modelo autoregresivo siempre tendra margen de error, y ningun parrafo de instrucciones lo elimina. Lo interesante de materiales como este es que devuelven el problema al terreno donde se resuelve de verdad: la ingenieria de software. Esquemas, contratos, validacion y reintentos son conceptos que cualquier equipo de backend lleva decadas aplicando, y aplicarlos a las salidas de un LLM es lo que separa un prototipo de un sistema que aguanta produccion.

    El riesgo, para las PYMEs sobre todo, es el exceso de ingenieria. No todo flujo necesita orquestaciones complejas ni cadenas de cinco llamadas. Muchas veces basta con un esquema y un validador para resolver el 90% de los casos, y montar arquitecturas elaboradas solo anade coste y puntos de fallo. La recomendacion honesta es empezar por lo minimo que funcione y crecer solo cuando los datos lo justifiquen. La fiabilidad no se compra con mas pasos, se gana con contratos claros y verificacion sistematica. Quien entienda eso sacara partido a los modelos sin depender de la suerte de cada respuesta, y quien lo ignore seguira parcheando outputs rotos a mano indefinidamente.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Jedify capta 24 millones para dar contexto a la IA

    Jedify capta 24 millones para dar contexto a la IA

    La startup Jedify acaba de cerrar una ronda de financiacion para agentes de IA de 24 millones de dolares, con un objetivo concreto: que los agentes dejen de operar a ciegas y entiendan de verdad como funciona cada empresa. La promesa no es menor. Hoy la mayoria de despliegues de agentes fracasan porque el modelo no conoce los procesos internos, los datos ni la jerga de la compania que los usa. Jedify quiere resolver ese punto ciego conectando los agentes con el contexto especifico del negocio, y ha convencido a sus inversores de que ahi esta el cuello de botella real.

    Que ha pasado y por que importa

    Jedify ha levantado 24 millones de dolares para desarrollar una plataforma que permite a los agentes de IA acceder al contexto especifico de cada negocio. En la practica, eso significa dotar al agente de informacion sobre los procesos internos, los datos y las operaciones particulares de la empresa que lo despliega. Segun la compania, esta capacidad es la que separa un agente que da respuestas genericas de uno que entiende como se trabaja realmente en una organizacion concreta.

    El argumento de fondo es coherente con lo que muchos equipos tecnicos llevan meses constatando. Un modelo potente sin acceso al contexto empresarial produce respuestas plausibles pero inutiles, porque desconoce las reglas, los flujos y los datos propietarios de la empresa. La ronda de financiacion para agentes de IA que ha conseguido Jedify se destina precisamente a expandir esa tecnologia de conexion entre agentes e informacion contextualizada. No es una apuesta por un modelo mas grande, sino por la capa que hace que un modelo ya existente sea util dentro de una organizacion concreta.

    Implicaciones tecnicas y de mercado

    El movimiento de Jedify se inscribe en una tendencia clara del mercado: el valor se esta desplazando del modelo base hacia la capa de contexto. Mientras los grandes laboratorios compiten por la capacidad bruta de sus LLM, crece una categoria de empresas centradas en la integracion, la recuperacion de informacion y la conexion con sistemas internos. Tecnicas como RAG y protocolos de conexion tipo MCP apuntan en esa direccion, y una ronda de financiacion para agentes de IA de este tamano confirma que los inversores ven negocio en esa capa intermedia.

    Para el resto del sector, la lectura es directa. La pelea por dar contexto empresarial a los agentes es un campo cada vez mas disputado, donde compiten startups especializadas, proveedores cloud y los propios fabricantes de modelos que amplian sus plataformas. Jedify entra con capital fresco para acelerar, pero tendra que demostrar que su enfoque ofrece algo defendible frente a actores con mas musculo. La cifra de 24 millones le da margen para construir y vender, no para dominar un mercado todavia inmaduro.

    Que significa este movimiento para el mercado

    Para los compradores empresariales, esta inversion es una senal de que el problema del contexto ya tiene proveedores especializados dispuestos a resolverlo, en lugar de obligar a cada empresa a construir su propia integracion desde cero. Eso puede acortar plazos, pero tambien introduce dependencia de un tercero joven cuya supervivencia no esta garantizada. Conviene evaluar Jedify como lo que es: una startup recien financiada, con producto en expansion y sin la trayectoria de un proveedor consolidado.

    Para los competidores, el mensaje es que la capa de contexto se esta convirtiendo en un mercado propio, separado del de los modelos. Los proveedores cloud y los fabricantes de LLM tienen incentivos para absorber esta funcionalidad dentro de sus plataformas, lo que presiona a las startups independientes a diferenciarse rapido o buscar una adquisicion. Para los proveedores de servicios y consultoras, abre la puerta a proyectos de integracion donde el reto no es elegir el modelo, sino conectar los datos y procesos de cada cliente. Quien resuelva esa conexion con menos friccion captura el valor.

    Analisis Blixel

    El cuello de botella de los agentes nunca fue la inteligencia del modelo, sino su ignorancia sobre la empresa que lo usa. Por eso una inversion centrada en la capa de contexto tiene mas sentido que otra ronda destinada a entrenar un modelo marginalmente mejor. El sector lleva meses descubriendo, proyecto a proyecto, que un agente sin acceso a los datos internos es poco mas que un chatbot elocuente. Que el capital empiece a fluir hacia ese problema concreto es una buena noticia para quien quiere resultados reales.

    Dicho esto, conviene moderar el entusiasmo. Conectar un agente con los datos y procesos de una empresa no es solo un reto tecnico: es un reto de gobernanza, permisos, calidad del dato y seguridad. Una plataforma que da contexto empresarial a los agentes hereda todos los problemas de los datos que consume, incluidos los silos mal documentados y la informacion contradictoria que abunda en cualquier organizacion. Ninguna ronda de financiacion arregla un dato sucio. Para una PYME espanola, la pregunta no es si Jedify es prometedora, sino si su propia casa de datos esta lo bastante ordenada como para que cualquier capa de contexto aporte valor. Nuestra recomendacion es la de siempre: antes de comprar la herramienta de moda, ordena los datos y define que decision quieres automatizar. La tecnologia llega cuando el problema esta bien planteado, no antes.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Agentes de IA que tramitan reclamaciones de seguros solos

    Agentes de IA que tramitan reclamaciones de seguros solos

    La automatizacion de reclamaciones de seguros con agentes de IA acaba de dar un paso concreto: un sistema construido con Strands Agents y Amazon Bedrock AgentCore Browser Tool que gestiona las fases iniciales del proceso sin intervencion humana. La idea es sencilla de explicar y dificil de ejecutar bien: que un agente capture, valide e inicie una reclamacion navegando por interfaces web como lo haria una persona. Para las aseguradoras, el atractivo es directo: menos tiempos muertos, menos coste operativo y un arranque mas rapido del expediente. Veamos que hay realmente detras y donde estan los limites.

    Que ha pasado y por que importa

    Se ha presentado un sistema de automatizacion de reclamaciones de seguros con agentes de IA que combina dos piezas: Strands Agents, un framework para orquestar agentes, y Amazon Bedrock AgentCore Browser Tool, que da al agente la capacidad de operar un navegador web de forma autonoma. El conjunto se aplica al tramo inicial de una reclamacion: capturar los datos del siniestro, validarlos y poner en marcha el expediente sin que un operador tenga que teclear o revisar manualmente cada campo.

    El componente de procesamiento de lenguaje natural permite interpretar la informacion que aporta el cliente, mientras que la herramienta de navegacion ejecuta las acciones dentro de los sistemas web de la aseguradora. El resultado buscado es reducir el tiempo de respuesta y bajar el coste por reclamacion gestionada, ademas de acelerar el momento en que el cliente recibe confirmacion de que su caso esta en marcha.

    El sector asegurador lleva anos intentando digitalizar el alta de siniestros, una fase tradicionalmente intensiva en mano de obra y propensa a errores de transcripcion. Lo novedoso aqui no es la automatizacion en si, sino que un agente navegue por interfaces pensadas para humanos, sin necesidad de integraciones API a medida con cada sistema legado.

    Implicaciones tecnicas de la automatizacion de reclamaciones de seguros con agentes de IA

    La automatizacion de reclamaciones de seguros con agentes de IA basada en un Browser Tool resuelve un problema clasico: muchos sistemas internos de aseguradoras no exponen APIs limpias, y conectarlos requiere proyectos largos y caros. Que el agente opere el navegador permite saltarse esa barrera y trabajar sobre la interfaz existente, lo que reduce el coste de integracion inicial.

    El reverso de la moneda es la fragilidad. Un flujo que depende de pulsar elementos de una web es sensible a cambios de interfaz, a tiempos de carga y a estados inesperados. La validacion de datos de siniestros tampoco es trivial: un error en el alta arrastra problemas a todo el expediente. Por eso el sistema se centra en las fases iniciales y deja la resolucion del caso fuera del bucle autonomo.

    Strands Agents aporta la orquestacion, es decir, el control de que paso ejecuta el agente y cuando pedir ayuda o detenerse. Esa logica de control es donde se juega la fiabilidad: sin trazabilidad de cada accion y sin puntos de parada claros, un agente que navega solo puede generar tanto trabajo de revision como el que ahorra.

    Como pueden aplicar esto las empresas hoy

    Si gestionas una correduria o una aseguradora mediana, el primer paso no es desplegar agentes en produccion, sino medir. Cronometra cuanto tarda hoy el alta de una reclamacion y cuantos errores de transcripcion genera: ese es tu punto de comparacion para calcular ROI real. La automatizacion de reclamaciones de seguros con agentes de IA tiene sentido cuando el volumen es alto y repetitivo; con pocos casos al mes, el coste de montar y mantener el sistema no compensa.

    Empieza por un piloto acotado a un solo tipo de siniestro sencillo, con un humano revisando cada salida del agente antes de que pase a expediente. Define metricas: porcentaje de reclamaciones completadas sin intervencion, tasa de error y tiempo ahorrado. Lo que conviene evitar: lanzar el agente sobre todo el catalogo de productos de golpe, y confiar en la navegacion autonoma sin un registro de auditoria de cada accion. Si tu interfaz interna cambia con frecuencia, presupuesta el mantenimiento del agente como coste recurrente, no como gasto unico.

    Analisis Blixel

    Hacer que un agente navegue por una web pensada para personas es, a la vez, lo mas practico y lo mas fragil de este enfoque. Practico porque esquiva el cuello de botella eterno de los seguros: integrar sistemas legado que nadie quiere tocar. Fragil porque cualquier rediseno de una pantalla puede romper el flujo y nadie se entera hasta que se acumulan los errores. Nuestra lectura es que la automatizacion de reclamaciones de seguros con agentes de IA es una via legitima, pero no una bala de plata. El valor real esta en el tramo inicial, repetitivo y de bajo riesgo, exactamente donde lo situa este sistema. Donde vemos a las empresas tropezar es en confundir un piloto que funciona en demo con un proceso fiable a escala. La diferencia esta en la trazabilidad, en los puntos de parada y en mantener a un humano supervisando hasta tener metricas solidas. Para una PYME aseguradora, el consejo es resistir la tentacion de automatizar todo el ciclo y centrarse en lo medible: alta de siniestros sencillos, validacion basica y poco mas. Si los numeros salen ahi, se amplia. Si no salen, se ha aprendido barato. La IA agentica que opera navegadores madurara, pero hoy exige disciplina operativa mas que entusiasmo tecnologico.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Opik: observabilidad de agentes de IA en codigo abierto

    Opik: observabilidad de agentes de IA en codigo abierto

    La observabilidad de agentes de IA ha dejado de ser un lujo para convertirse en un requisito tecnico. Opik, la plataforma de codigo abierto mantenida por comet-ml, llega para depurar, evaluar y monitorizar aplicaciones de LLM, sistemas RAG y flujos de trabajo agenticos. Su propuesta es directa: capturar cada paso, accion y contexto de una ejecucion para entender que hizo realmente un agente y por que. En un momento en que muchas empresas despliegan agentes sin saber como se comportan en produccion, una herramienta de trazabilidad detallada deja de ser opcional.

    Que es Opik y por que importa para quien despliega agentes

    Opik es una plataforma de codigo abierto orientada a la observabilidad de agentes de IA y a las aplicaciones basadas en modelos de lenguaje. Esta mantenida por comet-ml, se distribuye publicamente en GitHub y se integra en pipelines existentes para analizar y optimizar agentes en produccion. Su funcion central es la trazabilidad: registra los pasos, las acciones y el contexto de cada ejecucion, de modo que un equipo pueda reconstruir que decidio el agente, con que datos y en que orden.

    A esto suma cuadros de mando de produccion, evaluacion automatizada y seguimiento continuo. La idea es cerrar el bucle de mejora sin depender unicamente de la revision manual, que no escala cuando un agente procesa miles de interacciones al dia. Hasta ahora, depurar un fallo de un agente solia implicar revisar logs dispersos o reproducir el caso a mano. La observabilidad estructurada cambia ese enfoque: convierte la depuracion en un proceso medible y repetible, mas cercano a las practicas de MLOps que al ensayo y error artesanal.

    Implicaciones tecnicas de la trazabilidad en flujos agenticos

    El valor tecnico de Opik esta en como aborda la complejidad de los sistemas agenticos. Un flujo de trabajo con LLM rara vez es una sola llamada: encadena recuperacion de contexto, decisiones intermedias, llamadas a herramientas y generacion final. Cuando algo falla, el problema puede estar en cualquier eslabon. La trazabilidad detallada que ofrece la observabilidad de agentes de IA permite aislar el punto exacto donde se desvio el comportamiento, sin tener que adivinar.

    La evaluacion automatizada anade otra capa: en lugar de validar respuestas una a una, se definen criterios que se aplican de forma continua sobre las ejecuciones reales. Esto es clave en sistemas RAG, donde la calidad depende tanto del modelo como de los documentos recuperados. Al ser de codigo abierto e integrable en pipelines existentes, Opik no obliga a reescribir la arquitectura ni a depender de un proveedor cerrado. Para equipos que ya trabajan con herramientas propias de MLOps, ese encaje reduce la friccion de adopcion y evita el riesgo de quedar atado a una plataforma propietaria de monitorizacion.

    Como pueden aplicar esto las empresas hoy

    Para una PYME que ya tiene un agente o un chatbot RAG en produccion, el primer paso practico es instrumentar las ejecuciones con la observabilidad de agentes de IA antes de seguir anadiendo funcionalidades. Sin trazabilidad, cada incidencia se convierte en horas de depuracion manual. Al ser open source, Opik permite empezar sin coste de licencia, lo que reduce la barrera de entrada para equipos pequenos que no pueden permitirse suites comerciales caras.

    La evaluacion de ROI debe ser honesta: el valor aparece cuando el volumen de interacciones hace inviable la revision manual o cuando un fallo del agente tiene impacto directo en clientes. Si el agente atiende pocas consultas al dia, la inversion en montar la observabilidad puede no compensar todavia. Lo que conviene evitar es desplegar agentes en produccion sin ninguna capa de monitorizacion: es la causa mas comun de comportamientos inesperados que llegan al usuario final. Empezar por instrumentar los flujos criticos, definir unas pocas metricas de evaluacion automatizada y revisar los cuadros de mando semanalmente es un punto de partida razonable y sostenible.

    Analisis Blixel

    Demasiadas empresas despliegan agentes como si fueran scripts deterministas, y luego se sorprenden cuando el comportamiento se degrada sin explicacion aparente. El verdadero problema no es la falta de modelos potentes, sino la ausencia de visibilidad sobre lo que esos modelos hacen una vez en produccion. Ahi es donde una herramienta como esta encaja en una necesidad real y poco glamurosa: saber que pasa de verdad dentro del sistema.

    El que sea codigo abierto y este mantenido por comet-ml aporta dos cosas que valoramos: ausencia de bloqueo de proveedor y un punto de partida sin coste de licencia. Para una PYME espanola que esta empezando con agentes, esto importa mas que cualquier funcionalidad vistosa. Dicho esto, el codigo abierto no significa gratis: alguien tiene que instrumentar las trazas, definir las evaluaciones y revisar los cuadros de mando. Esa carga operativa es real y conviene planificarla.

    Nuestra recomendacion es pragmatica: la observabilidad no es un proyecto que se hace una vez, sino una practica continua. Quien la incorpore desde el primer despliegue se ahorrara semanas de depuracion a ciegas mas adelante. Quien la deje para cuando algo se rompa, descubrira que reconstruir lo que paso sin trazas es casi imposible. No es una herramienta que vaya a impresionar a nadie en una demo, pero es exactamente el tipo de infraestructura sin la que los agentes en produccion no deberian existir.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Apple renueva Siri con IA de Google para WWDC 2026

    Apple renueva Siri con IA de Google para WWDC 2026

    La nueva Siri con IA que Apple presentara en la WWDC 2026 marca un giro pragmatico: la compania incorporara tecnologia Gemini de Google para conversaciones mas naturales y el manejo de tareas complejas, y lanzara una app independiente de Siri para competir directamente con ChatGPT y Claude. Mas alla del titular, lo relevante para empresas y desarrolladores es la apertura a agentes de IA capaces de ejecutar reservas, gestionar documentos y controlar dispositivos desde el App Store. El evento se emitira en directo el lunes 6 de junio a las 10 a.m. PT.

    Que ha anunciado Apple y por que importa

    Apple confirmara en la WWDC 2026 una renovacion completa de Siri dentro de su plataforma Apple Intelligence. El cambio mas llamativo es tecnico: la nueva Siri con IA usara tecnologia Gemini de Google como motor para sostener conversaciones mas naturales y resolver tareas que hasta ahora quedaban fuera del alcance del asistente. Es un reconocimiento explicito de que el modelo propio no llegaba al nivel necesario, y de que Apple prioriza el resultado sobre la pureza del stack interno.

    El segundo movimiento es estrategico: una app de Siri independiente, pensada para competir cara a cara con ChatGPT y Claude. Hasta ahora Siri vivia incrustada en el sistema operativo; convertirla en aplicacion propia la coloca en el mismo terreno que los chatbots conversacionales que millones de usuarios ya tienen en sus pantallas de inicio.

    El contexto ayuda a entender la urgencia. Siri llevaba anos quedandose atras frente a asistentes basados en modelos de lenguaje grandes, y la promesa de una Apple Intelligence ambiciosa se habia retrasado mas de lo previsto. Apoyarse en Gemini permite a Apple acortar distancias sin esperar a madurar un modelo propio competitivo, una decision que pocos habrian anticipado de una compania tan celosa de su integracion vertical.

    Implicaciones tecnicas para desarrolladores y agentes

    La parte que mas interesa al ecosistema profesional son los agentes de IA integrados en el App Store. Segun lo previsto, la nueva Siri con IA permitira automatizar tareas como reservas, gestion de documentos y control de dispositivos inteligentes, lo que convierte al asistente en un orquestador de acciones y no solo en un buscador conversacional. Para un desarrollador, esto abre la puerta a exponer funciones de su app como capacidades invocables por el asistente.

    El detalle de combinar tecnologia Gemini para el razonamiento conversacional con el control de dispositivos del ecosistema Apple sugiere una arquitectura hibrida: el modelo externo aporta comprension y planificacion, mientras la capa de Apple gestiona permisos, privacidad y ejecucion en el dispositivo. Esa separacion es importante porque define donde viven los datos sensibles y que sale fuera del telefono.

    Para quien construye software, el reto sera adaptar las integraciones a este nuevo modelo de agentes sin asumir que la automatizacion sera infalible. Las tareas complejas encadenadas (reservar, confirmar, modificar) son justamente donde los asistentes fallan mas, y donde un error tiene consecuencias reales para el usuario final.

    Como pueden aplicar esto las empresas hoy

    Antes de junio, lo sensato no es esperar sentado sino preparar terreno. Si tu empresa tiene una app en el App Store, conviene revisar que tareas repetitivas de tus clientes (reservas, consultas de documentos, configuracion de dispositivos) podrian exponerse como acciones para la nueva Siri con IA cuando llegue el soporte. Documentar bien esos flujos ahora reduce el coste de integracion despues.

    En cuanto a ROI, el calculo realista es modesto al principio: la automatizacion via asistente reduce friccion en tareas de bajo riesgo, pero no sustituye procesos criticos donde un fallo cuesta dinero o reputacion. Empieza por casos acotados y reversibles. Lo que conviene evitar es rehacer tu producto entero apostando por una funcion que aun no se ha lanzado ni probado en produccion. Tambien hay que vigilar la dependencia de tecnologia Gemini dentro del ecosistema Apple: dos proveedores en una misma cadena implica revisar terminos de tratamiento de datos antes de mover informacion de clientes. La recomendacion practica es seguir la WWDC del 6 de junio, identificar las APIs concretas que se publiquen y pilotar con un flujo real medible.

    Analisis Blixel

    Que Apple recurra a un rival directo para alimentar su asistente dice mas sobre el estado del mercado que cualquier nota de prensa. La integracion vertical, dogma historico de Cupertino, cede ante una realidad incomoda: construir un modelo de lenguaje competitivo es caro, lento y no garantiza ventaja. Apostar por Gemini es admitir que el valor de Apple no esta en el modelo, sino en el dispositivo, la distribucion y la confianza del usuario. Es una jugada defensiva inteligente, aunque la dependencia tecnologica de Google tenga su precio a medio plazo. Para las empresas, el mensaje es claro y aplicable: no es necesario poseer el modelo para construir productos utiles encima de el. Lo que importa es el problema que resuelves y la experiencia que entregas. La promesa de agentes que reservan y gestionan documentos suena bien, pero conviene recordar cuantas veces hemos oido lo mismo sin que la automatizacion fiable llegara. La diferencia esta en los detalles que solo veremos en junio: que APIs se abren, que permisos exigen y cuanto control real tiene el desarrollador. Hasta entonces, la actitud razonable es prepararse sin reorganizar la estrategia entera alrededor de un anuncio. Quien tenga sus flujos documentados y sus datos en orden llegara en mejor posicion el dia que las integraciones esten disponibles. El resto correra detras.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • NVIDIA lleva Nemotron 3 Ultra a SageMaker JumpStart

    NVIDIA lleva Nemotron 3 Ultra a SageMaker JumpStart

    El modelo NVIDIA Nemotron 3 Ultra en SageMaker JumpStart ya esta disponible para cualquier equipo que trabaje en AWS. Se trata de un modelo de lenguaje abierto de 550 mil millones de parametros totales y 55 mil millones activos, construido sobre una arquitectura hibrida Transformer-Mamba MoE. NVIDIA lo ha pensado para agentes autonomos de larga duracion, con inferencia hasta 5 veces mas rapida y un ahorro de coste de hasta el 30% en cargas agenticas frente a modelos densos equivalentes. Aqui te contamos que cambia de verdad y para quien.

    Que ha pasado y por que importa

    NVIDIA ha publicado Nemotron 3 Ultra en Amazon SageMaker JumpStart, el catalogo de modelos preentrenados que se despliegan con pocos clics dentro de AWS. La novedad no es solo que sea un modelo grande, sino su disenо: una arquitectura hibrida que combina capas Transformer con capas Mamba y un esquema Mixture of Experts (MoE). De los 550 mil millones de parametros totales, solo 55 mil millones se activan por token, lo que reduce el coste de inferencia sin renunciar a la capacidad del modelo.

    El modelo NVIDIA Nemotron 3 Ultra en SageMaker JumpStart soporta ventanas de contexto de hasta 1 millon de tokens y usa el formato NVFP4 para ganar eficiencia en memoria y computo. Esa combinacion esta orientada a un caso concreto: agentes que ejecutan tareas largas, encadenan herramientas y mantienen estado durante mucho tiempo.

    Hasta ahora, desplegar modelos de este tamano implicaba montar infraestructura propia o negociar accesos con proveedores. Tenerlo en JumpStart como modelo abierto cambia la barrera de entrada: el aprovisionamiento, la red y el escalado quedan dentro del flujo habitual de AWS, sin construir el stack desde cero.

    Implicaciones tecnicas del modelo agentico de NVIDIA

    La eleccion de una arquitectura Transformer-Mamba MoE no es estetica. Las capas Mamba manejan secuencias largas con un coste que escala mejor que la atencion clasica, y el enrutado MoE activa solo una fraccion de los expertos por token. El resultado declarado es una inferencia hasta 5 veces mas rapida y hasta un 30% menos de coste en cargas agenticas comparado con modelos densos de capacidad similar. Para un orquestador de agentes que lanza miles de pasos, ese margen se nota en la factura.

    El contexto de 1 millon de tokens es el otro punto clave. Permite que un agente conserve historiales largos, documentacion completa o trazas de ejecucion sin trocear constantemente la informacion. El formato NVFP4 reduce la huella de memoria y acelera el computo, lo que ayuda a que un modelo de 550B parametros sea operable en produccion.

    El modelo NVIDIA Nemotron 3 Ultra en SageMaker JumpStart apunta a tres usos concretos: orquestadores de agentes, agentes de codigo y flujos empresariales complejos. Son escenarios donde la latencia acumulada y el coste por paso deciden si un proyecto es viable o se queda en prototipo.

    Como pueden aplicar esto las empresas hoy

    Lo primero es ser honestos con el tamano: 550 mil millones de parametros no es para un chatbot de FAQs. Tiene sentido cuando ya tienes un caso agentico real que encadena muchos pasos y donde el coste por inferencia se ha vuelto un problema. Para una PYME, el modelo NVIDIA Nemotron 3 Ultra en SageMaker JumpStart es interesante sobre todo si ya operas en AWS y quieres evaluar un modelo abierto sin montar infraestructura GPU propia.

    Antes de lanzarte, mide. Despliega en JumpStart, corre tu carga agentica real durante unos dias y compara coste y latencia frente a lo que ya usas. El 30% de ahorro y la inferencia 5 veces mas rapida son cifras del fabricante en cargas agenticas: tu mezcla de tareas puede dar otro resultado. Que evitar: adoptarlo para casos que un modelo mas pequeno resuelve igual de bien y mas barato, o activar contextos de 1 millon de tokens cuando tus prompts caben en 32K. El contexto largo cuesta. Empieza acotado, mide ROI por caso de uso y escala solo donde los numeros lo justifiquen.

    Analisis Blixel

    Lo interesante aqui no es el numero de parametros, sino hacia donde apunta el diseno. Combinar Mamba y MoE en lugar de apilar mas atencion densa es una senal clara: la industria empieza a optimizar para el coste real de los agentes, no para el benchmark de turno. Cuando un agente ejecuta miles de pasos, cada milisegundo y cada centimo se multiplican, y ahi es donde un modelo eficiente gana frente a uno mas potente sobre el papel.

    Dicho esto, conviene templar el entusiasmo. Tener un modelo de 550B parametros disponible con un clic no significa que tu empresa lo necesite. La mayoria de los proyectos agenticos que vemos fracasan por falta de un caso de uso claro, no por falta de potencia de modelo. El contexto de 1 millon de tokens suena espectacular, pero la mayoria de flujos empresariales no lo aprovechan y si pagan por el.

    Para quien ya tiene agentes en produccion sobre AWS y nota la factura crecer, esta es una opcion concreta que merece una prueba controlada. Para el resto, es una buena oportunidad de entender hacia donde va la arquitectura de los modelos agenticos antes de que sea la norma. La eficiencia, no el tamano, sera el campo de batalla de los proximos meses. Y eso, para las PYMEs, son buenas noticias: significa precios mas razonables.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • Endava reorganiza su entrega de software con agentes IA

    Endava reorganiza su entrega de software con agentes IA

    La integracion de agentes de IA en la entrega de software deja de ser un experimento aislado y empieza a tocar la columna vertebral de las consultoras tecnologicas. Endava ha anunciado que esta reestructurando sus procesos de desarrollo para meter agentes de IA dentro del flujo de trabajo de entrega, con el objetivo de automatizar tareas repetitivas y acelerar los ciclos de despliegue. Es un movimiento de estrategia corporativa con implicaciones para todo el sector de servicios IT, aunque la propia compania no ha detallado todavia metricas concretas ni la arquitectura tecnica que sostiene el cambio.

    Que ha pasado y por que importa

    Endava, una de las consultoras de ingenieria de software con presencia internacional, ha comunicado que rediseña su modelo de entrega para incorporar agentes de IA en el flujo de trabajo. La idea central es delegar a IA especializada las tareas repetitivas del desarrollo y comprimir los tiempos de despliegue. No hablamos de un asistente puntual para programadores, sino de una reorganizacion del proceso de delivery, lo que situa la apuesta en el plano estrategico y no solo en el de las herramientas.

    El contexto explica el gesto. El negocio de las consultoras tradicionales se ha medido durante decadas en horas facturables y tamano de equipo. Si los agentes de IA en la entrega de software absorben parte del trabajo repetitivo, ese modelo de facturacion por horas entra en tension. Conviene matizar: la informacion disponible no incluye detalles sobre la implementacion tecnica, los frameworks de agentes utilizados ni cifras de productividad. Por tanto, lo relevante ahora es la senal de direccion, no el resultado medido.

    Implicaciones para el mercado

    El anuncio se enmarca en una tendencia mas amplia: las consultoras de software estan reposicionando su propuesta de valor ante la presion de la IA generativa. Cuando el codigo repetitivo se automatiza, el diferencial se desplaza hacia la arquitectura, la integracion, la calidad y el conocimiento de negocio del cliente. Mover los agentes de IA en la entrega de software al nucleo del proceso es una manera de adelantarse a esa conversacion antes de que la impongan los clientes o los competidores.

    Para los compradores de servicios IT, el efecto practico es doble. Por un lado, presion a la baja en los presupuestos de proyectos cuya parte mecanica se automatiza. Por otro, una expectativa creciente de que el proveedor demuestre con datos el ahorro real, algo que aqui todavia no esta sobre la mesa. Para los competidores directos de Endava, el movimiento marca un liston: quien no tenga una respuesta sobre agentes en su delivery tendra que explicarse en las proximas licitaciones.

    Que significa este movimiento para el mercado

    Para los proveedores de servicios, la consecuencia inmediata es la necesidad de redefinir como se cobra el trabajo. Un modelo basado en horas pierde sentido cuando una parte sustancial del desarrollo la ejecutan agentes; tendra mas recorrido la facturacion por resultado o por valor entregado. Las consultoras que tarden en hacer esa transicion quedaran expuestas a una guerra de precios que no podran ganar.

    Para los buyers corporativos, la recomendacion es exigir transparencia. Ante un proveedor que vende agentes de IA en su entrega, conviene pedir como se controla la calidad del codigo generado, quien responde de los errores y que governance existe sobre lo que producen esos agentes. El riesgo no es solo tecnico: delegar partes del delivery en IA sin trazabilidad puede generar deuda tecnica dificil de auditar. Para los competidores, la lectura es clara: el debate ya no es si adoptar agentes, sino como hacerlo sin degradar la calidad ni la confianza del cliente.

    Analisis Blixel

    Cobrar por horas para tareas que una maquina hace en segundos era un modelo con fecha de caducidad, y las grandes consultoras lo saben desde hace tiempo. El anuncio, leido en frio, es mas un posicionamiento de mercado que una demostracion de resultados: faltan numeros, falta arquitectura y falta el detalle de como se garantiza la calidad de lo que producen esos agentes. Eso no le resta valor, pero obliga a tomarlo como lo que es, una declaracion de rumbo. La parte interesante no es el titular, sino la pregunta incomoda que abre: si el delivery se automatiza, donde queda el margen del proveedor y donde queda la responsabilidad sobre el codigo. Las companias que esten evaluando contratar este tipo de servicios harian bien en no dejarse seducir por la etiqueta de IA y exigir, en cambio, evidencias concretas: tasas de error, cobertura de tests, trazabilidad de lo generado y un modelo de governance claro. La automatizacion del desarrollo es real y va a redibujar el sector de servicios IT en pocos anos, pero el que la adopta sin control acumula riesgo en lugar de eliminarlo. Nuestra postura es pragmatica: aplaudimos el movimiento como senal de madurez del mercado y desconfiamos por defecto de cualquier promesa de aceleracion que no venga acompanada de metricas verificables.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • AWS publica guia para mejorar agentes IA con SFT y DPO

    AWS publica guia para mejorar agentes IA con SFT y DPO

    Amazon Web Services ha publicado una guia tecnica para optimizar agentes IA tool-calling mediante Supervised Fine-Tuning (SFT) y Direct Preference Optimization (DPO) en SageMaker AI. Esta metodologia aborda uno de los problemas mas criticos en produccion: que los agentes seleccionen las herramientas correctas en flujos de trabajo complejos, reduciendo errores que pueden costar miles de euros en operaciones empresariales fallidas.

    Que ha publicado AWS y por que es relevante ahora

    La guia de AWS documenta un proceso completo de entrenamiento usando el modelo Qwen3 1.7B con el dataset When2Call de NVIDIA, que incluye 15,000 muestras para SFT y 9,000 adicionales para DPO. Esta combinacion permite que los agentes IA tool-calling aprendan no solo que herramienta usar, sino cuando NO usarla, un matiz critico que los modelos base suelen fallar. El enfoque se centra en casos donde el agente debe decidir entre multiples APIs, bases de datos o servicios externos.

    El timing de esta publicacion coincide con la migracion masiva de aplicaciones agentivas desde entornos de piloto hacia produccion empresarial. Segun datos internos de AWS, el 60% de los fallos en agentes productivos se deben a seleccion incorrecta de herramientas, no a errores en la ejecucion de las herramientas mismas. Esta guia ataca directamente ese cuello de botella.

    Como funciona la metodologia SFT + DPO para tool-calling

    El Supervised Fine-Tuning entrena al modelo con ejemplos correctos de cuando usar cada herramienta, mientras que DPO va un paso mas alla: ensena al modelo a preferir respuestas correctas sobre incorrectas mediante comparaciones directas. En el contexto de agentes IA tool-calling, esto significa que el modelo aprende patrones como «si el usuario pregunta por ventas del ultimo trimestre, usa la API de analytics, NO la de inventario», pero tambien «si la consulta es ambigua, pide clarificacion antes que adivinar».

    La implementacion en SageMaker AI permite entrenar estos modelos sin gestionar infraestructura, usando instancias ml.g5.2xlarge para el entrenamiento SFT y ml.g5.4xlarge para DPO. El proceso completo toma entre 4-6 horas para un modelo de 1.7B parametros, con costes aproximados de 50-80 dolares por iteracion de entrenamiento, segun la configuracion elegida.

    Como pueden aplicar esto las empresas hoy

    Las empresas que ya tienen agentes en piloto pueden implementar esta metodologia siguiendo tres pasos concretos. Primero, recopilar logs de interacciones fallidas donde el agente eligio herramientas incorrectas – estos logs se convierten en datos de entrenamiento DPO. Segundo, crear un dataset balanceado que incluya tanto casos exitosos como fallidos, priorizando escenarios donde la ambiguedad es alta. Tercero, usar SageMaker AI para entrenar iterativamente, midiendo mejoras en precision de tool-calling antes de desplegar en produccion.

    El ROI es medible: una empresa con 1000 interacciones agentivas diarias que reduce errores de tool-calling del 15% al 3% puede ahorrar entre 20-40 horas semanales de intervencion manual, equivalente a 15,000-30,000 euros anuales solo en costes operativos. Para sectores como fintech o e-commerce, donde errores de herramienta pueden activar procesos incorrectos, el impacto es exponencialmente mayor.

    Analisis Blixel

    Esta guia marca un punto de inflexion en la madurez de agentes empresariales. Hasta ahora, la mayoria de empresas implementaban agentes con modelos base esperando que «aprendieran sobre la marcha», pero la realidad es que tool-calling requiere precision quirurgica que solo se logra con entrenamiento especifico. AWS no esta vendiendo una solucion magica, sino documentando lo que funciona en produccion real.

    Lo mas valioso no es la metodologia en si – SFT y DPO son tecnicas conocidas – sino la aplicacion especifica a tool-calling con datos reales y metricas de coste. El dataset When2Call de NVIDIA proporciona un baseline que las empresas pueden usar para evaluar si su implementacion esta funcionando o necesita ajustes. Para PYMEs que han invertido en agentes durante 2024, esta guia puede ser la diferencia entre un piloto que funciona y uno que escala rentablemente.

    Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.

  • AWS integra OAuth en AgentCore Gateway para agentes MCP

    AWS integra OAuth en AgentCore Gateway para agentes MCP

    AWS ha lanzado una configuración oficial de autenticación OAuth para AgentCore Gateway con clientes MCP, permitiendo que los agentes de IA accedan de forma segura a herramientas empresariales. Esta implementación resuelve uno de los principales obstáculos para adoptar agentes autónomos en entornos corporativos: verificar la identidad del usuario antes de que el agente ejecute acciones críticas.

    Qué incluye esta nueva configuración OAuth

    La guía técnica de AWS detalla cómo implementar el flujo de autorización OAuth Code entre tres componentes clave. Primero, el proveedor de identidad empresarial (Okta, Microsoft Entra ID o Amazon Cognito) que gestiona las credenciales y permisos de usuario. Segundo, AgentCore Gateway configurado con autorización JWT inbound que valida tokens antes de permitir acceso a servidores MCP. Tercero, el cliente Kiro IDE que maneja automáticamente el intercambio de tokens sin intervención manual del desarrollador.

    Esta arquitectura permite que los asistentes de IA mantengan sesiones autenticadas mientras ejecutan tareas que requieren acceso a sistemas internos. El flujo OAuth garantiza que cada acción del agente esté respaldada por credenciales válidas del usuario real, no por tokens genéricos o claves de servicio compartidas.

    Por qué esto cambia la seguridad en agentes empresariales

    Hasta ahora, conectar agentes de IA con herramientas empresariales requería configuraciones de seguridad ad-hoc o credenciales compartidas que violaban políticas corporativas. Los equipos de TI rechazaban implementaciones donde un agente podía acceder a sistemas críticos sin trazabilidad clara del usuario responsable. Esta configuración OAuth resuelve ese problema fundamental.

    El sistema permite auditoría granular: cada llamada del agente a un servidor MCP queda registrada con la identidad del usuario que inició la sesión. Los administradores pueden revocar acceso instantáneamente desde el proveedor de identidad, aplicando las mismas políticas de seguridad que usan para aplicaciones tradicionales. Además, los tokens tienen expiración automática, eliminando el riesgo de credenciales permanentes comprometidas.

    Cómo pueden aplicar esto las empresas hoy

    Las organizaciones que ya usan Okta, Microsoft Entra ID o Amazon Cognito pueden implementar esta configuración en días, no semanas. El proceso requiere crear una aplicación OIDC en el proveedor de identidad, configurar AgentCore Gateway con las claves públicas para validar JWT, y actualizar Kiro IDE con los endpoints de autorización. AWS proporciona plantillas CloudFormation que automatizan gran parte del despliegue.

    El ROI más inmediato aparece en equipos de desarrollo que necesitan agentes con acceso a APIs internas, bases de datos o herramientas de CI/CD. En lugar de crear sistemas de autenticación personalizados o usar credenciales de servicio inseguras, pueden aprovechar la infraestructura de identidad existente. Esto reduce tiempo de desarrollo y cumple automáticamente con auditorías de seguridad corporativas.

    Análisis Blixel

    Esta configuración OAuth marca un punto de inflexión para la adopción empresarial de agentes de IA. Durante meses, hemos visto organizaciones rechazar implementaciones de agentes por problemas de trazabilidad y control de acceso. AWS está resolviendo la fricción técnica más importante: integrar agentes con sistemas de identidad corporativos sin comprometer seguridad.

    Lo más relevante no es la tecnología en sí, sino que AWS está estandarizando patrones de seguridad para agentes empresariales. Esto acelera la adopción porque los equipos de TI ya conocen OAuth y pueden evaluar riesgos usando frameworks familiares. Esperamos que otros proveedores de agentes adopten configuraciones similares, creando un ecosistema más maduro y auditable para IA empresarial.

    ¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.