Cómo nOps envió agentes FinOps un 75 % más rápido con Amazon Bedrock AgentCore

nOps, una solución de optimización de la nube impulsada por IA, recientemente reinventó sus capacidades de análisis de operaciones financieras (FinOps) mediante la transición a Amazon Bedrock AgentCore. Amazon Bedrock AgentCore es un servicio para crear, conectar y optimizar agentes a escala, con cualquier marco o modelo. La nueva base ayuda a nOps a brindar un mejor servicio a los clientes que administran la optimización del compromiso en Amazon Web Services (AWS), Google Cloud Platform (GCP) y Microsoft Azure. A través de la optimización continua de compromisos como instancias reservadas y planes de ahorro de AWS, nOps ayuda a los equipos a maximizar los ahorros, reducir el riesgo y automatizar la carga operativa de las FinOps manuales. Hoy en día, nOps brinda soporte a clientes que representan más de 4 mil millones de dólares en gastos en la nube bajo administración.

En esta publicación, explicamos cómo nOps hizo la transición de nuestra experiencia de análisis y agentes para acelerar la entrega de productos, mejorar la calidad de la respuesta y reducir la complejidad operativa mediante Amazon Bedrock AgentCore, Databricks Lakehouse Metric Views, Databricks Lakebase, Amazon DynamoDB y Vercel.

Escalar la IA de FinOps más allá de los límites de la infraestructura centrada en API

A medida que ampliamos nuestra cartera de productos y nuestra base de clientes, los equipos de infraestructura, front-end y back-end necesitaban soportar flujos de trabajo de análisis cada vez más complejos y, al mismo tiempo, mantener una alta confiabilidad y un aislamiento multiinquilino. Los patrones de infraestructura existentes introdujeron fricciones:

Latencia e inconsistencia de la respuesta: los mensajes de contexto largos provenientes del acceso a datos basados ​​en API aumentaron la latencia y redujeron la consistencia de la respuesta. Complejidad del sistema: múltiples capas de orquestación y observabilidad aumentaron la complejidad del sistema. Lastre para la innovación: el tiempo de ingeniería se consumía cada vez más en el mantenimiento de la infraestructura en lugar de en la innovación de productos.

"Estábamos intentando construir capacidades avanzadas de IA sobre una infraestructura que no estaba diseñada para agentes basados ​​en análisis, lo que hacía que la iteración fuera lenta, compleja y propensa a imprecisiones".

– Jordán Stein

Estado actual

Antes de la transición, presentamos a Clara, nuestra agente de FinOps AI, además de los componentes de infraestructura existentes, incluidos Kubernetes, la invocación del modelo Amazon Bedrock, la orquestación LangChain/LangGraph y envoltorios de herramientas alrededor de las API web.

Esto permitió una entrega inicial rápida, pero también reveló límites estructurales:

Tiempo de obtención de información más lento: los datos en forma de API y las grandes ventanas de contexto aumentaron la latencia de los turnos. Gastos generales operativos: múltiples capas no diseñadas específicamente dificultaron la iteración y la depuración. Falta de coincidencia en la ruta de los datos: las respuestas de los agentes estaban vinculadas a las respuestas de la API en lugar de a una capa de análisis semántico dedicada.

Para abordar esto, cambiamos a una arquitectura diseñada específicamente centrada en Amazon Bedrock AgentCore para el tiempo de ejecución/orquestación, Databricks Metric Views para la semántica de análisis gobernada y Databricks Lakebase para un estado duradero de la aplicación. Elegimos Bedrock AgentCore por su tiempo de ejecución de agente administrado, memoria integrada y orquestación, junto con la libertad de utilizar cualquier marco o modelo. Con esta libertad, nos basamos en Strands y evolucionamos nuestras opciones de modelos sin cambiar de servicio, para que el equipo pudiera centrarse en la lógica del dominio en lugar de la infraestructura.

Descripción general de la solución

Diseñamos la nueva arquitectura para escalar con la demanda, producir respuestas precisas y permitir a los desarrolladores realizar envíos más rápido.

El siguiente diagrama ilustra la arquitectura de un extremo a otro de la solución nOps Clara creada en Amazon Bedrock AgentCore:

La solución consiste en:

Capa de interacción: una aplicación web Next.js alojada en Vercel donde los clientes interactúan con Clara a través de una interfaz conversacional respaldada por la transmisión de eventos enviados por el servidor. Capa de tiempo de ejecución del agente: Amazon Bedrock AgentCore ejecuta un único agente basado en Strands con acceso directo a herramientas para operaciones de lienzo, ejecución de consultas, descubrimiento de fuentes de datos y orquestación de flujos de trabajo, lo que alivia la sobrecarga de enrutamiento de múltiples agentes. Capa de datos: Databricks Lakehouse Metric Views que proporciona una capa de análisis semántico gobernado, con Databricks Lakebase (PostgreSQL sin servidor) que almacena el estado duradero de la aplicación, como sesiones, lienzos y especificaciones de widgets. Capa de flujo de trabajo asíncrono: una ruta de ejecución basada en eventos que utiliza el seguimiento de trabajos de Amazon DynamoDB, notificaciones de Amazon Simple Notification Service (Amazon SNS) y Amazon Simple Queue Service (Amazon SQS), y Amazon API Gateway WebSocket push para tareas de análisis de larga duración que actualizan la interfaz de usuario en tiempo real.

aplicación web

En la capa de interacción, los clientes utilizan Clara a través de una aplicación web alojada en Vercel. Las solicitudes fluyen a través de un backend para frontend (BFF) de Next.js que invoca Amazon Bedrock AgentCore. Clara se ejecuta como un tiempo de ejecución de agente basado en Strands que admite la transmisión de respuestas y llamadas de herramientas. Los usuarios pueden invocar manualmente los mismos flujos de trabajo que Clara llama a través de las herramientas de Strands. Este es un requisito importante y un componente básico para Clara porque requiere que el agente realice tareas que sigan los mismos procedimientos que lo haría un humano dentro de los requisitos del producto.

Back-end de Amazon Bedrock AgentCore

El tiempo de ejecución se implementa como un contenedor Docker en Amazon Bedrock AgentCore, con la infraestructura completa (tiempo de ejecución, memoria, barreras de seguridad, colas y funciones de trabajo) definida en una única pila del kit de desarrollo en la nube de AWS (AWS CDK). Clara utiliza una arquitectura de agente único en lugar de un enrutador de agentes múltiples: un agente de Strands con acceso directo a las siguientes herramientas: operaciones de lienzo, ejecución de consultas, descubrimiento de fuentes de datos y orquestación de flujo de trabajo. Esto evita la latencia y la sobrecarga de propagación de errores de las transferencias de agente a agente y, al mismo tiempo, mantiene el envío de herramientas determinista.

La transmisión es fundamental para la experiencia. Una capa de combinación personalizada se encuentra entre la secuencia asíncrona de Strands y la salida del evento enviado por el servidor, manejando tres preocupaciones en una sola pasada:

Los latidos mantienen vivas las conexiones durante ejecuciones prolongadas de herramientas. Un búfer de texto con vaciado que reconoce los límites de las palabras fusiona deltas de modelos pequeños en fragmentos legibles para ayudar a evitar el parpadeo de la interfaz de usuario (UI). Un trabajador de encuesta de widget intercala eventos de actualización del lienzo en tiempo real en la misma secuencia.

Clara utiliza la memoria AgentCore con tres estrategias (hechos semánticos, preferencias del usuario y resúmenes de lienzo), de modo que aprende cómo cada usuario interactúa con sus datos a lo largo del tiempo. Las preferencias informan las opciones de diseño, las agregaciones predeterminadas y los tipos de gráficos. Los hechos capturan el contexto organizacional, como las estructuras de cuentas y las convenciones de asignación de costos. Los resúmenes de Canvas preservan el hilo analítico entre las sesiones para que los usuarios puedan continuar donde lo dejaron sin volver a explicar el contexto. Las sesiones tienen un alcance por lienzo (no por la sesión HTTP efímera), por lo que el contexto de la conversación persiste durante las actualizaciones y reconexiones del navegador.

Para el aislamiento de inquilinos, Amazon Bedrock Guardrails se ejecuta como una verificación previa independiente en el mensaje de usuario sin procesar antes de invocar al agente, lo que aplica políticas de acceso a datos entre inquilinos y detección de ataques rápidos. Luego, una capa de política de inquilinos desinfecta los fragmentos de flujo salientes y los eventos de widgets, redactando los identificadores internos antes de que lleguen al front-end.

Casa del lago de datos

En la capa de datos, Clara ya no depende de API de productos genéricos para el contexto analítico. En su lugar, utiliza herramientas seleccionadas para ejecutar lenguaje de consulta estructurado (SQL) en Databricks SQL Warehouse respaldado por Databricks Lakehouse Metric Views. Esto proporciona una capa semántica gobernada para medidas y dimensiones, mejorando la coherencia entre las respuestas conversacionales y los resultados del panel.

Ejemplo

Vistas de métricas comparadas con SQL sin formato (costo real para el cliente)

El usuario pregunta: "Muestre mi costo real de AWS durante los últimos 30 días por cuenta".

Enfoque del Protocolo de contexto del modelo SQL (MCP) sin formato: la herramienta debe recalcular la lógica empresarial cada vez en varios programas de precios de AWS y descuentos basados ​​en compromisos, luego unir y normalizar esos valores antes de agruparlos por cuenta.

Enfoque de MCP de Vista de métricas: la herramienta consulta una medida predefinida, utilizando comentarios detallados y sinónimos (por ejemplo, costo_verdadero_cliente) con una dimensión (nombre_cuenta) y un rango de tiempo (últimos 30 días).

Resultado: una definición gobernada de costo real para el cliente, una lógica de MCP más simple y resultados consistentes en el chat y los paneles.

Cómo aparece una medida de Vista de métricas en un modelo de lenguaje grande (LLM)

ID: true_customer_cost
Nombre para mostrar: Costo real para el cliente
Comentario: El costo real del gasto de un cliente después de recibir créditos, reembolsos, compromisos y descuentos, como el Programa de descuentos empresariales (EDP) y los acuerdos de precios privados (PPA).

Sinónimos: campos personalizados que se utilizarán para el análisis LLM. Hemos elegido sinónimos para usarlos con pares clave:valor para enviar metadatos adicionales al front-end.

capa de estado

En la capa de estado, Databricks Lakebase (PostgreSQL sin servidor) almacena objetos de productos duraderos, sesiones, lienzos, widgets y especificaciones de consultas/gráficos, de modo que la información generada en el chat se pueda promover en artefactos analíticos persistentes y compartibles.

Flujo de trabajo de análisis

Para flujos de trabajo de análisis de larga duración, introdujimos una ruta de ejecución asincrónica utilizando trabajadores de flujo de trabajo, seguimiento de trabajos de Amazon DynamoDB, notificaciones de Amazon SNS y Amazon SQS y envío de WebSocket de Amazon API Gateway. Luego, Clara puede proporcionar interacciones de usuario receptivas mientras se completa el procesamiento pesado en segundo plano y actualiza la interfaz de usuario en tiempo real.

Resultado

Juntos, estos componentes forman una arquitectura única y administrada donde:

Amazon Bedrock AgentCore ejecuta el tiempo de ejecución y la orquestación del agente. Las vistas de métricas de Databricks Lakehouse impulsan consultas de análisis gobernadas. Lakebase almacena el estado duradero de las aplicaciones y del panel. Los flujos de trabajo asíncronos y WebSockets brindan una experiencia de usuario (UX) escalable en tiempo real.

Resultado

Al reestructurar Clara en torno a Amazon Bedrock AgentCore y un modelo de análisis pionero en Lakehouse, establecimos una base más escalable para flujos de trabajo FinOps impulsados ​​por IA.

Velocidad de desarrollo

Reducción del 75 por ciento en el tiempo de producción, de 10 a 12 meses a 4 meses después de reemplazar una pila autoadministrada de Amazon Elastic Kubernetes Service (Amazon EKS) por un único servicio administrado. Actualmente, entre 4 y 6 agentes listos para producción brindan análisis en un tiempo de ejecución compartido.

Calidad de respuesta

81,7 por ciento de puntuación de corrección (un aumento del 145 por ciento con respecto al período anterior), en comparación con aproximadamente el 65 por ciento en la versión 1. 79,4 por ciento de puntuación de utilidad (un aumento del 138 por ciento respecto al período anterior). La tasa de falla de la herramienta se redujo del 7,49 por ciento al 0,92 por ciento después de adoptar Amazon Bedrock AgentCore con un nuevo método de llamada de herramientas.

Eficiencia operativa

Reducción del tiempo del 75 por ciento para el análisis manual, de aproximadamente 2 horas a 30 minutos para gerentes de éxito del cliente y arquitectos de soluciones. Reducción del esfuerzo manual diario para el éxito del cliente, la arquitectura de soluciones y los equipos ejecutivos de cuentas mediante la transmisión de respuestas y la finalización del flujo de trabajo basado en push.

Simplificación de infraestructura

Se eliminó por completo la capa de orquestación LangGraph/LangChain, se reemplazó por el tiempo de ejecución de AgentCore y la memoria de AgentCore, junto con enrutamiento de solicitudes y observabilidad integrados. Esto liberó a los equipos de ingeniería para centrarse en la diferenciación de productos.

Conclusión

Transformamos a Clara de un asistente de IA centrado en API en capas a un sistema de análisis unificado nativo del agente. Al combinar Amazon Bedrock AgentCore con Databricks Lakehouse Metric Views y Lakebase, creamos un patrón repetible para crear experiencias de análisis de IA empresarial que se mantengan precisas a escala sin una gran sobrecarga operativa.

Para obtener más información sobre cómo crear aplicaciones nativas de agentes, visite la documentación de Amazon Bedrock AgentCore. Para ver cómo utilizamos estas capacidades en producción, visite nops.io.

Sobre los autores