AWS Builder Center

Builder Center

I Gave an AI Agent a Job: Building a Study Buddy with Amazon Bedrock

What if an AI assistant did more than answer questions? In this project, I built a serverless study buddy that creates learning plans, answers questions from personal notes, generates quizzes, and tracks progress using Amazon Bedrock, AWS Lambda, Amazon DynamoDB, Amazon S3, and Amazon OpenSearch Serverless.

Introduction

I have used plenty of AI chat tools that can explain a topic, summarize an article, or answer a question.
That part is no longer especially surprising.
The more interesting question is what happens when an AI assistant is given a real job to do.
For my first project, I wanted to build something practical: an AI study buddy that could help someone learn a topic from beginning to end. It should create a plan, explain difficult concepts, use the learner’s own notes, generate quizzes, remember progress, and suggest what to study next.
The result is a serverless learning assistant built with Amazon Bedrock and several AWS managed services.
This article walks through the idea, architecture, implementation approach, and lessons I learned while building it.

The idea

The initial concept was simple:
Give the application a learning goal, and let it help the user reach it.
For example, a user might enter:
1
I want to learn AWS Lambda in seven days.
Instead of returning one long explanation, the application creates a structured learning plan containing:
  • Daily topics.
  • Learning objectives.
  • Short explanations.
  • Practice questions.
  • Review recommendations.
  • Progress tracking.
The assistant can also use the learner’s own material. A user can upload notes or reference documents and then ask questions based on those documents.
The goal was not to create an assistant that talks about everything. It was to create one that performs a small number of useful tasks reliably.

What the application does

The study buddy supports four main workflows.

Create a learning plan

The user provides a topic and a target duration. The assistant creates a day-by-day plan.
For example:
1
2
3
Topic: Amazon DynamoDB
Duration: 5 days
Experience: Beginner
The generated plan might include DynamoDB fundamentals on day one, keys and access patterns on day two, indexes on day three, application integration on day four, and a final review on day five.

Answer questions

The user can ask questions in a conversational interface.
1
Why should I design my DynamoDB access patterns before creating the table?
The assistant gives an explanation appropriate to the learner’s level and can include a small example.

Generate quizzes

After completing a lesson, the user can request a short quiz. The application stores the result and uses it to identify topics that may need more attention.

Track progress

The assistant remembers completed topics, quiz results, and areas where the learner struggled. This allows it to make a more useful recommendation than simply returning another generic answer.

Architecture

The application uses managed AWS services so there is no server infrastructure to provision or maintain.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
User
|
v
Web application
|
v
Amazon API Gateway
|
v
AWS Lambda
|
+--> Amazon Bedrock
+--> Amazon DynamoDB
+--> Amazon S3
+--> Amazon OpenSearch Serverless
+--> Amazon EventBridge
The main services have the following responsibilities:
  • Amazon Bedrock generates study plans, explanations, quizzes, and recommendations.
  • AWS Lambda contains the application logic.
  • Amazon API Gateway exposes the backend APIs.
  • Amazon DynamoDB stores users, plans, progress, and quiz results.
  • Amazon S3 stores uploaded learning material.
  • Amazon OpenSearch Serverless supports semantic search over uploaded documents.
  • Amazon EventBridge can trigger background tasks such as reminders or progress analysis.
Amazon Bedrock Agents can also use action groups backed by Lambda functions. This makes it possible for an agent to interpret a request, select an appropriate action, and call application code rather than only generating text.docs.aws.amazon 

Creating a learning plan

When a user submits a learning goal, the request follows this path:
  1. The web application sends the goal to API Gateway.
  2. API Gateway invokes a Lambda function.
  3. Lambda validates the request.
  4. Lambda sends the request to Amazon Bedrock.
  5. Bedrock generates a structured learning plan.
  6. Lambda validates the response.
  7. The plan is stored in DynamoDB.
  8. The application returns the plan to the user.
The model receives information such as:
  • The subject.
  • The learner’s experience level.
  • The number of available days.
  • The preferred learning style.
  • Any known constraints.
A simplified request might look like this:
1
2
3
4
5
6
{
"topic": "AWS Lambda",
"duration_days": 7,
"experience_level": "beginner",
"goal": "Build and deploy a simple serverless API"
}
The application then asks the model to return a plan that the frontend can render.

Keeping the output usable

One of the first problems I ran into was inconsistent model output.
A human can understand a response such as:
1
Here is a useful plan for learning Lambda...
An application needs predictable fields.
The expected response therefore looks more like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"title": "AWS Lambda in Seven Days",
"duration_days": 7,
"days": [
{
"day": 1,
"topic": "Lambda fundamentals",
"objectives": [
"Understand event-driven execution",
"Create a basic Lambda function"
],
"quiz_questions": 3
}
]
}
The Lambda function checks that required fields exist before saving the result.
Amazon Bedrock now supports structured outputs that constrain model responses to a user-defined JSON schema. This can reduce the amount of custom parsing and validation required by the application.docs.aws.amazon 
Even with structured output, I would still keep application-level validation. A valid JSON response can still contain an empty title, an invalid duration, or content that does not make sense for the user.
That was an important lesson for me:
A model can produce the language, but the application still owns the rules.

Adding personal notes

The study buddy becomes much more useful when it can work with the learner’s own material.
A user might upload:
  • AWS documentation.
  • Class notes.
  • Markdown files.
  • Internal training material.
  • PDF study guides.
The documents are stored in Amazon S3. A processing workflow extracts the text, divides it into smaller sections, creates embeddings, and stores the searchable content in Amazon OpenSearch Serverless.
When the user asks a question, the application performs a retrieval-augmented generation workflow:
1
2
3
4
5
1. Receive the question.
2. Search for relevant document sections.
3. Send the question and retrieved context to Amazon Bedrock.
4. Generate an answer using that context.
5. Return the answer with supporting references.
This approach gives the assistant access to the learner’s specific material instead of relying only on general model knowledge.
For example, if a user uploads internal notes about a company’s deployment process, the assistant can answer questions about those notes without requiring the information to be included in every prompt.

Giving the assistant tools

The biggest difference between a chatbot and an agent is the ability to take controlled actions.
For this application, the assistant can request actions such as:
  • Create a study plan.
  • Retrieve the user’s progress.
  • Generate a quiz.
  • Save a quiz result.
  • Recommend a review topic.
  • Search the user’s uploaded documents.
Each action is implemented as an application function. The model does not receive unrestricted access to the AWS account.
A simplified progress function might look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import boto3
from boto3.dynamodb.conditions import Key

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("study-progress")

def get_progress(user_id):
response = table.query(
KeyConditionExpression=Key("user_id").eq(user_id)
)

return {
"user_id": user_id,
"completed_topics": response.get("Items", [])
}
The assistant can decide that it needs the user’s progress, but the Lambda function controls how that data is retrieved.
This distinction matters. The model can suggest an action, but the application decides whether the action is valid, authorized, and safe.

Tracking progress with DynamoDB

I used DynamoDB to store the application’s operational data.
A progress record might contain:
1
2
3
4
5
6
7
8
{
"user_id": "user-123",
"plan_id": "plan-456",
"topic": "Lambda fundamentals",
"status": "completed",
"quiz_score": 80,
"last_updated": "2026-09-25T00:00:00Z"
}
The application can use these records to answer questions such as:
  • Which lessons has the user completed?
  • Which topics have low quiz scores?
  • When did the user last study?
  • Which lesson should be recommended next?
The data model is deliberately simple. I did not want to build a complex learning-management system before proving that the core experience was useful.

Problems I encountered

The first version worked, but it was not perfect.

The responses were too long

The assistant tried to explain everything at once. I improved this by asking for shorter explanations and moving optional detail into follow-up questions.

The assistant repeated completed topics

The first version did not store enough progress information. Once progress was saved in DynamoDB, recommendations became more relevant.

The output was sometimes difficult to parse

Free-form model responses are comfortable for humans but inconvenient for software. Structured responses, schema validation, and clear error handling made the workflow much more reliable.

The application needed boundaries

An assistant that can call tools needs strict limits. Each tool should accept only the parameters it needs, verify the user’s identity, and reject invalid requests.
These issues changed how I thought about the project. The hard part was not simply connecting a model to an API. The hard part was designing the boundary between flexible AI output and predictable application behavior.

Security and cost considerations

A working prototype is not automatically ready for production.
Before deploying an application like this for real users, I would include:
  • IAM roles with least-privilege permissions.
  • Authentication for users and API requests.
  • Validation for prompts, uploaded files, and request sizes.
  • Encryption for S3 objects and DynamoDB data.
  • Careful logging that avoids exposing private learning material.
  • Rate limiting for public APIs.
  • Monitoring for errors, latency, and model usage.
  • Budget alerts for Amazon Bedrock and search resources.
I would also separate development, testing, and production environments. This prevents experiments from affecting real user data.
Cost awareness is especially important for AI applications. Long prompts, large document collections, repeated searches, and unnecessary model calls can increase costs quickly. Caching, prompt limits, smaller models for simple tasks, and asynchronous processing can help keep the design efficient.

What I learned

The biggest lesson was that an AI application is still an application.
The model is only one part of the system. Data modeling, permissions, error handling, observability, user experience, and cost controls matter just as much.
I also learned that a focused agent is often more useful than a general-purpose assistant.
The study buddy does not need to answer every question on the internet. It needs to do a few things well:
  • Understand a learning goal.
  • Create a practical plan.
  • Explain difficult concepts.
  • Track progress.
  • Recommend the next useful action.
Keeping the scope narrow made the application easier to test and easier to improve.

What I would build next

There are several features I would add in a future version:
  • Spaced-repetition reminders.
  • Automatic difficulty adjustment.
  • A dashboard showing learning trends.
  • Voice-based questions.
  • Support for multiple foundation models.
  • Human review for generated educational content.
  • A more advanced agent runtime for long-running workflows.
I would also like to test whether the assistant could help with hands-on learning rather than only theory. For example, it could give the user a small AWS challenge, inspect the result, and suggest the next step.
That would turn the study buddy from a learning companion into something closer to a practical coach.

Conclusion

This project started with a simple question: could I build an AI assistant that helps someone make steady progress instead of just answering isolated questions?
The answer is yes, but the model alone is not what makes the application useful.
The real value comes from combining Amazon Bedrock with a reliable application around it: Lambda for business logic, DynamoDB for progress, S3 for learning material, search for retrieval, and carefully designed tools for controlled actions.
The most important design decision was also the simplest one: give the agent a clear job.
In this case, its job is not to be an expert on everything. Its job is to help one person learn one topic, one step at a time.
# amazon-bedrock# amazon-dynamodb# aws-lambda# amazon-s3# ai-agents
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article