A Serverless RAG Decision Intelligence Agent on AWS

The Business Challenge

A few months ago I led an executive workshop on artificial intelligence how organizations can put it to work to improve productivity and get more from the data they already have. During the session, one of the CIOs asked a question that stayed with me: “Can AI help us make better business decisions?”

A few weeks later we met to talk it through. Her leadership team, she explained, was making strategic decisions every day from information scattered across BI dashboards, Excel reports, CRM and ERP systems, project management tools, and internal documents. The problem was not a lack of data it was turning that data into something they could act on.

Executives were spending hours pulling reports together, comparing trends, and validating numbers before they could decide anything. By the time the analysis was finished, the situation on the ground had often already moved.

So I asked her a simple question: “If you had all of that information in front of you right now, what would you actually want to know?” Her answer came without hesitation:

• Why are sales declining in a specific division?

• Which projects are at risk of missing their targets?

• Where should we invest next quarter?

• What should we do to improve performance?

That conversation sparked the idea. What if executives could ask those questions in plain language and get answers grounded in their own enterprise data the reports, the historical trends, the organizational knowledge they already had instead of navigating dozens of dashboards to assemble the picture themselves?

That is the idea behind a Decision Intelligence Agent: a system that uses generative AI and retrieval-augmented generation (RAG) over enterprise data sources to surface recommendations, flag risks, and highlight opportunities, so leaders can decide faster and with better context. The goal was never to replace human judgment. It was to put the right information in front of decision makers at the right time, with the right context so they could spend their attention on the decision itself, not on hunting for the data behind it.

The Solution

The agent works in two parts. One quietly ingests enterprise data and turns it into searchable knowledge; the other answers questions against that knowledge in natural language. It is a serverless, event driven RAG system, built for the people at the top executives, CIOs, and leadership teams. Behind the chat box, a question becomes a retrieval over the company’s own data, and the answer is generated only from what comes back not from the model’s general training.

Architecture

🟢 Green arrows: User request & AI response flow Show the runtime interaction between the user, API, Lambda, and the AI-generated response returned to the chat UI.

🔵 Blue arrows: Semantic search & retrieval Represent vector search operations between Amazon Bedrock, AWS Lambda, and Amazon OpenSearch Service to retrieve relevant enterprise knowledge.

🟠 Orange arrows: Data ingestion & background processing Show asynchronous workflows, including data ingestion, embedding generation, knowledge base indexing, notifications, and alert processing.

🟣 Purple arrows: Monitoring & logging Represent operational telemetry such as logging, session state, and monitoring data.

Everything runs in us-east-1 as a serverless, event-driven RAG architecture, with Amazon OpenSearch Service placed in a private database subnet inside a VPC so the index of enterprise data is never directly exposed. The design splits cleanly into an ingestion path and a query path.

On the ingestion side, Amazon AppFlow pulls data from enterprise SaaS systems while Amazon Bedrock Knowledge Bases chunks the data into paragraph-sized sections and generates an embedding for each chunk with Amazon Titan on Bedrock, then stores them in Amazon OpenSearch Service for semantic search. This is the “ingested data embedded and stored” path in the diagram. This runs on a schedule driven by CloudWatch Events, so the index stays current as the underlying reports and records change.

On the query side, a user signs in through Amazon Cognito, which creates a session, and their question reaches Amazon API Gateway. The request is forwarded to AWS Lambda, which runs a semantic search over the embeddings in OpenSearch to find the most relevant enterprise data, then passes that retrieved context to Claude on Amazon Bedrock as grounding for the answer. Amazon Bedrock Guardrails check the question before it reaches the model and the answer before it returns, and the response flows back through API Gateway to the chat UI. Session state lives in Amazon DynamoDB, user activity is logged to Amazon CloudWatch, sensitive data is encrypted with AWS KMS, and when the agent surfaces a critical risk it pushes an SMS alert through Amazon SNS.

How It Works: The Flow

Following a single question end to end shows how the two paths meet. An executive asks, in plain language, “why are sales declining in the Western division?” Cognito authenticates them and API Gateway forwards the question to the Lambda orchestrator, where Bedrock Guardrails first check that it is in scope. AWS Lambda invokes Amazon Titan Embeddings on Amazon Bedrock to generate a query embedding and performs a semantic search against OpenSearch to retrieve the most relevant enterprise data, which returns the paragraph-level passages from the company’s reports, trends, and documents most relevant to Western-division sales. Lambda hands that retrieved context to Claude on Bedrock with the original question, and the model composes an answer grounded in those specific passages rather than in general knowledge. AWS Lambda then returns the AI-generated HTTP response to Amazon API Gateway, which securely delivers it back to the client application (web or chat UI). Bedrock Guardrails perform a final validation of the generated response before it is presented to the user. The exchange is stored in DynamoDB so follow-up questions preserve the conversation context, and if the answer contains a flagged risk for example, a project trending toward a missed target Amazon SNS sends an alert without waiting to be asked.

The reason the ingestion pipeline matters is that the quality of every answer depends on what is in the index. Embedding the enterprise data ahead of time is what lets a vague executive question map to the right records in milliseconds; without it, the agent would be guessing.

Architecture Decisions

Each choice was made to keep the build focused, secure, and grounded in the customer’s own data. The main ones:

Why Amazon Bedrock and Claude?

The agent needed a strong foundation model without standing up model infrastructure, and more importantly it had to run inside the customer’s AWS account so enterprise data never left their security boundary. Claude on Amazon Bedrock meets both, and it is straightforward to feed it retrieved context as grounding. Amazon Bedrock Guardrails sit around the model to keep the agent on-topic and filter unsafe input and output which matters when the answers inform business decisions.

Why Amazon OpenSearch Service?

Answers are only as good as the retrieval behind them. OpenSearch stores the embeddings and runs the semantic (vector) search that finds the right enterprise data for a question. Placing it in a private VPC subnet keeps the index of sensitive business data off the public internet.

Why AppFlow and Bedrock Knowledge Bases for ingestion?

Getting data out of CRM, ERP, and other systems is the unglamorous part that makes or breaks a RAG system. AppFlow provides managed connectors so I did not have to hand-build integrations, and Amazon Bedrock Knowledge Bases handles the chunking and embedding as a managed step, so the pipeline stays simple instead of a tangle of ad-hoc scripts.

Why AWS Lambda?

Executive questions are bursty and unpredictable. A serverless orchestrator scales with that pattern and costs nothing between questions, and the retrieve-augment-generate loop is short-lived work that fits Lambda well.

Why Cognito, KMS, and SNS?

Because the agent reaches sensitive business data, identity and encryption were requirements, not extras: Cognito controls who can ask, and KMS encrypts the data and embeddings at rest. SNS turns the agent from purely reactive into something that can warn a leader about a critical risk the moment it surfaces.

Early Results

Two measures mattered most to this leadership team, and both moved. The first is speed: the customer reports that time to decision has dropped by more than 30%, with the routine questions that once meant assembling reports by hand now answered close to twice as fast. The second is visibility: information that used to be scattered across dashboards, spreadsheets, CRM, and ERP is now a plain-language question away, so leaders can see the picture they need without waiting on a reporting cycle. The two reinforce each other — a fast answer only helps if leaders trust they are seeing the whole picture, and broad visibility only helps if they can act on it quickly.

Architecture Vision and Next Steps

This first version answers questions well from documents and reports, but a decision agent has to earn trust, and that shapes where it goes next.

Ground every answer in citations. For executive decisions, a recommendation is only useful if the leader can see what it is based on. The next step is returning the source passages alongside each answer and a confidence signal, so the agent supports judgment rather than asking for blind faith.

Move the orchestration to Amazon Bedrock AgentCore Runtime. Today a single Lambda runs the retrieve-augment-generate loop. Hosting the agent on AgentCore Runtime, with the BI, ERP, and project systems exposed as tools, would let it take multi-step actions pulling a live figure, then explaining it rather than answering from the index alone.

Add short-term and long-term memory. Beyond the session state in DynamoDB, AgentCore Memory would give the agent short-term memory within a conversation and long-term memory across sessions so it remembers an executive’s earlier questions and standing context instead of starting cold each time.

Conclusion

The Decision Intelligence Agent began with a CIO’s question can AI help us make better decisions? and answered it not by adding another dashboard but by letting leaders ask their own data directly. Amazon Bedrock supplies the reasoning, OpenSearch supplies the retrieval, an AppFlow and Knowledge Bases pipeline keeps the knowledge current, and Lambda, API Gateway, Cognito, and the supporting services make it a secure, usable system. The result puts the right context in front of decision makers at the moment they need it, which was the goal all along: less time hunting for data, more time deciding what to do with it.