Building Agentic AI systems with AWS Serverless • Uma Ramadoss • GOTO 2025

Agentic AI systems represent an evolution from AI as a tool to an intelligent participant that can autonomously work towards a goal. This enhances human capability rather than replacing it. The core of an agentic system is its ability to think, act iteratively, and work independently by observing results, adjusting its approach, and continuing until a goal is achieved.

The Power of Context in Overcoming LLM Limitations

Large Language Models (LLMs) have inherent limitations: they are trained on past data, are stateless, and cannot take external actions. The key to overcoming these limitations and enabling agentic behavior is context. The application enriches the context sent to the LLM in several ways:

• System Prompts: Assign a personality or role to the model (e.g., “behave like a French chef”).
• Conversation History: Provide memory of past interactions, making the conversation feel stateful.
• Retrieval-Augmented Generation (RAG): Augment the context with domain-specific data from an internal knowledge corpus, often stored in a vector database.
• Tools: This is the crucial step for agentic AI. APIs for external actions (e.g., a weather API, a location API) are bundled as “tools” and their descriptions, inputs, and outputs are provided in the context.

The agentic loop works as follows:

1. The model receives the user’s goal and the available tools within the context.
2. The model identifies the user’s intent and determines the next step. It may ask for more information or decide to call a specific tool.
3. The agentic system executes the chosen tool (e.g., calls an API).
4. The tool’s output is added back into the context.
5. The enriched context is sent back to the model, which then decides the next step. This process repeats until the model determines the final goal has been reached and it can provide a complete answer.

Agentic AI vs. AI-Enabled Workflows

It’s critical to distinguish between agentic systems and simpler AI-enabled workflows.

• AI-Enabled Workflows: These are deterministic. While they use generative AI, the developer explicitly codes the branching logic and knows every possible step in the workflow. They are reliable, faster, and cheaper.
• Agentic AI Systems: These are non-deterministic and highly autonomous. The LLM decides which tool to use and when the process is complete. The exact number of steps is unknown beforehand.

Guideline: Start simple. If a business use case can be solved with a deterministic AI-enabled workflow, choose that path. Avoid building an overly complex “Rube Goldberg machine” when a simpler solution suffices.

Building Agentic Systems on AWS

Building an agentic system, such as a travel agent, requires three main components: an LLM, tools, and the agent orchestration logic.

1. Large Language Model (LLM): Amazon Bedrock provides a broad choice of foundation models accessible via a simple API, making it a strong choice for the model provider.

2. Tools: Existing business logic, such as APIs for searching, booking, or canceling a flight, can be directly used as tools for the agent.

3. Agent Orchestration: There are two primary approaches to building the agent’s core logic on AWS.

   • AWS Step Functions: A serverless visual workflow service ideal for automating business processes. Its ability to run tasks in a loop perfectly models the iterative nature of an agent. Step Functions provide excellent observability, allowing you to visually track each iteration, including the inputs and outputs. It is highly recommended for AI-enabled workflows and task-based agents that are not highly interactive (e.g., agents running on a schedule).

   • Specialized Agent Frameworks: Open-source SDKs like LangChain, Llama Index, and the AWS-native Strands SDK abstract the complexity of building agents. With Strands SDK, you can build a functional agent with just a few lines of code: import the library, choose a model (from Bedrock or elsewhere), define the agent with its tools, and run it. Strands SDK also provides abstractions for session management (using S3 or DynamoDB) and tool invocation.

Architecture and Deployment

Once the agent logic is written (e.g., using Strands SDK), it can be deployed using various AWS compute services like AWS Lambda, ECS, or EKS. A typical serverless architecture might involve:

• API Gateway: To expose the agent as an endpoint.
• AWS Lambda: To host and run the agent’s code.
• Amazon S3/DynamoDB: For session storage to maintain conversation history.
• Amazon Bedrock: To provide the underlying LLM.

As the system’s complexity grows (e.g., adding hotel and car booking to a travel agent), it’s best to think in terms of a microservices architecture. This promotes extensibility and scalability, whether by adding more tools to a single agent or by creating multiple specialized agents (e.g., a FlightAgent, a CarAgent) that work together.

Final Guideline: Verification

Given that agentic systems are non-deterministic and highly autonomous, their outputs can be unreliable. It is crucial to verify and evaluate the agent’s responses before deploying to production. Techniques like using an “LLM as a judge” can be employed to systematically assess the quality and safety of the agent’s output.

• Tags:
• Agentic AI
• LLM
• Generative AI
• AWS
• Amazon Bedrock
• Serverless
• Step Functions