Create presentations using Amazon Bedrock AgentCore.

Financial services teams often lose hours each week turning quarterly reports, compliance documents, and market analyses into client-ready PowerPoint decks. That work involves reading hundreds of pages, pulling out key data points, structuring slides, and producing supporting visuals. A new reference solution from AWS shows how to automate the whole workflow with an AI agent system built on Amazon Bedrock AgentCore. In internal testing, the system completed a presentation in under 90 seconds, while keeping generated content grounded in the source documents.

The solution is aimed at developers and enterprise teams who want to connect an agent to their own knowledge base rather than rely on a model's training data alone. It ships with a public repository containing the code assets, so the architecture can be inspected and reused.

What the system actually does

At its center is a single supervisor agent deployed on Amazon Bedrock AgentCore runtime, a capability of Amazon Bedrock AgentCore. The agent is built with the Strands Agents framework, an open source SDK for building AI agents, and it decides whether a user request needs document generation, summarization, or both.

Two tools are exposed to the supervisor:

• generate_pptx creates PowerPoint presentations by calling the PPTX Generator Lambda function, which retrieves content from the knowledge base, builds slide outlines, creates AI images, and assembles the final file.
• generate_summary extracts and synthesizes information from the knowledge base using Retrieval Augmented Generation (RAG) to return grounded answers.

The agent routes each request to the right tool, and new capabilities can be added by defining new tools without touching existing ones. Content creation is handled by Anthropic Claude Sonnet 4.6 on Amazon Bedrock, vector search by Amazon Titan Text Embeddings v2, and slide images by Stability AI Stable Image Inpaint, also available on Amazon Bedrock.

How retrieval keeps output grounded

RAG is the mechanism that ties generated text back to enterprise data. The pipeline starts when documents are uploaded to Amazon Simple Storage Service (Amazon S3). The system chunks and parses them, with special handling for multimodal content such as tables, charts, and images. Amazon Titan Text Embeddings v2 converts each chunk into high-dimensional vectors that capture semantic meaning, and Amazon OpenSearch Serverless stores those vectors as a searchable database.

At query time, the user's request is converted into an embedding and matched against the stored vectors. The most relevant chunks are retrieved and passed to the language model as context, so responses are grounded in the source material. AWS notes this design is intended to help reduce hallucinated content.

One deployment detail is worth flagging: the Amazon OpenSearch Serverless collection data plane must stay publicly accessible, because Amazon Bedrock Knowledge Bases reaches OpenSearch Serverless from AWS-managed infrastructure rather than through customer VPC endpoints. IAM data access policies protect the collection, and VPC-only access restricts the OpenSearch Serverless dashboard.

Guardrails and security controls

Enterprise deployments need content moderation, and Amazon Bedrock Guardrails provides filtering at several points in the pipeline. Input processing screens user requests to help prevent injection issues and inappropriate content. Output generation monitors model responses against content policies. Personally identifiable information (PII) is detected and either anonymized or blocked. The guardrails are created through AWS Cloud Development Kit (AWS CDK) with policies tailored to enterprise document creation, and they apply at the model invocation level, so no manual configuration is needed per deployment.

The architecture routes requests through Amazon API Gateway to a .NET-based Chat API running on AWS Lambda, with conversation state held in Amazon DynamoDB. The supervisor agent then runs on AgentCore runtime. Generated documents land in Amazon S3 and are returned as presigned URLs for secure download.

Additional protections include AWS WAF with managed rule sets and IP-based rate limiting on API Gateway; Amazon Cognito with the Plus feature plan and advanced security mode; Amazon DynamoDB with point-in-time recovery, deletion protection, and customer-managed AWS KMS encryption; Amazon S3 buckets with versioning, server access logging, and block public access; AWS X-Ray tracing on Lambda functions; regex-based validation of tenant and session IDs; and tenant isolation through AWS Security Token Service (AWS STS) role assumption per tenant.

Prerequisites and setup

Before deploying, you need an active AWS account with infrastructure permissions, an AWS CLI configured with credentials, and an IAM role with the right service access policies. On the development side, the solution requires .NET SDK 8 with Amazon.Lambda.Tools installed globally, Python 3.12 or later for AWS CDK and Lambda functions, Node.js and the AWS CDK CLI, and Docker or Finch for building container images with ARM64 support.

You also need model access in Amazon Bedrock for Anthropic Claude Sonnet 4.6, Amazon Titan Text Embeddings v2, and Stability AI Stable Image Inpaint, plus AgentCore access enabled in your account. The API Gateway Regional REST API integration timeout must be set to at least 300 seconds, since the default is 29 seconds. An existing Amazon VPC with private subnets and an Amazon S3 bucket for deployment artifacts are also required.

Setup begins by cloning the repository and creating a `pipeline-params.ini` configuration file at the repository root. That file specifies the environment, container registries, bucket, VPC ID, inference profile IDs, embedding model ID, image generation model ID, and image tags. The `awscliprofile` value can be left empty to use environment variable credentials. AWS CDK then needs to be bootstrapped once per account and Region, which creates the AWS CloudFormation CDKToolkit stack. Finally, three build scripts are made executable.

Build and deploy in three phases

The build phase compiles the .NET Chat API projects and packages them as Lambda deployment packages. It builds the PPTX Generator container image using Docker or Finch, authenticates with Amazon Elastic Container Registry (Amazon ECR), pushes the image, and stores build artifacts in the asset-output directory.

Infrastructure deployment creates four AWS CloudFormation stacks in dependency order:

1. VPCEndpointsStack configures Amazon VPC endpoints for AWS services including Amazon Bedrock AgentCore.
2. OpensearchStack provisions the Amazon OpenSearch Serverless collection for vector storage.
3. AgentCoreStack creates guardrails, Lambda functions, IAM roles, and stores configuration in AWS Systems Manager Parameter Store.
4. ChatApiStack deploys Amazon API Gateway and the Chat API Lambda.

The third phase deploys the supervisor agent to AgentCore runtime. The script builds the agent container for ARM64, pushes it to Amazon ECR, and creates the AgentCore runtime.

What this means for teams evaluating agents

The interesting part of this solution is not the PowerPoint output itself but the pattern behind it: a supervisor agent that routes to specialized tools, a RAG pipeline that keeps generation tied to source documents, and guardrails applied at the model level. Those are the pieces that make an agent usable in a regulated environment, and they are the pieces most teams underestimate when they first try to automate document work.

The 90-second figure comes from AWS internal testing, so real-world performance will depend on document volume, knowledge base size, and Region availability. Anyone planning to adopt the pattern should confirm model availability by Region in Amazon Bedrock and plan for the API Gateway timeout change, which is easy to overlook and will break long-running generation if left at the default.