Amazon Connect Customer now provides a performance dashboard for cases that helps managers monitor case volume, resolution trends, and performance against service level agreement (SLA) targets. Managers can compare current and prior-period performance across metrics such as cases created, average resolution time, first-contact resolution percentage, and SLA achievement rate. They can also analyze trends across dimensions such as case template, assigned user, or assigned queue. For example, a manager can identify that the billing team missed more SLA targets for refund cases than in the prior period, investigate the causes, and prioritize process improvements.
Cases is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (London), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Africa (Cape Town). To learn more and get started, visit the Cases webpage and documentation.
Amazon Connect Customer now provides a performance dashboard for cases that helps managers monitor case volume, resolution trends, and performance against service level agreement (SLA) targets. Managers can compare current and prior-period performance across metrics such as cases created, average resolution time, first-contact resolution percentage, and SLA achievement rate. They can also analyze trends across dimensions such as case template, assigned user, or assigned queue. For example, a manager can identify that the billing team missed more SLA targets for refund cases than in the prior period, investigate the causes, and prioritize process improvements.
Cases is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (London), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Africa (Cape Town). To learn more and get started, visit the Cases webpage and documentation.
Redis’s langcache-embed-v3-small, JetBrains’ Mellum2-12B-A2.5B-Thinking, and LightOn’s LightOnOCR-2-1B models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These three models bring specialized capabilities spanning semantic caching optimization, code-focused reasoning, and end-to-end document OCR, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
langcache-embed-v3-small is optimized for semantic caching in LLM applications. It maps sentences and paragraphs into a dense vector space purpose-built for identifying semantically equivalent queries regardless of phrasing, enabling intelligent cache hits that reduce redundant LLM calls and accelerate response times in high-volume inference workloads.
Mellum2-12B-A2.5B-Thinking excels in code generation, debugging, multi-step reasoning, and agentic coding workflows. It uses a Mixture-of-Experts architecture (64 experts, 8 activated per token), activating only 2.5B of its 12B total parameters per forward pass with a 131,072-token context length. It emits explicit chain-of-thought reasoning traces before final answers, delivering high-throughput, low-latency inference ideal for routing, RAG, sub-agents, and private deployments.
LightOnOCR-2-1B provides end-to-end multilingual document-to-text conversion for PDFs, scans, and images without brittle OCR pipelines. This 1B-parameter vision-language model directly transduces page images into clean, naturally ordered text, achieving state-of-the-art performance on OlmOCR-Bench while being ~9× smaller and significantly faster than competing approaches.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Redis’s langcache-embed-v3-small, JetBrains’ Mellum2-12B-A2.5B-Thinking, and LightOn’s LightOnOCR-2-1B models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These three models bring specialized capabilities spanning semantic caching optimization, code-focused reasoning, and end-to-end document OCR, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
langcache-embed-v3-small is optimized for semantic caching in LLM applications. It maps sentences and paragraphs into a dense vector space purpose-built for identifying semantically equivalent queries regardless of phrasing, enabling intelligent cache hits that reduce redundant LLM calls and accelerate response times in high-volume inference workloads.
Mellum2-12B-A2.5B-Thinking excels in code generation, debugging, multi-step reasoning, and agentic coding workflows. It uses a Mixture-of-Experts architecture (64 experts, 8 activated per token), activating only 2.5B of its 12B total parameters per forward pass with a 131,072-token context length. It emits explicit chain-of-thought reasoning traces before final answers, delivering high-throughput, low-latency inference ideal for routing, RAG, sub-agents, and private deployments.
LightOnOCR-2-1B provides end-to-end multilingual document-to-text conversion for PDFs, scans, and images without brittle OCR pipelines. This 1B-parameter vision-language model directly transduces page images into clean, naturally ordered text, achieving state-of-the-art performance on OlmOCR-Bench while being ~9× smaller and significantly faster than competing approaches.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases. To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Z.ai’s GLM-5.2 FP8, NVIDIA’s Nemotron-Nano-12B-v2, and Z.ai’s GLM-OCR models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These three models bring specialized capabilities spanning long-horizon agentic engineering, efficient hybrid reasoning, and advanced document understanding, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
GLM-5.2 FP8 is optimized for long-horizon tasks and agentic engineering workflows such as full-cycle software development from requirements to deployment. It delivers a substantial leap in long-horizon task capability over its predecessor GLM-5.1 and, for the first time, provides a truly usable 1M-token context window, enabling it to handle project-level engineering context, execute long-running tasks reliably, follow engineering standards consistently, and complete full development workflows in a single task.
NVIDIA-Nemotron-Nano-12B-v2 excels in unified reasoning and non-reasoning tasks with high inference throughput, making it ideal for enterprise applications requiring both accuracy and efficiency. It uses a hybrid Mamba-2 and Transformer architecture with a 128K context length, generating reasoning traces before concluding with final responses. Its compact 12B parameter design achieves comparable or better accuracy than leading open models while delivering up to 6x higher inference throughput.
GLM-OCR provides accurate, fast, and comprehensive document understanding for complex real-world materials including scanned PDFs, handwritten notes, dense academic papers with formulas, multi-column tables, code documentation, and multilingual text. This 0.9B-parameter multimodal model reconstructs structure, tables, and formulas into clean Markdown, JSON, or LaTeX, with latency low enough for real-time services and edge devices—ideal for large-scale document processing and invoice extraction workflows.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Z.ai’s GLM-5.2 FP8, NVIDIA’s Nemotron-Nano-12B-v2, and Z.ai’s GLM-OCR models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These three models bring specialized capabilities spanning long-horizon agentic engineering, efficient hybrid reasoning, and advanced document understanding, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
GLM-5.2 FP8 is optimized for long-horizon tasks and agentic engineering workflows such as full-cycle software development from requirements to deployment. It delivers a substantial leap in long-horizon task capability over its predecessor GLM-5.1 and, for the first time, provides a truly usable 1M-token context window, enabling it to handle project-level engineering context, execute long-running tasks reliably, follow engineering standards consistently, and complete full development workflows in a single task.
NVIDIA-Nemotron-Nano-12B-v2 excels in unified reasoning and non-reasoning tasks with high inference throughput, making it ideal for enterprise applications requiring both accuracy and efficiency. It uses a hybrid Mamba-2 and Transformer architecture with a 128K context length, generating reasoning traces before concluding with final responses. Its compact 12B parameter design achieves comparable or better accuracy than leading open models while delivering up to 6x higher inference throughput.
GLM-OCR provides accurate, fast, and comprehensive document understanding for complex real-world materials including scanned PDFs, handwritten notes, dense academic papers with formulas, multi-column tables, code documentation, and multilingual text. This 0.9B-parameter multimodal model reconstructs structure, tables, and formulas into clean Markdown, JSON, or LaTeX, with latency low enough for real-time services and edge devices—ideal for large-scale document processing and invoice extraction workflows.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Black Forest Labs’ FLUX.2-small-decoder and Google’s gemma-4-12B-it models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These two models bring specialized capabilities spanning efficient image generation decoding and unified multimodal understanding, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
FLUX.2-small-decoder is optimized for faster image decoding with lower VRAM usage in FLUX.2 image generation pipelines. It is a distilled VAE decoder that serves as a drop-in replacement for the standard FLUX.2 decoder, delivering approximately 1.4× faster decoding speed at 1.4× lower VRAM consumption with minimal to zero quality loss. Benefits increase at higher resolutions where the decoder processes more pixels, making it ideal for production-grade image generation workloads at scale.
gemma-4-12B-it excels in unified multimodal understanding across text, image, and audio inputs with native support for function calling and agentic workflows. It features an encoder-free architecture where all modalities flow directly into a single decoder-only transformer, delivering performance nearing Google’s larger 26B MoE model at less than half the memory footprint. Compact enough to run on 16GB of RAM, it enables powerful multimodal and agentic experiences for enterprise deployments.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Black Forest Labs’ FLUX.2-small-decoder and Google’s gemma-4-12B-it models are now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. These two models bring specialized capabilities spanning efficient image generation decoding and unified multimodal understanding, enabling customers to deploy high-performance, scalable AI solutions on AWS infrastructure.
FLUX.2-small-decoder is optimized for faster image decoding with lower VRAM usage in FLUX.2 image generation pipelines. It is a distilled VAE decoder that serves as a drop-in replacement for the standard FLUX.2 decoder, delivering approximately 1.4× faster decoding speed at 1.4× lower VRAM consumption with minimal to zero quality loss. Benefits increase at higher resolutions where the decoder processes more pixels, making it ideal for production-grade image generation workloads at scale.
gemma-4-12B-it excels in unified multimodal understanding across text, image, and audio inputs with native support for function calling and agentic workflows. It features an encoder-free architecture where all modalities flow directly into a single decoder-only transformer, delivering performance nearing Google’s larger 26B MoE model at less than half the memory footprint. Compact enough to run on 16GB of RAM, it enables powerful multimodal and agentic experiences for enterprise deployments.
With SageMaker JumpStart, customers can deploy any of these models with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Amazon EC2 High Memory U7in-24TB instances (u7in-24tb.224xlarge) are now available in AWS South America (São Paulo) region. U7i instances are part of the AWS 7th generation and are powered by custom fourth-generation Intel Xeon Scalable processors (Sapphire Rapids). U7in-24TB instances offer 24 TiB of DDR5 memory, enabling customers to scale transaction processing throughput in a fast-growing data environment.
U7in-24TB instances deliver 896 vCPUs and support up to 100 Gbps of Amazon EBS bandwidth for faster data loading and backups, 200 Gbps of network bandwidth, and ENA Express. U7i instances are ideal for customers running mission-critical in-memory databases like SAP HANA, Oracle, and SQL Server.
Amazon EC2 High Memory U7in-24TB instances (u7in-24tb.224xlarge) are now available in AWS South America (São Paulo) region. U7i instances are part of the AWS 7th generation and are powered by custom fourth-generation Intel Xeon Scalable processors (Sapphire Rapids). U7in-24TB instances offer 24 TiB of DDR5 memory, enabling customers to scale transaction processing throughput in a fast-growing data environment.
U7in-24TB instances deliver 896 vCPUs and support up to 100 Gbps of Amazon EBS bandwidth for faster data loading and backups, 200 Gbps of network bandwidth, and ENA Express. U7i instances are ideal for customers running mission-critical in-memory databases like SAP HANA, Oracle, and SQL Server.
To learn more about U7i instances, visit the High Memory instances page.
Amazon GameLift Streams now manages shader cache capture and distribution for your applications. You capture a shader cache from a stream session, and the service automatically makes it available for future sessions across your streaming locations. No application changes are required.
Capturing shader caches can help reduce loading times and visual stuttering, during the session. With service-managed shader caching, you designate a stream session for capture and run your application to generate the cache. Amazon GameLift Streams then replicates the cache to compatible stream groups and locations, and loads it automatically in future sessions.
You can monitor shader cache status and storage size using the ListApplicationShaderCaches API or the Amazon GameLift Streams console. The feature supports Linux (Ubuntu 22.04), Proton, and Windows Server 2022 runtimes.
Amazon GameLift Streams now manages shader cache capture and distribution for your applications. You capture a shader cache from a stream session, and the service automatically makes it available for future sessions across your streaming locations. No application changes are required. Capturing shader caches can help reduce loading times and visual stuttering, during the session. With service-managed shader caching, you designate a stream session for capture and run your application to generate the cache. Amazon GameLift Streams then replicates the cache to compatible stream groups and locations, and loads it automatically in future sessions. You can monitor shader cache status and storage size using the ListApplicationShaderCaches API or the Amazon GameLift Streams console. The feature supports Linux (Ubuntu 22.04), Proton, and Windows Server 2022 runtimes. You are charged for storage of the latest version of each shader cache. For pricing details, visit the Amazon GameLift Streams pricing page. For supported Regions, see the AWS Region table.
Amazon EC2 introduces application status checks, a new status check that helps customers detect and respond to application-level issues on their EC2 instances. With application status checks, EC2 monitors applications to detect issues such as a web server that has stopped accepting requests, a Docker daemon that is not running, an incorrect networking configuration, or a network interface that is no longer passing traffic.
Customers rely on EC2 status checks today to receive alerts when an instance or the underlying system is unreachable. However, to monitor application issues, customers had to build and maintain their own monitoring solution. Now, with application status checks customers can monitor the status of their applications running on EC2 instances alongside existing EC2 instance and system status checks. Customers create a check by specifying the protocol, port, and path to monitor, along with the response codes that indicate a healthy application. After customers associate the check with their instances by instance ID or tag, Amazon EC2 sends HTTP or HTTPS requests to that port and path and reports on the application’s status every 60 seconds. Auto Scaling groups act on application status, initiating recovery by replacing instances when their applications report unhealthy.
Application status checks are available in all commercial AWS Regions and AWS GovCloud (US) Regions.
To get started with application status checks and review pricing, see the Amazon EC2 User Guide.
Amazon EC2 introduces application status checks, a new status check that helps customers detect and respond to application-level issues on their EC2 instances. With application status checks, EC2 monitors applications to detect issues such as a web server that has stopped accepting requests, a Docker daemon that is not running, an incorrect networking configuration, or a network interface that is no longer passing traffic.
Customers rely on EC2 status checks today to receive alerts when an instance or the underlying system is unreachable. However, to monitor application issues, customers had to build and maintain their own monitoring solution. Now, with application status checks customers can monitor the status of their applications running on EC2 instances alongside existing EC2 instance and system status checks. Customers create a check by specifying the protocol, port, and path to monitor, along with the response codes that indicate a healthy application. After customers associate the check with their instances by instance ID or tag, Amazon EC2 sends HTTP or HTTPS requests to that port and path and reports on the application’s status every 60 seconds. Auto Scaling groups act on application status, initiating recovery by replacing instances when their applications report unhealthy.
Application status checks are available in all commercial AWS Regions and AWS GovCloud (US) Regions.
To get started with application status checks and review pricing, see the Amazon EC2 User Guide.
The next generation of Amazon OpenSearch Serverless now supports up to 10,000 collections within a single collection group, increased from the previous limit of 1,500. Collection groups organize multiple collections and enable them to share OpenSearch Compute Units (OCUs), even when the collections are encrypted with different AWS KMS keys. With this higher limit, you can consolidate significantly more collections into a single collection group and manage them under a shared set of capacity limits.
Customers use collection groups to reduce costs by sharing compute across many collections rather than provisioning separate OCUs for each KMS key, while still maintaining collection-level security and access controls. As customer workloads have grown, particularly for multi-tenant applications that provision a collection per tenant, the previous limit of 1,500 collections per group constrained how many tenants could benefit from a shared compute pool. Raising the limit to 10,000 collections on the next generation of Amazon OpenSearch Serverless lets you scale these workloads further, improve compute utilization, and lower per-collection cost, without creating and operating additional collection groups. The higher limit applies automatically to new and existing nextgen collection groups.
The increased limit is available on the next generation of Amazon OpenSearch Serverless in all AWS Regions where it is available. To learn more, see Amazon OpenSearch Serverless technical documentation and quotas.
The next generation of Amazon OpenSearch Serverless now supports up to 10,000 collections within a single collection group, increased from the previous limit of 1,500. Collection groups organize multiple collections and enable them to share OpenSearch Compute Units (OCUs), even when the collections are encrypted with different AWS KMS keys. With this higher limit, you can consolidate significantly more collections into a single collection group and manage them under a shared set of capacity limits.
Customers use collection groups to reduce costs by sharing compute across many collections rather than provisioning separate OCUs for each KMS key, while still maintaining collection-level security and access controls. As customer workloads have grown, particularly for multi-tenant applications that provision a collection per tenant, the previous limit of 1,500 collections per group constrained how many tenants could benefit from a shared compute pool. Raising the limit to 10,000 collections on the next generation of Amazon OpenSearch Serverless lets you scale these workloads further, improve compute utilization, and lower per-collection cost, without creating and operating additional collection groups. The higher limit applies automatically to new and existing nextgen collection groups.
The increased limit is available on the next generation of Amazon OpenSearch Serverless in all AWS Regions where it is available. To learn more, see Amazon OpenSearch Serverless technical documentation and quotas.
Cómo construir un agente de IA: una guía sencilla para cualquiera
Imaginen a un oficinista que hace clic en un enlace de phishing a las 2:13 de la madrugada. Mientras el equipo de TI duerme, un agente de IA detecta comportamientos de inicio de sesión inusuales y desactiva la cuenta comprometida. Luego, comprueba si el malware se ha propagado a otros dispositivos o cuentas, abre un ticket, envía una alerta al equipo de seguridad y redacta un resumen del incidente.
Esta es la belleza de los agentes de IA. Pueden ayudar a los trabajadores de todo tipo de puestos a realizar una variedad de tareas, como controlar los plazos de los proyectos, supervisar las bandejas de entrada compartidas, crear informes nocturnos y más. Lo que las diferencia de las aplicaciones de chat con IA es que, aunque las aplicaciones de chat destacan en responder preguntas, los agentes también pueden actuar.
Pueden pensar en los agentes como aplicaciones para un mundo impulsado por IA. Empezar es más fácil de lo que parece. Esta guía repasa los pasos clave — desde definir el problema hasta construir y compartir un agente por medio de Microsoft 365 Copilot — para que puedan pasar de la idea al prototipo funcional sin necesidad de escribir código.
Si tienen Microsoft 365 Copilot, vayan al Microsoft 365 Copilot Chat, hagan clic en «Agentes» y luego en «Nuevo agente» para empezar a construir de inmediato.
Empiecen por el trabajo, no por la tecnología. ¿Qué problema intentan resolver? Hablen con sus compañeros para aclarar la necesidad y reducir el alcance. Luego definan el resultado: ¿Debe el agente recuperar información, completar una tarea o actuar de manera independiente? Un objetivo claro desde el principio hace que el resto del proceso de construcción sea más rápido — y mucho más útil.
Ejemplo: Un grupo de trabajadores de oficina dedica horas cada semana a elaborar un informe de estado a partir de sus correos electrónicos, mensajes y documentos. Es repetitivo y fácil pasar por alto detalles, y el informe final varía mucho según quién lo elabore. Un agente de IA podría resolver eso al hacer el trabajo de campo de leer los condominios de internet del equipo y preparar el primer borrador en minutos.
2. Decidan por dónde empezar
Antes de construir, comprueben qué ya existe. Un modelo de IA o un agente preconstruido puede que ya haga el trabajo. Para comprobarlo, abran Microsoft 365 Copilot y hagan clic en «Agentes» en el panel izquierdo para abrir un almacén de agentes preconfigurados. Si no encuentran lo que buscan, tengan en cuenta su nivel de experiencia. Con poca o ninguna experiencia en programación, Microsoft 365 Copilot está diseñado para ayudarlos a empezar de manera rápida. Las construcciones más avanzadas pueden requerir herramientas de desarrollo para mayor personalización y control.
Ejemplo: Para un equipo que trabaja en conjunto para responder a los correos de los clientes desde una bandeja de entrada compartida, un agente podría ayudar a clasificar los mensajes entrantes, elegir cuáles son más importantes, escribir respuestas a preguntas comunes y encaminar mensajes a la persona adecuada.
3. Construyan su agente de IA en Microsoft 365 Copilot
Desde la sección de Agentes en Microsoft 365 Copilot, hagan clic en «Nuevo Agente.» Empiecen con describir lo que quieren en lenguaje sencillo: su copiloto generará un borrador de su agente por ustedes.
Una vez que Copilot haya creado su agente, pueden probarlo con un clic en «configurar». Luego refinen las instrucciones: definan el comportamiento, el tono y las tareas del agente. Este paso es donde ustedes moldean cómo responde el agente, asegurándose de que sea consistente, útil y alineado con su flujo de trabajo específico.
Ejemplo: El equipo que responde a correos en una bandeja de entrada compartida podría dar a su agente todo tipo de indicaciones. Un miembro del equipo podría decirle que categorizara los tipos de solicitudes comunes como preguntas generales, asuntos urgentes o solicitudes complejas, y que enrutara cada tipo de mensaje a un miembro específico del equipo. El equipo podría formar al agente para que utilice ciertos términos aprobados para responder a preguntas rutinarias de inmediato y para señalar cualquier cosa sensible ante un revisor humano.
4. Añadir conocimiento y definir salidas
Para que su agente haga lo mejor de sí requiere que le den un poco de contexto.
Conecten a su agente con las fuentes de información adecuadas, como correos electrónicos, documentos, sitios de SharePoint o páginas web. Decidan si debe basarse sólo en sus datos seleccionados o recurrir a fuentes más amplias, como una página web o un PDF con las políticas de tu empresa. Luego definan qué produce — informes, presentaciones, hojas de cálculo, respuestas o código — para que entregue el trabajo en el formato que en verdad necesitan.
Pueden tan solo adjuntar documentos a su agente por ustedes mismos o usar el chatbot. Para ello, naveguen a la página del Constructor de Agentes en su Microsoft 365 Copilot y hagan clic en el icono del lápiz a la derecha del nombre de su agente para abrir la pantalla de edición. Desde ahí, pueden desplazarse hacia abajo para adjuntar fuentes de información o usar la ventana de chat a la izquierda para guiarse.
Ejemplo: El equipo que elabora un informe semanal podría decirle al agente que «revise los mensajes y correos electrónicos de Teams de los últimos siete días» y que «se centre solo en mensajes relacionados con un proyecto o equipo específico», o que «identifique actualizaciones, decisiones, bloqueos o fechas límite próximas».
Una vez hecho esto, el equipo puede decirle al agente justo cómo quiere que se estructure el informe y cuánto debe tener, y que redacte todo con un tono claro y profesional. El equipo también puede establecer límites con el agente y decirle que solo use información de correos electrónicos y mensajes de Teams — y que no insinúe ningún detalle faltante.
5. Probar, compartir y escalar
Prueben a su agente en escenarios reales y refinen sus instrucciones para volver a la configuración según sea necesario. Desde la pantalla de edición dentro de la página del Constructor de Agentes, pueden cambiar por ustedes mismos las instrucciones del agente, o Copilot puede guiarlos en los cambios de la izquierda en una ventana de chat.
Ejemplo: El equipo con el informe semanal puede darse cuenta de que su agente recibe actualizaciones poco claras o contradictorias de los correos electrónicos del equipo, por lo que un miembro del equipo indica al agente que las marque — y que no infiera ni adivine detalles faltantes.
O el equipo puede darse cuenta de que el recuento inicial de palabras para el informe era demasiado largo, por lo que un miembro del equipo ajusta las indicaciones del agente para hacerlo más corto y fácil de ojear, o para incluir puntos clave en una lista con viñetas.
Una vez que su agente esté operativo, pueden ampliar sus capacidades o trasladarlo a herramientas más avanzadas. El objetivo no es la perfección de inmediato, sino construir algo útil para su trabajo y seguir perfeccionándolo con el tiempo.
Todas las imágenes realizadas con MAI Playground y Microsoft 365 Copilot.
AWS Elastic Disaster Recovery (AWS DRS) now preserves UEFI boot mode when recovering Linux source servers that boot with UEFI firmware. Previously, DRS launched these Linux servers in legacy BIOS mode, which could require extra configuration after recovery. Now your recovered Linux instances launch with the same UEFI boot mode as your source servers. This means your recovery instances more closely match your source environment, so applications that depend on UEFI boot behavior come back exactly as you expect — with no additional post-recovery steps. Boot mode preservation is automatic, with nothing to configure.
This capability is available in all AWS Regions where AWS DRS is offered, at no additional cost. To learn more, visit the AWS Elastic Disaster Recovery User Guide.
AWS Elastic Disaster Recovery (AWS DRS) now preserves UEFI boot mode when recovering Linux source servers that boot with UEFI firmware. Previously, DRS launched these Linux servers in legacy BIOS mode, which could require extra configuration after recovery. Now your recovered Linux instances launch with the same UEFI boot mode as your source servers. This means your recovery instances more closely match your source environment, so applications that depend on UEFI boot behavior come back exactly as you expect — with no additional post-recovery steps. Boot mode preservation is automatic, with nothing to configure.
This capability is available in all AWS Regions where AWS DRS is offered, at no additional cost. To learn more, visit the AWS Elastic Disaster Recovery User Guide.
