La creación de agentes de IA listos para producción requiere una planificación y ejecución cuidadosas durante todo el ciclo de vida de desarrollo. La diferencia entre un prototipo que impresiona en una demostración y un agente que ofrece valor en producción se logra mediante prácticas de ingeniería disciplinadas, una arquitectura sólida y una mejora continua.
Esta publicación explora nueve mejores prácticas esenciales para crear agentes de IA empresarial utilizando Amazon Bedrock AgentCore. Amazon Bedrock AgentCore es una plataforma de agencia que brinda los servicios que necesita para crear, implementar y administrar agentes de IA a escala. En esta publicación, cubrimos todo, desde el alcance inicial hasta el escalamiento organizacional, con orientación práctica que puede aplicar de inmediato.
Empiece poco a poco y defina el éxito con claridad
La primera pregunta que debe responder no es "¿qué puede hacer este agente?" sino más bien “¿qué problema estamos resolviendo?” Demasiados equipos comienzan por crear un agente que intenta manejar todos los escenarios posibles. Esto genera complejidad, ciclos de iteración lentos y agentes que no destacan en nada.
En su lugar, trabaje hacia atrás a partir de un caso de uso específico. Si está creando un asistente financiero, comience con las tres tareas de analista más comunes. Si está creando un asistente de recursos humanos, concéntrese en las cinco preguntas principales de los empleados. Haga que estos trabajen de manera confiable antes de ampliar el alcance.
Su planificación inicial debería producir cuatro resultados concretos:
Definición clara de lo que el agente debe y no debe hacer. Escribe esto. Compártelo con las partes interesadas. Úselo para decir no a las funciones desagradables. El tono y la personalidad del agente. Decide si será formal o una conversación, cómo saludará a los usuarios y qué pasará cuando encuentre preguntas fuera de su alcance. Definiciones inequívocas para cada herramienta, parámetro y fuente de conocimiento. Las descripciones vagas hacen que el agente tome decisiones incorrectas. Un conjunto de datos reales de interacciones esperadas que cubren tanto consultas comunes como casos extremos. Definición del agente Tono y personalidad del agente Definición de herramientas Conjunto de datos reales
Agente de análisis financiero: ayuda a los analistas a recuperar datos de ingresos trimestrales, calcular métricas de crecimiento y generar resúmenes ejecutivos para regiones específicas (EMEA, APAC, AMER).
No debe proporcionar asesoramiento de inversión, ejecutar operaciones ni acceder a datos de compensación de empleados.
Profesional pero conversacional. Se dirige a los usuarios por su nombre. Reconoce las limitaciones de datos de forma transparente. Cuando no hay seguridad sobre la calidad de los datos, se indica explícitamente el nivel de confianza. No utiliza jerga financiera sin explicación.
getQuarterlyRevenue(Región: EMEA|APAC|AMER, trimestre: AAAA-QN): devuelve ingresos en millones de dólares.
calcularCrecimiento(valoractual: número, valoranterior: número): devuelve el cambio porcentual.
getMarketData(Región: cadena, tipo de datos: ingresos|ventas|clientes): recupera los indicadores más recientes de la industria.
50 consultas que incluyen: "¿Cuáles son nuestros ingresos del tercer trimestre en EMEA?" "Muéstrame el crecimiento en comparación con el último trimestre" "¿Cómo nos desempeñamos en Asia?" "¿Cuál es el bono del director ejecutivo?" (debe disminuir) “Comparar todas las regiones para 2024”
Asistente de políticas de recursos humanos: responde preguntas de los empleados sobre políticas de vacaciones, solicitudes de licencia, inscripción de beneficios y políticas de la empresa.
No debe acceder a archivos personales confidenciales, brindar asesoramiento legal ni discutir compensaciones individuales o evaluaciones de desempeño.
Amable y solidario. Utiliza el nombre preferido del empleado. Mantiene el profesionalismo siendo accesible. Cuando las políticas son complejas, las divide en pasos claros. Ofrece conectar a los empleados con representantes de recursos humanos para asuntos delicados. checkVacationBalance(employeeId: string): devuelve los días disponibles por tipo.
getPolicy(policyName: string): recupera documentos de políticas de la base de conocimientos.
createHRTicket(employeeId: cadena, categoría: cadena, descripción: cadena): escala problemas complejos.getUpcomingHolidays(año: número, región: cadena): devuelve el calendario de días festivos de la empresa. 45 consultas que incluyen: "¿Cuántos días de vacaciones tengo?" "¿Cuál es la política de licencia parental?" “¿Puedo tomarme un tiempo libre la próxima semana?” "¿Por qué mi bonificación fue menor de lo esperado?" (debe intensificarse) “¿Cómo me inscribo en un seguro médico?”
Agente de soporte de TI: ayuda a los empleados con el restablecimiento de contraseñas, solicitudes de acceso al software, resolución de problemas de VPN y problemas técnicos comunes.
No debe acceder a los sistemas de producción, modificar los permisos de seguridad directamente ni manejar cambios de infraestructura.
Paciente y claro. Evita la jerga técnica. Proporciona instrucciones paso a paso. Confirma la comprensión antes de pasar al siguiente paso. Celebra pequeñas victorias (“¡Genial, funcionó!”). Se escala al equipo de TI cuando los problemas requieren acceso al sistema. resetPassword(userId: string, system: string): inicia el flujo de trabajo de restablecimiento de contraseña.checkVPNStatus(userId: string): verifica la configuración y la conectividad de VPN.
requestSoftwareAccess(userId: cadena, software: cadena, justificación: cadena): crea un ticket de solicitud de acceso.
searchKnowledgeBase(consulta: cadena): recupera artículos de solución de problemas. 40 consultas que incluyen: "No puedo iniciar sesión en mi correo electrónico" "La VPN sigue desconectándose" "Necesito acceso a Salesforce" "¿Pueden darme derechos de administrador?" (debería rechazar), "La computadora portátil no se conecta a Wi-Fi", "¿Cómo instalo Slack?"
Cree una prueba de concepto con este alcance limitado. Pruébalo con usuarios reales. Inmediatamente encontrarán problemas que no anticipaba. Por ejemplo, el agente podría tener dificultades con el análisis de fechas. Es posible que no maneje abreviaturas, que no las maneje bien o que invoque la herramienta incorrecta cuando las preguntas se formulan de manera inesperada. Aprender esto en una prueba de concepto puede costarle un par de semanas, mientras que aprenderlo en producción puede costarle credibilidad y confianza al usuario.
Instrumente todo desde el primer día
Uno de los errores más importantes que pueden cometer los equipos con la observabilidad es tratarla como algo que se puede agregar más adelante. Cuando se da cuenta de que lo necesita, ya ha enviado un agente, lo que puede dificultar la depuración eficaz.
Desde su primera consulta de prueba, necesita visibilidad de lo que está haciendo su agente. Los servicios AgentCore emiten seguimientos de OpenTelemetry automáticamente. Se capturan las invocaciones de modelos, las llamadas a herramientas y los pasos de razonamiento. Cuando una consulta tarda doce segundos, puede ver si el retraso se debe al modelo de lenguaje, una consulta de base de datos o una llamada API externa.
La estrategia de observabilidad debe incluir tres capas:
Habilite la depuración a nivel de seguimiento durante el desarrollo para que pueda ver los pasos de cada conversación. Cuando los usuarios reportan un comportamiento incorrecto, obtenga el seguimiento específico y vea exactamente lo que hizo el agente. Configure paneles para el monitoreo de la producción utilizando los paneles de observabilidad de IA generativa de Amazon CloudWatch que vienen con AgentCore Observability. Realice un seguimiento del uso de tokens, percentiles de latencia, tasas de error y patrones de invocación de herramientas. Exporte los datos a su sistema de observabilidad existente si su organización utiliza Datadog, Dynatrace, LangSmith o Langfuse. La siguiente figura muestra cómo AgentCore Observability le permite profundizar en la información de seguimiento y metadatos de su agente dentro de una invocación de sesión:
La observabilidad satisface diferentes necesidades para diferentes roles. Los desarrolladores lo necesitan para depurar y responder preguntas como por qué el agente tuvo alucinaciones, qué versión del mensaje funciona mejor y de dónde proviene la latencia. Los equipos de plataforma lo necesitan para la gobernanza; necesitan saber cuánto gasta cada equipo, qué agentes generan aumentos de costos y qué sucedió en un incidente en particular. El principio es sencillo: no se puede mejorar lo que no se puede medir. Configure su infraestructura de medición antes de que la necesite.
Construya una estrategia de herramientas deliberada
Las herramientas son la forma en que su agente accede al mundo real. Obtienen datos de bases de datos, llaman a API externas, buscan documentación y ejecutan lógica empresarial. La calidad de las definiciones de sus herramientas afecta directamente el rendimiento de los agentes.
Cuando se define una herramienta, la claridad importa más que la brevedad. Considere estas dos descripciones para la misma función:
Malo: "Obtiene datos de ingresos" Bueno: "Recupera datos de ingresos trimestrales para una región y un período de tiempo específicos.
Devuelve valores en millones de USD. Requiere código de región (EMEA, APAC, AMER)
y trimestre en formato AAAA-QN (por ejemplo, 2024-Q3)."
La primera descripción obliga al agente a adivinar qué entradas son válidas y cómo interpretar las salidas. El segundo ayuda a eliminar la ambigüedad. Cuando multiplicas esto por veinte herramientas, la diferencia se vuelve dramática. Su estrategia de herramientas debe abordar cuatro áreas:
Manejo de errores y resiliencia. Las herramientas fallan. Las API devuelven errores. Los tiempos de espera ocurren. Defina el comportamiento esperado para cada modo de falla, si el agente debe volver a intentarlo, recurrir a los datos almacenados en caché o informar al usuario que el servicio no está disponible. Documente esto junto con la definición de la herramienta. Reutilización a través del Protocolo de contexto modelo (MCP). Muchos proveedores de servicios ya proporcionan servidores MCP para herramientas como Slack, Google Drive, Salesforce y GitHub. Úselos en lugar de crear integraciones personalizadas. Para las API internas, envuélvalas como herramientas MCP a través de AgentCore Gateway. Esto le brinda un protocolo para todas las herramientas y las hace visibles para diferentes agentes. Catálogo de herramientas centralizado. Los equipos no deberían crear el mismo conector de base de datos cinco veces. Mantener un catálogo aprobado de herramientas que hayan sido revisadas por seguridad y probadas en producción. Cuando un nuevo equipo necesita una capacidad, comienza consultando el catálogo. Ejemplos de código con cada herramienta. La documentación por sí sola no es suficiente. Muestre a los desarrolladores cómo integrar cada herramienta con ejemplos de código funcional que puedan copiar y adaptar.
La siguiente tabla muestra qué incluye la documentación de herramientas efectivas:
Elemento Propósito Ejemplo Nombre claro Describe lo que obtiene la herramienta QuarterlyRevenue no
getData Parámetros explícitos Elimina ambigüedad sobre las entradas región: cadena (EMEA|APAC|AMER), trimestre: cadena (AAAA-QN) Formato de devolución Especifica la estructura de salida Devuelve: {ingresos: número, moneda: “USD”, período: cadena} Condiciones de error Documenta los modos de falla Devuelve 404 si no se encuentra el trimestre, 503 si el servicio no está disponible Guía de uso Explica cuándo usar esta herramienta Se usa cuando el usuario pregunta sobre ingresos, ventas o desempeño financiero
Estos estándares de documentación se vuelven aún más valiosos cuando administra herramientas de múltiples fuentes y tipos. El siguiente diagrama ilustra cómo AgentCore Gateway proporciona una interfaz unificada para herramientas de diferentes orígenes: ya sea que estén expuestas a través de instancias de Gateway adicionales (para funciones de análisis y recuperación de datos), AWS Lambda (para capacidades de generación de informes) o Amazon API Gateway (para servicios internos como gestión de proyectos). Si bien este ejemplo muestra una única puerta de enlace para simplificar, muchos equipos implementan varias instancias de puerta de enlace (una por agente o por conjunto de agentes relacionados) para mantener límites y propiedad claros. Gracias a este enfoque modular, los equipos pueden administrar sus propias colecciones de herramientas y al mismo tiempo beneficiarse de patrones consistentes de autenticación, descubrimiento e integración en toda la organización.
AgentCore Gateway ayuda a resolver el problema práctico de la proliferación de herramientas. A medida que crea más agentes en su organización, puede acumular rápidamente docenas de herramientas, algunas expuestas a través de servidores MCP, otras a través de Amazon API Gateway y otras como funciones Lambda. Sin AgentCore Gateway, cada equipo de agentes vuelve a implementar la autenticación, administra puntos finales separados y carga cada definición de herramienta en sus indicaciones, incluso cuando solo unas pocas son relevantes. AgentCore Gateway proporciona un punto de entrada unificado para sus herramientas independientemente de dónde se encuentren. Diríjalo a sus servidores MCP y puertas de enlace API existentes, y los agentes podrán descubrirlos a través de una interfaz. La capacidad de búsqueda semántica se vuelve crítica cuando el número de herramientas aumenta a veinte o treinta: los agentes pueden encontrar la herramienta adecuada en función de lo que intentan lograr en lugar de cargar todo en contexto. También obtiene un manejo de autenticación integral en ambas direcciones: verificar qué agentes pueden acceder a qué herramientas y administrar credenciales para servicios de terceros. Esta es la infraestructura que hace que el catálogo de herramientas centralizado sea práctico a escala.
Automatizar la evaluación desde el principio
Necesita saber si su agente mejora o empeora con cada cambio que realiza. La evaluación automatizada le brinda este circuito de retroalimentación. Comience por definir qué significa "bueno" para su caso de uso específico. Las métricas variarán según la industria y la tarea:
Un agente de servicio al cliente podría medirse por su tasa de resolución y satisfacción del cliente. Un agente analista financiero podría ser evaluado por la precisión de los cálculos y la calidad de las citas. Un asistente de recursos humanos podría ser evaluado por la precisión de las políticas y la integridad de las respuestas.
Equilibre las métricas técnicas con las métricas comerciales. La latencia de respuesta es importante, pero sólo si las respuestas son correctas. El costo del token es importante, pero solo si los usuarios encuentran valioso al agente. Defina ambos tipos de métricas y realice un seguimiento conjunto. Construya su conjunto de datos de evaluación con cuidado. Incluye datos como:
Varias frases de la misma pregunta porque los usuarios no hablan como la documentación API. Casos extremos en los que el agente debería negarse a responder o derivar a un humano. Consultas ambiguas que podrían tener múltiples interpretaciones válidas.
Considere el agente de análisis financiero de nuestro ejemplo anterior. Su conjunto de datos de evaluación debe incluir consultas como "¿Cuáles son nuestros ingresos del tercer trimestre en EMEA?" con una respuesta esperada y la invocación correcta de la herramienta. Pero también debería incluir variaciones: "¿Cuánto ganamos en Europa el último trimestre?", "¿Números del tercer trimestre de EMEA?" y "Muéstrame los ingresos europeos de julio a septiembre". Cada frase debe dar como resultado la misma llamada de herramienta con los mismos parámetros. Sus métricas de evaluación pueden incluir:
Precisión de la selección de herramientas: ¿el agente eligió getQuarterlyRevenue en lugar de getMarketData? Objetivo: 95 % Precisión de extracción de parámetros: ¿Asignó correctamente EMEA y el tercer trimestre de 2024 al formato correcto? Objetivo: 98% Precisión de la negativa: ¿El agente se negó a responder? ¿Cuál es la bonificación del director ejecutivo? Objetivo: 100% Calidad de la respuesta: ¿El agente explicó los datos claramente sin jerga financiera? Evaluado mediante LLM como juez Latencia: P50 en menos de 2 segundos, P95 en menos de 5 segundos Costo por consulta: uso promedio de tokens en menos de 5000 tokens
Ejecute este conjunto de evaluación con su conjunto de datos reales. Antes de su primer cambio, su línea de base podría mostrar una precisión de selección de herramientas del 92 % y una latencia P50 de 3,2 segundos. Después de cambiar de Amazon Claude 4.5 Sonnet a Claude 4.5 Haiku en Amazon Bedrock, puede volver a ejecutar la evaluación y descubrir que la selección de herramientas se redujo al 87 %, pero la latencia mejoró a 1,8 segundos. Esto cuantifica la compensación y le ayuda a decidir si la ganancia de velocidad justifica la pérdida de precisión.
El flujo de trabajo de evaluación debe convertirse en parte de su proceso de desarrollo. ¿Cambiar un mensaje? Ejecute la evaluación. ¿Agregar una nueva herramienta? Ejecute la evaluación. ¿Cambiar a un modelo diferente? Ejecute la evaluación. El ciclo de retroalimentación debe ser lo suficientemente rápido como para detectar los problemas de inmediato, no tres confirmaciones después.
Descomponer la complejidad con sistemas multiagente
Cuando un solo agente intenta manejar demasiadas responsabilidades, resulta difícil de mantener. Las indicaciones se vuelven complejas. La lógica de selección de herramientas tiene problemas. El rendimiento se degrada. La solución es descomponer el problema en múltiples agentes especializados que colaboren. Piense en ello como organizar un equipo. No contrata a una sola persona para que se encargue de las ventas, la ingeniería, el soporte y las finanzas. Contratas especialistas que coordinan su trabajo. El mismo principio se aplica a los agentes. En lugar de que un agente maneje treinta tareas diferentes, cree tres agentes, cada uno de los cuales maneje diez tareas relacionadas, como se muestra en la siguiente figura. Cada agente tiene instrucciones más claras, conjuntos de herramientas más simples y una lógica más enfocada. Cuando se aísla la complejidad, los problemas se vuelven fáciles de depurar y solucionar.
Elegir el patrón de orquestación correcto es importante. Los patrones secuenciales funcionan cuando las tareas tienen un orden natural. El primer agente recupera datos, el segundo los analiza y el tercero genera un informe. Los patrones jerárquicos funcionan cuando se necesita un enrutamiento inteligente. Un agente supervisor determina la intención del usuario y la delega en agentes especializados. Los patrones peer-to-peer funcionan cuando los agentes necesitan colaborar dinámicamente sin un coordinador central.
El desafío clave en los sistemas multiagente es mantener el contexto en todas las transferencias. Cuando un agente pasa trabajo a otro, el segundo agente necesita saber qué ya sucedió. Si un usuario proporcionó su número de cuenta al primer agente, el segundo agente no debería volver a preguntar. AgentCore Memory proporciona un contexto compartido al que varios agentes pueden acceder dentro de una sesión.
Supervise cuidadosamente los traspasos entre agentes. Ahí es donde ocurren la mayoría de los fracasos. ¿Qué agente manejó qué parte de la solicitud? ¿Dónde ocurrieron los retrasos? ¿Dónde se perdió el contexto? AgentCore Observability rastrea todo el flujo de trabajo de un extremo a otro para que pueda diagnosticar estos problemas.
Un punto común de confusión merece aclaración. Los protocolos y los patrones no son lo mismo. Los protocolos definen cómo se comunican los agentes. Son la capa de infraestructura, el formato de conexión, el contrato API. El protocolo Agent2Agent (A2A), MCP y HTTP son protocolos. Los patrones definen cómo los agentes organizan el trabajo. Son la capa de arquitectura, el diseño del flujo de trabajo, la estrategia de coordinación. Secuencial, jerárquico y de igual a igual son patrones.
Puedes utilizar el mismo protocolo con diferentes patrones. Puede utilizar A2A cuando esté creando un canal secuencial o un supervisor jerárquico. Puede utilizar el mismo patrón con diferentes protocolos. Las transferencias secuenciales funcionan a través de MCP, A2A o HTTP. Mantenga estas preocupaciones separadas para no vincular estrechamente su infraestructura con su lógica empresarial.
La siguiente tabla describe las diferencias en capas, ejemplos y preocupaciones entre protocolos y patrones de colaboración multiagente.
Protocolos: cómo hablan los agentes Patrones: cómo organizan los agentes Capa Comunicación e infraestructura Arquitectura y organización Preocupaciones Formato de mensaje, APIS y estándares Flujo de trabajo, rol y coordinación Ejemplos A2A, MCP, HTTP, etc. Secuencial, jerárquico, de igual a igual, etc.
Escale de forma segura con personalización
Pasar de un prototipo que funciona para un desarrollador a un sistema de producción que atiende a miles de usuarios introduce nuevos requisitos en materia de aislamiento, seguridad y personalización.
El aislamiento de la sesión es lo primero. La conversación del usuario A no puede filtrarse a la sesión del usuario B bajo ninguna circunstancia. Cuando dos usuarios hacen preguntas simultáneamente sobre diferentes proyectos, diferentes regiones o diferentes cuentas, esas sesiones deben ser completamente independientes. AgentCore Runtime maneja esto ejecutando cada sesión en su propia micromáquina virtual (microVM) aislada con computación y memoria dedicadas. Cuando finaliza la sesión, la microVM finaliza. No existe ningún estado compartido entre usuarios.
La personalización requiere memoria que persista a lo largo de las sesiones. Los usuarios tienen preferencias sobre cómo les gusta que se presente la información. Trabajan en proyectos específicos que brindan contexto a sus preguntas. Utilizan terminología y abreviaturas específicas de su función. AgentCore Memory proporciona memoria a corto plazo para el historial de conversaciones y memoria a largo plazo para hechos, preferencias e interacciones pasadas. La memoria tiene un espacio de nombres por usuario, por lo que el contexto de cada persona permanece privado. Se debe aplicar el control de seguridad y acceso antes de que se ejecuten las herramientas. Los usuarios sólo deben acceder a los datos para los que tienen permiso de ver. El siguiente diagrama muestra cómo los componentes de AgentCore trabajan juntos para ayudar a imponer la seguridad en múltiples capas.
Cuando un usuario interactúa con su agente, primero se autentica a través de su proveedor de identidad (IdP), ya sea Amazon Cognito, Microsoft Entra ID u Okta. AgentCore Identity recibe el token de autenticación y extrae notificaciones OAuth personalizadas que definen los permisos y atributos del usuario. Estas reclamaciones fluyen a través de AgentCore Runtime hasta el agente y están disponibles durante toda la sesión.
A medida que el agente determina qué herramientas invocar, AgentCore Gateway actúa como punto de cumplimiento. Antes de que se ejecute una herramienta, Gateway intercepta la solicitud y la evalúa en dos capas de políticas. AgentCore Policy valida si este usuario específico tiene permiso para invocar esta herramienta específica con estos parámetros específicos, verificando las políticas de recursos que definen quién puede acceder a qué. Al mismo tiempo, AgentCore Gateway verifica los proveedores de credenciales (como Google Drive, Dropbox o Outlook) para recuperar e inyectar las credenciales necesarias para servicios de terceros. Los interceptores de puerta de enlace proporcionan un enlace adicional donde puede implementar una lógica de autorización personalizada, limitación de velocidad o registro de auditoría antes de que continúe la llamada a la herramienta.
Sólo después de pasar estas comprobaciones se ejecuta la herramienta. Si un analista junior intenta acceder a los datos de remuneración de los ejecutivos, la solicitud se rechaza en AgentCore Gateway antes de que llegue a su base de datos. Si un usuario no ha otorgado el consentimiento de OAuth para su Google Drive, el agente recibe un error claro que puede comunicar al usuario. El flujo de consentimiento del usuario se maneja de forma transparente; Cuando un agente necesita acceso a un proveedor de credenciales por primera vez, el sistema solicita autorización y almacena el token para solicitudes posteriores.
Este enfoque de defensa en profundidad ayuda a garantizar que la seguridad se aplique de manera consistente en todos los agentes y herramientas, independientemente de qué equipo los creó o dónde se alojen las herramientas.
El seguimiento se vuelve más complejo a escala. Con miles de sesiones simultáneas, necesita paneles que muestren patrones agregados y que pueda utilizar para examinar interacciones individuales. AgentCore Observability proporciona métricas en tiempo real entre los usuarios que muestran el uso de tokens, distribuciones de latencia, tasas de error y patrones de invocación de herramientas, como se muestra en las figuras siguientes. Cuando algo falla para un usuario, puede rastrear exactamente lo que sucedió en esa sesión específica, como se muestra en las siguientes figuras.
AgentCore Runtime también aloja herramientas como servidores MCP. Esto ayuda a mantener su arquitectura modular. Los agentes descubren y llaman a herramientas a través de AgentCore Gateway sin un acoplamiento estrecho. Cuando actualiza la implementación de una herramienta, los agentes usan automáticamente la nueva versión sin cambios de código.
Combinar agentes con código determinista
Una de las decisiones arquitectónicas más importantes que tomará es cuándo confiar en el comportamiento de agencia y cuándo usar código tradicional. Los agentes son poderosos pero es posible que no sean apropiados para todas las tareas. Reserve agentes para tareas que requieran razonamiento sobre entradas ambiguas. Comprender consultas en lenguaje natural, determinar qué herramientas invocar e interpretar los resultados en contexto pueden beneficiarse de las capacidades de razonamiento de los modelos básicos. Estas son tareas en las que el código determinista requeriría enumerar miles de casos posibles. Utilice código tradicional para cálculos, validaciones y lógica basada en reglas. El crecimiento de los ingresos es una fórmula. La validación de fechas sigue patrones. Las reglas comerciales son declaraciones condicionales. No necesita un modelo de lenguaje para calcular "restar Q2 de Q3 y dividir por Q2". Escribe una función de Python. Puede ejecutarse en milisegundos sin costo adicional y producir la misma respuesta cada vez.
La arquitectura correcta tiene agentes que organizan funciones de código. Cuando un usuario pregunta: "¿Cuál es nuestro crecimiento en EMEA este trimestre?", el agente utiliza el razonamiento para comprender la intención y determinar qué datos recuperar. Llama a una función determinista para realizar el cálculo. Luego vuelve a utilizar el razonamiento para explicar el resultado en lenguaje natural.
Comparemos la cantidad de invocaciones de modelos de lenguaje grande (LLM), el recuento de tokens y la latencia de dos consultas para "Crear el informe de gastos para el próximo mes". En el primero, get_current_date() se expone como una herramienta agente y en el segundo, la fecha actual se pasa como atributo al agente:
get_current_date() como herramienta Fecha actual pasada como atributo Consulta “Crear el informe de gastos para el próximo mes” “Crear el informe de gastos para el próximo mes” Comportamiento del agente Crea un plan para invocar get_current_date()
Calcula el próximo mes en función del valor de la fecha actual.
Invoca create_report() con el próximo mes como parámetro y crea una respuesta final. Utiliza código para obtener la fecha actual.
Invoca al agente con hoy como atributo
Invoca create_booking() con el mes siguiente (inferido mediante el razonamiento LLM) como parámetro y crea la respuesta final Latencia 12 segundos 9 segundos Número de invocaciones de LLM Cuatro invocaciones Tres invocaciones Total de tokens (entrada + salida) Aproximadamente 8500 tokens Aproximadamente 6200 tokens
La fecha actual es algo que puedes obtener fácilmente usando código. Luego puede pasarlo al contexto de su agente en el momento de la invocación, como atributo. El segundo enfoque es más rápido, menos costoso y más preciso. Multiplique esto por miles de consultas y la diferencia se vuelve sustancial. Mida el costo en comparación con el valor continuamente. Si el código determinista resuelve el problema de manera confiable, utilícelo. Si necesita razonamiento o comprensión del lenguaje natural, utilice un agente. El error común es asumir que todo debe ser agente. La respuesta correcta es agentes más código trabajando juntos.
Establecer prácticas de prueba continuas.
La implementación en producción no es el punto final. Es la línea de salida. Los agentes operan en un entorno en constante cambio. El comportamiento del usuario evoluciona. La lógica empresarial cambia. El comportamiento del modelo puede variar. Necesita pruebas continuas para detectar estos cambios antes de que afecten a los usuarios. Cree un canal de pruebas continuo que se ejecute en cada actualización. Mantenga un conjunto de pruebas con consultas representativas que cubran casos comunes y casos extremos. Cuando cambia un mensaje, agrega una herramienta o cambia de modelo, la canalización ejecuta su conjunto de pruebas y califica los resultados. Si la precisión cae por debajo de su umbral, la implementación falla automáticamente. Esto ayuda a prevenir regresiones. Utilice pruebas A/B para validar cambios en producción. Cuando quiera probar un modelo nuevo o una estrategia de indicación diferente, no cambie a todos los usuarios a la vez. Por ejemplo, enrute el 10% del tráfico a la nueva versión. Compare el rendimiento durante una semana. Mida la precisión, la latencia, el costo y la satisfacción del usuario. Si la nueva versión funciona mejor, impleméntela gradualmente. Si no, revertir. AgentCore Runtime proporciona soporte integrado para control de versiones y división del tráfico. Monitorear la desviación en la producción. Los patrones de usuario cambian con el tiempo. Las preguntas que eran raras se vuelven comunes. Lanzamiento de nuevos productos. Cambios de terminología. Pruebe interacciones en vivo continuamente y califíquelas según sus métricas de calidad. Cuando detecte una desviación, como una caída de la precisión del 92 % al 84 % en dos semanas, investigue y aborde la causa raíz.
AgentCore Assessments simplifica la mecánica de ejecución de estas evaluaciones. Proporciona dos modos de evaluación para adaptarse a diferentes etapas de su ciclo de vida de desarrollo. Las evaluaciones bajo demanda le permiten evaluar el rendimiento del agente frente a un conjunto de datos de prueba predefinido, ejecutar su conjunto de pruebas antes de la implementación, comparar dos versiones de solicitudes en paralelo o validar un cambio de modelo frente a sus ejemplos reales. Las evaluaciones en línea monitorean continuamente el tráfico de producción en vivo, muestreando y calificando interacciones reales de los usuarios para detectar la degradación de la calidad a medida que ocurre. Ambos modos funcionan con marcos populares, incluidos Strands y LangGraph, a través de la instrumentación OpenTelemetry y OpenInference. Cuando su agente se ejecuta, los seguimientos se capturan automáticamente, se convierten a un formato unificado y se califican utilizando técnicas de LLM como juez. Puede utilizar evaluadores integrados para dimensiones de calidad comunes, como utilidad, nocividad y precisión. Para requisitos específicos del dominio, cree evaluadores personalizados con su propia lógica de puntuación. Las figuras siguientes muestran un ejemplo de evaluación de métricas que se muestra en las evaluaciones de AgentCore.
Establecer mecanismos de reversión automatizados. Si las métricas críticas superan los umbrales, vuelva automáticamente a la versión anterior en buen estado. Por ejemplo, si la tasa de alucinaciones supera el 5%, retroceda y alerte al equipo. No espere a que los usuarios informen problemas.
Su estrategia de prueba debe incluir estos elementos:
Pruebas de regresión automatizadas en cada cambio Pruebas A/B para actualizaciones importantes Muestreo y evaluación continuos en producción Detección de deriva con alertas automatizadas Reversiones automatizadas cuando la calidad se degrada
Con los agentes, las pruebas no se detienen porque el entorno no deja de cambiar.
Desarrollar capacidad organizacional
Tu primer agente en producción es un logro. Pero el valor empresarial proviene de ampliar esta capacidad en toda la organización. Eso requiere un pensamiento de plataforma, no sólo un pensamiento de proyecto.
Recopile comentarios de los usuarios y patrones de interacción continuamente. Observe sus paneles de observabilidad para identificar qué consultas tienen éxito, cuáles fallan y qué casos extremos aparecen en producción que no estaban en su conjunto de prueba. Utilice estos datos para ampliar su conjunto de datos reales. Lo que comenzó como cincuenta casos de prueba crece hasta convertirse en cientos basados en interacciones de producción reales.
Configure un equipo de plataforma para establecer estándares y proporcionar infraestructura compartida. El equipo de la plataforma:
Mantiene un catálogo de herramientas aprobadas que han sido examinadas por equipos de seguridad. Proporciona orientación sobre prácticas de observabilidad, evaluación y implementación. Ejecuta paneles centralizados que muestran el rendimiento de todos los agentes. Cuando un nuevo equipo quiere formar un agente.
Cuando un nuevo equipo quiere crear un agente, comienza con el conjunto de herramientas de la plataforma. Cuando los equipos completan la implementación de sus herramientas y/o agentes a producción, pueden contribuir a la plataforma. A escala, el equipo de la plataforma proporciona activos y estándares reutilizables a la organización y los equipos crean sus propios activos mientras contribuyen a respaldar la plataforma con activos validados.
Implementar un seguimiento centralizado entre los agentes de la organización. Un panel muestra los agentes, las sesiones y los costos. Cuando el uso de tokens aumenta inesperadamente, los líderes de la plataforma pueden verlo de inmediato. Pueden revisar por equipo, por agente o por período de tiempo para comprender qué cambió.
Fomente la colaboración entre equipos para que los equipos puedan aprender unos de otros. Tres equipos no deberían crear tres versiones de un conector de base de datos. En cambio, deberían compartir herramientas a través de AgentCore Gateway, compartir estrategias de evaluación y organizar sesiones periódicas donde los equipos demuestren sus agentes y discutan los desafíos. Al hacer esto, surgen problemas comunes y soluciones compartidas.
El patrón de escalamiento organizacional es un proceso de gatear, caminar y correr:
Fase de rastreo. Implemente el primer agente internamente para un pequeño grupo piloto. Centrarse en el aprendizaje y la iteración. Los fracasos son baratos. Fase de marcha. Implemente el agente en un grupo de usuarios externo controlado. Más usuarios, más comentarios, más casos extremos descubiertos. La inversión en observabilidad y evaluación da sus frutos. Fase de ejecución. Escale el agente a usuarios externos con confianza. Las capacidades de la plataforma permiten que otros equipos creen sus propios agentes más rápido. Compuestos de capacidad organizacional.
Así es como puede pasar de un desarrollador que crea un agente a docenas de equipos que crean docenas de agentes con calidad constante, infraestructura compartida y velocidad acelerada.
Conclusión
Crear agentes de IA listos para producción requiere más que conectar un modelo básico a sus API. Requiere prácticas de ingeniería disciplinadas a lo largo de todo el ciclo de vida, que incluyen:
Comience poco a poco con un problema claramente definido Instrumente todo desde el primer día Construya una estrategia de herramientas deliberada Automatice su evaluación Descomponga la complejidad con arquitecturas de múltiples agentes Escale de forma segura con personalización Combine agentes con código determinista Pruebe continuamente Construya capacidad organizacional con pensamiento de plataforma
Amazon Bedrock AgentCore proporciona los servicios que necesita para implementar estas prácticas:
Estas mejores prácticas no son teóricas. Provienen de la experiencia de equipos que crean agentes de producción que manejan cargas de trabajo reales. La diferencia entre agentes que impresionan en demostraciones y agentes que brindan valor comercial se reduce a la ejecución de estos fundamentos.
Para obtener más información, consulte la documentación de Amazon Bedrock AgentCore y comience con nuestros ejemplos de código y talleres prácticos para comenzar y profundizar en AgentCore.
Sobre los autores
Maira Ladeira Tanke es líder tecnológica de IA agente en AWS, donde ayuda a los clientes en su viaje hacia el desarrollo de sistemas de IA autónomos. Con más de 10 años de experiencia en IA/ML, Maira se asocia con clientes empresariales para acelerar la adopción de aplicaciones agentes utilizando Amazon Bedrock AgentCore y Strands Agents, ayudando a las organizaciones a aprovechar el poder de los modelos básicos para impulsar la innovación y la transformación empresarial. En su tiempo libre, Maira disfruta viajar, jugar con su gato y pasar tiempo con su familia en un lugar cálido.
Kosti Vasilakakis es PM principal en AWS en el equipo de Agentic AI, donde ha dirigido el diseño y desarrollo de varios servicios Bedrock AgentCore desde cero, incluidos Runtime, Browser, Code Interpreter e Identity. Anteriormente trabajó en Amazon SageMaker desde sus inicios, lanzando capacidades de IA/ML que ahora utilizan miles de empresas en todo el mundo. Al principio de su carrera, Kosti fue científico de datos. Fuera del trabajo, crea automatizaciones de productividad personal, juega tenis y disfruta de la vida con su esposa e hijos.