DEV Community: abdullah haroon

MAYHEM: A Monster-Collecting Battle Game built with AdaL and Cloudinary ⚔️

abdullah haroon — Tue, 27 Oct 2026 01:16:40 +0000

Create your legend. Collect the extraordinary. Fight for glory.

What if you could upload an image, turn it into a collectible monster, build a squad of three, and take it into a turn-based battle?

That idea became MAYHEM — Monster Fighting Arena, an open-source browser game where you collect creatures, create your own fighters from images, and battle rival tamers in a dark-fantasy world.

I built MAYHEM using AdaL, an AI-assisted development workflow, and integrated Cloudinary to handle monster artwork uploads, image transformations, optimized delivery, and shareable collectible cards. Here’s a look at the project, the technology behind it, and what you can explore in the game.

🎮 What is MAYHEM?

MAYHEM is a browser-based monster-collecting and turn-based battle game. It runs on desktop, tablet, and mobile without requiring installation or an account. The core idea is simple:

Collect: Discover monsters across six elemental types and four rarity tiers.
Create: Upload an image and transform it into a custom monster.
Build: Assemble a team of three monsters.
Battle: Fight opponents using attacks, special abilities, defensive moves, items, and team switching.
Progress: Earn coins and XP, unlock new species, complete quests, and improve your monsters.

The game combines collectible-card mechanics with RPG-style progression and turn-based combat.

✨ Explore the game

1. Discover: Enter the arena

The home screen introduces the world of MAYHEM through a cinematic fantasy scene, animated effects, featured discoveries, daily rewards, and progression information.

The interface uses a dark purple atmosphere, glowing accents, and fiery orange calls to action to create an arcade-inspired fantasy experience.

2. Collection: Build your bestiary

Every monster has its own identity, elemental type, rarity, stats, and special ability.

The collection includes four rarity tiers:

Common
Rare
Epic
Legendary

You can search for monsters, filter by element or rarity, sort your collection, and mark favourites. Higher rarity cards can feature foil and holographic-style finishes.

3. Create Your Monster: Turn images into fighters

This is one of my favourite parts of the project.

Instead of choosing only from predefined creatures, players can upload an image, drag and drop a file, paste an image, or use bundled sample artwork. They can then customize the monster's name, element, and rarity, choose a battle style, and preview its collectible card before creating it. The creation studio also includes generated stats, special abilities, and a full-screen reveal when a new monster is born.

4. Battle Arena: Strategy matters

Players select a squad of three monsters and face rival tamers in turn-based battles.

Available actions include:

Attack: Deal damage to the opponent.
Special: Use a powerful monster ability.
Defend: Reduce incoming damage and gain defensive benefits.
Switch: Change the active monster.
Items: Use available battle items.

Combat also includes elemental matchups, speed-based turn order, critical hits, status effects, shields, and buffs. The arena has three difficulty tiers, each with its own setting: Verdant Ruins, Stormspire Citadel, and Infernal Throne.

5. Progression and Shop: Keep getting stronger

Battles and quests feed into the game's progression system. Players earn XP and coins, level up their summoner, unlock additional monster species, purchase stat boosts, learn skills, and acquire battle items. Achievements, collection milestones, daily quests, and login streaks provide more goals beyond simply winning fights.

🤖 Building with AdaL

MAYHEM was designed and developed with AdaL, an AI-assisted development workflow. AdaL helped with several parts of the project, including game design, UI and UX, the battle engine, procedural audio, and Cloudinary integration.

A project like this requires more than generating a few screens. The interface, game rules, monster stats, battle actions, progression, image uploads, and saved state all need to work together. That made MAYHEM an opportunity to bring several pieces into one playable experience rather than build a static mockup.

☁️ How Cloudinary powers MAYHEM

Monster creation depends on images, so image handling is a core part of the experience—not just an extra feature.

I integrated Cloudinary to manage monster artwork and make it suitable for different parts of the game.

Here's how it is used:

Cloudinary capability	How MAYHEM uses it
Unsigned uploads	Upload monster artwork directly from the browser using an upload preset
Image transformations	Crop and resize images for collectible cards and thumbnails
Automatic format and quality	Use `f_auto,q_auto` for optimized image delivery
Smart cropping	Use `c_fill,g_auto` to fill the card frame while focusing on the subject
Optional background removal	Use `e_background_removal` when the required add-on is available
Shareable card images	Render monster details, rarity, stats, abilities, and borders into shareable cards
CDN delivery	Load artwork at responsive sizes with lazy loading and fallbacks

For example, the transformation settings can request an automatically selected format and quality:

f_auto,q_auto

For a card image that needs to fill a portrait frame while keeping the main subject in focus:

c_fill,g_auto

These transformations help serve artwork in a form suited to the game's collectible cards.

A small but important security detail

The browser uses an unsigned upload preset and browser-safe Cloudinary configuration. The Cloudinary API secret is never exposed through a VITE_ environment variable.

Game data—such as monster stats, inventory, progression, and battle rules—remains separate from image hosting. Cloudinary handles the images, while the game handles the gameplay.

MAYHEM also has a fallback: if Cloudinary isn't configured, the game can process uploaded artwork in the browser and save it on the device. It reports that fallback rather than pretending a cloud upload succeeded.

🛠️ Tech stack

The project uses:

React 18 — UI and reusable components
TypeScript 5 — typed game data and application logic
Vite 5 — development server and production build
Tailwind CSS 4 — styling and interface design
Cloudinary — image uploads, transformations, and delivery
Web Audio API — procedural music and sound effects
localStorage — local game saves and player progression
AdaL — AI-assisted development workflow

The game logic is organized into modules for elements, monster data, stats, combat rules, turn order, progression, and persistence. The UI is divided into screens and reusable components.

🌱 What's next?

MAYHEM is open source under the MIT License. The project can be forked, modified, reskinned, and extended.

Some areas where contributors could help include:

Adding new monsters, elements, and abilities
Improving battle balance
Online Multiplayer
Creating new arena environments
Improving accessibility and translations
Exploring a real backend for persistent player accounts and shared progression

The current game saves progress locally through localStorage, with a storage adapter that can support a future backend implementation.

🤝 Try it, fork it, improve it

MAYHEM brings together creature collection, image-driven customization, turn-based combat, progression systems, and cloud-powered image handling in one browser game.

I'm especially interested in the possibilities of letting players create their own creatures instead of being limited to a predefined roster. If you're interested in game development, AI-assisted coding, React, or Cloudinary image workflows, I'd love for you to explore the project.

Project repository: https://github.com/ab2030909/MAYHEM-monsters-card-game
Website Link: https://mayhem-monsters.vercel.app/

Built with: AdaL + React + TypeScript + Cloudinary

If you check it out, let me know: what kind of monster would you create first? 🔥

⚔️ Enter the arena. Unleash MAYHEM.

Meet NEXI: A Windows Focus Companion Built with Python and AdaL

abdullah haroon — Mon, 26 Oct 2026 02:09:50 +0000

What if your computer could help you understand where your time goes and gently remind you when it's time to get back on track?

That's the idea behind NEXI: Your Focus Companion, a Windows desktop productivity app I've been building with Python, PySide6, and AdaL.

NEXI combines activity tracking, focus sessions, intention-based work, visual analytics, and a small floating companion into one desktop application. The goal isn't to control every minute of your day. It's to make your digital habits easier to understand and help you work with more intention.

Why I built NEXI

We spend hours switching between code editors, browsers, chats, and other applications. Sometimes that time is productive. Sometimes we open a browser to look up one thing and end up somewhere completely different. I wanted a desktop tool that could help answer a few simple questions:

Where did my computer time actually go?
Which applications and websites occupied most of it?
When am I most active?
Can I set a clear intention before starting a focus session?
Can productivity tools feel useful without looking boring or intrusive?

That became the starting point for NEXI.

1. Focus Center: One place to start a session

The Focus Center is the main dashboard. It brings the current focus session, timer, active foreground application, and daily activity summaries together.

The dashboard includes:

Focus sessions with a circular countdown.
Focus modes such as Deep Work and Custom.
Intent Mode for setting a task and time budget.
Screen time, productive time, distractions, and daily goal metrics.
Most-used applications and tracked website summaries.

I wanted the main screen to answer one question quickly: What is happening on my computer right now?

2. Intent Mode: Work with a purpose

One of NEXI's key ideas is Intent Mode.

Before starting a session, you can define a task, choose a time budget, and optionally specify a target platform.

For example:

Study compiler design for 45 minutes.
Find a solution to an authentication bug.
Watch a programming tutorial without losing track of time.

The idea is simple: instead of opening an application without a plan, start with a specific reason for being there.

Intent Mode is designed to support accountability through a defined objective and countdown. Its behavior depends on the features and integrations enabled in the current build.

3. Focus Radar: Turn activity into something understandable

Raw activity logs aren't very helpful if you can't see the patterns in them.

Focus Radar presents tracked activity through visual summaries, hourly bars, time-period filters, and application and website breakdowns.

The dashboard is designed to help answer questions such as:

How much active time did I record today?
Which application did I use most?
When was my activity highest?
Which websites accounted for tracked distraction time?

The emphasis is on visual clarity. Bars and ranked lists make it easier to spot patterns than reading a long list of timestamps.

4. Understand which applications consume your time

NEXI can track the foreground application and present application usage alongside website activity where supported.

The purpose isn't to judge every application as good or bad. A browser can be essential for research, just as an editor can be essential for coding. Context matters. The useful part is being able to see where time accumulated and use that information to make better decisions.

5. A settings page that gives users control

Productivity tools need to adapt to the person using them.

NEXI's Settings page brings appearance preferences, attention controls, timers, website limits, and monitoring options into one place.

The appearance controls include a dark theme, OLED-style black, Midnight Orange, a light theme, and custom color values.

The app also has a break experience with a breathing prompt and controls to resume focus or extend the break. Other attention and website-control options depend on the current implementation and configuration.

6. A small companion, not another noisy notification

I also wanted NEXI to have a recognizable personality.

The floating companion is designed to sit alongside the desktop workflow rather than demand constant attention. It gives the app a visual identity beyond another timer and collection of charts. The design direction is deliberately focused: dark surfaces, orange highlights, clear typography, and compact cards.

7. Built with Python, PySide6, and AdaL

NEXI is a Windows desktop application built with Python and PySide6 (Qt) using AdaL.

The project brings together several pieces:

PySide6: desktop interface and interactive components.
Windows APIs: foreground application detection and idle-time awareness.
SQLite: local activity and settings storage.
Chromium browser integration: optional support for more accurate website attribution.
Groq API: optional AI habit insights, when configured.

I used AdaL as a coding assistant throughout development. It helped me work through implementation tasks and iterate on the application, while the project itself remains a software system that needs practical verification and refinement.

The architecture aims to keep everyday activity tracking local. Optional AI insights are a separate capability and should be enabled only when the user wants to use them.

8. Privacy and user control

Activity tracking is personal, so privacy needs to be part of the design rather than an afterthought.

NEXI is designed around local storage for activity records. Its optional browser integration communicates with a local service, and the optional AI coach is intended to use high-level summaries rather than raw browsing history.

Users should still review the settings and privacy documentation for the exact behavior of the release they install, especially before enabling optional integrations.

What's next?

There is always more to improve in a desktop productivity app. My next priorities are making the experience more polished, keeping the dashboard responsive, improving empty states and activity summaries, and ensuring that focus and attention controls behave consistently. I also want the project to be straightforward for other developers to explore, build, and contribute to.

Try NEXI

NEXI is built for people who want a clearer picture of their computer habits and a more intentional way to approach focus sessions.

GitHub: https://github.com/ab2030909/NEXI-focus-companion
Releases: https://github.com/ab2030909/NEXI-focus-companion/releases/latest

If you're interested in desktop productivity tools, Python GUI applications, or building software with AI coding assistants, I'd love to hear your thoughts.

What feature would make a focus companion genuinely useful in your daily workflow?

Built with Python, PySide6, and AdaL.

Building Transforma: A Cloudinary Image Transformation and Benchmarking Playground

abdullah haroon — Wed, 14 Oct 2026 23:33:52 +0000

Imagine you're building a web application that displays hundreds of images.

Everything works perfectly on your development machine. But then you notice that some images are unnecessarily large, mobile users are downloading more data than they need, and you're not sure whether your image optimization settings are actually helping.

You start changing image dimensions, experimenting with compression, and manually editing transformation URLs. One configuration produces a smaller file, another preserves better quality, and a third behaves differently when delivered through the CDN.

Now you have another problem: How do you compare these configurations without turning image optimization into a repetitive manual process?

I wanted to explore a better way to approach this problem.

That's why I built Transforma , an interactive developer workbench for building, visualizing, comparing, and benchmarking Cloudinary image-transformation pipelines. The idea is simple: give developers a place to experiment with image transformations, inspect the results, measure what actually changes, and export the configurations they want to use in their applications.

Transform. Optimize. Measure.

The problem: Image optimization is more than compression

When I started thinking about this project, I wanted to focus on a problem developers encounter in real applications.

Consider a platform that displays workspace photographs, user profile pictures, product images, and community posts. Each image may be displayed in a different context. A small profile card doesn't need the same dimensions as a full-width desktop banner. A mobile layout may need a smaller image than a high-resolution display.

Serving the original image everywhere can waste bandwidth. Manually generating multiple versions introduces additional work, and aggressive compression can reduce visual quality. I identified four practical challenges:

Oversized images: Delivering unnecessarily large images increases the amount of data transferred.
Complex transformations: Developers need to manage resizing, cropping, formats, and quality settings.
Quality trade-offs: Smaller files are useful, but not when the resulting image looks noticeably worse.
Limited visibility: Without actual measurements, it's difficult to compare different optimization strategies.

I wanted a tool that would make these trade-offs easier to explore.

Why Cloudinary?

Instead of building my own image-processing infrastructure, I chose to build around Cloudinary's existing media capabilities.

Cloudinary provides APIs for uploading and managing media, URL-based image transformations, and CDN delivery. It also supports automatic format and quality selection through transformation parameters such as f_auto and q_auto.

This meant I could focus on the developer experience rather than implementing a custom image-processing engine.

The responsibilities became clearer:

Cloudinary handles image storage, supported transformations, and media delivery.
Transforma provides the visual interface for configuring transformations.
The browser displays the results and measures observable delivery characteristics.
The application generates reusable URLs and code snippets.

That separation became the foundation of the project.

Introducing Transforma

Transforma is a developer-focused playground built with Next.js, TypeScript, Tailwind CSS, and the official Cloudinary Node.js SDK. It brings several related workflows into one workspace:

Upload an image.
Configure transformation parameters.
Compare the original and transformed versions.
Inspect image dimensions, formats, and available file-size measurements.
Benchmark delivery requests.
Export the resulting transformation URL or code.

Rather than manually assembling every URL, developers can experiment through a visual interface and see how their choices affect the resulting image.

1. Building image transformation pipelines visually

Cloudinary transformations are powerful, but manually constructing URLs can become tedious when experimenting with multiple combinations of parameters.

Transforma provides controls for the most common image-transformation operations.

Resizing images

Developers can specify custom dimensions or choose preset widths such as:

320px
640px
800px
1200px
1920px

For example, if an image is displayed in an 800-pixel-wide container, delivering a much larger image may be unnecessary for that particular use case.

A transformation can limit the output width while preserving the image's proportions.

Choosing a cropping strategy

Different layouts require different cropping behavior.

Transforma supports these Cloudinary transformation modes:

Mode	Purpose
`c_fit`	Fit the image within the requested dimensions
`c_fill`	Fill the target dimensions, cropping when necessary
`c_crop`	Extract a region from the source image
`c_scale`	Scale the image to the requested dimensions

For example, a profile image may need a consistent square shape, while a workspace photograph may need to preserve more of the original scene.

Optimizing format and quality

One of Cloudinary's useful features is automatic format and quality selection.

A transformation such as:

f_auto,q_auto,w_800

requests automatic format and quality selection with a target width of 800 pixels.

The delivered format and resulting file size depend on the source image, browser capabilities, and delivery configuration. Rather than assuming the transformation always produces a particular result, Transforma lets developers inspect the output.

Advanced options

The playground also provides access to options such as:

dpr_auto for device-pixel-ratio-aware delivery.
g_auto for automatic gravity and subject-aware cropping where supported.
fl_strip_profile for removing supported image profile metadata.

These options make the playground useful for exploring more than basic resizing and compression.

2. Comparing images instead of guessing

Reducing an image's file size is only part of the problem. The image should still look good.

For this reason, Transforma includes two visual comparison modes.

Before-and-after slider: Move a divider across the preview to inspect the original and transformed versions in the same viewing area.

Side-by-side comparison: Display both versions simultaneously to compare composition, sharpness, and visible compression artifacts.

The workspace can also display relevant asset information, including dimensions, available file-size measurements, delivered format, and the active transformation settings.

This makes it easier to understand what actually changed between configurations.

The important idea is that developers should be able to inspect both the visual result and the technical properties of the image.

3. Measuring actual image-delivery performance

This is where Transforma goes beyond being a simple image editor.

A smaller image doesn't automatically guarantee a faster request. Delivery performance also depends on network conditions, browser caching, connection reuse, and CDN behavior. I designed the benchmarking workflow to compare several configurations:

The original image.
An automatically optimized image.
A resized image with automatic optimization.
A higher-quality transformed variant.

The browser makes real requests to Cloudinary's delivery endpoints and collects measurements that are available to JavaScript.

What does the benchmark measure?

Metric	Why it matters
Downloaded bytes	Shows the delivered payload size
Image dimensions	Helps verify the resulting image size
Delivered format	Identifies the resulting encoding when detectable
Request duration	Measures client-observed request timing
Byte savings	Quantifies the payload difference against the baseline

For example, the percentage reduction in file size can be calculated as:

Savings (%) =
  ((Original Size - Transformed Size) / Original Size) × 100

This gives developers a consistent way to compare the payload impact of different transformation settings.

How the benchmarking workflow works

The process follows a straightforward sequence:

Generate the URLs for the selected transformation scenarios.
Request the images from Cloudinary's CDN.
Measure elapsed time using the browser's performance.now() API.
Read available response metadata or inspect downloaded Blob sizes.
Inspect image dimensions and format where possible.
Aggregate the results into a comparison report.

The intention is to use actual request results rather than predetermined performance numbers.

Understanding the limitations

Browser-based measurements require some care.

Cross-origin restrictions may prevent JavaScript from reading certain response headers. Cached responses may also behave differently from requests that transfer the image over the network.

Adding a unique query parameter can help distinguish benchmark requests, but it does not guarantee a cold Cloudinary edge cache. Similarly, a browser-observed request duration is not the same as measuring the entire page's loading performance. For meaningful comparisons, test conditions should be documented and repeated measurements considered.

The goal is not to promise a particular speed improvement. It is to help developers understand the trade-offs using observable evidence.

4. Securing direct image uploads

Another important part of Transforma is the upload workflow.

When users upload images, the application needs to authorize the upload without exposing sensitive Cloudinary credentials in the browser.

I used a server-signed upload architecture built with Next.js Route Handlers and the official Cloudinary Node.js SDK.

Here's how the flow works:

sequenceDiagram
    autonumber
    actor User as Browser
    participant API as Next.js API
    participant SDK as Cloudinary SDK
    participant Cloud as Cloudinary Upload API

    User->>API: Request upload authorization
    API->>SDK: Sign permitted parameters
    Note over API,SDK: API secret stays server-side
    SDK-->>API: Return signature
    API-->>User: Signature and upload configuration
    User->>Cloud: Upload image directly
    Cloud-->>User: Return asset metadata
    User->>User: Update image preview

The workflow has a few important steps:

The browser requests upload authorization from POST /api/sign-upload.
The server generates a timestamp and signs the permitted upload parameters.
The browser receives the signature and public upload configuration.
The image is uploaded directly to Cloudinary.
The application receives the asset metadata and updates the interface.

The signing logic follows this pattern:

const timestamp = Math.round(Date.now() / 1000);

const signature = cloudinary.utils.api_sign_request(
  {
    folder: "transforma-pipeline",
    timestamp,
  },
  process.env.CLOUDINARY_API_SECRET!
);

The API secret stays on the server. The browser receives the signature required for the upload, not the secret itself.

The implementation also needs server-side validation of upload parameters and sensible restrictions on accepted file types and sizes. Client-side validation alone is not sufficient.

Once an upload succeeds, the returned public ID and asset metadata can be used to generate transformation URLs and update the preview.

5. How a transformation becomes a delivered image

The transformation builder is the central part of Transforma.

Rather than making the application process every image itself, it generates Cloudinary transformation URLs from the selected parameters.

flowchart LR
    A[Transformation Controls] --> B[Parameter Compiler]
    B --> C[Cloudinary Transformation URL]
    C --> D[Cloudinary CDN]
    D --> E[Transformed Image]
    D --> F[Visual Comparison]
    D --> G[Code Export]

    A1[Resize and Crop] --> A
    A2[Format and Quality] --> A
    A3[Advanced Options] --> A

The user changes a setting, such as the target width or output format. The application compiles those choices into a valid transformation URL. Cloudinary then delivers the requested transformed asset, which Transforma displays and makes available for comparison.

This keeps the application relatively lightweight while allowing developers to explore Cloudinary's media-processing capabilities.

It also makes transformation configurations easier to reproduce because the parameters are explicit in the generated URL.

6. Exporting reusable code

A developer playground becomes much more useful when its output can be used in real applications.

Transforma provides a code-export panel for copying:

Cloudinary delivery URLs.
HTML image markup.
Next.js image usage examples.
JavaScript integration snippets.
Cloudinary Node.js SDK examples.

For instance, a generated delivery URL can be used in ordinary HTML:

<img
  src="YOUR_CLOUDINARY_TRANSFORMED_IMAGE_URL"
  alt="Optimized image"
  loading="lazy"
/>

Transforma also supports saving named pipeline configurations in browser local storage. Developers can reload these recipes without requiring a separate database or account system.

7. The technology stack

Transforma uses a lightweight architecture in which each component has a clear responsibility.

Technology	Responsibility
Next.js App Router	Application interface and API routes
TypeScript	Transformation settings and asset metadata
Tailwind CSS	Responsive interface styling
Lucide React	Interface icons
Cloudinary Node.js SDK	Upload signing and Cloudinary integration
Cloudinary Upload API	Direct image uploads
Cloudinary transformation URLs	Resizing, cropping, and format and quality options
Browser Performance APIs	Client-observed benchmark timing
Browser local storage	Saved pipeline configurations

Cloudinary provides the media infrastructure, while Transforma focuses on making that infrastructure easier to explore and use.

This means there's no need to build a separate image-processing backend for transformations Cloudinary already supports.

8. What I learned

Building Transforma helped me think about image optimization as a measurable engineering problem rather than just a collection of URL parameters.

Optimization depends on context. The right dimensions and quality settings depend on where an image is displayed and how much visual detail needs to be preserved.

Transformations should be reproducible. Explicit parameters make it easier to reuse configurations and compare their results.

Performance claims need evidence. Payload size and request duration are different metrics. A smaller image can be beneficial without guaranteeing a faster request in every environment.

Security belongs in the architecture. Direct uploads can avoid proxying image contents through the application server, but authorization and server-side validation remain essential.

Developer tools should produce reusable results. A playground is more valuable when its output can be taken directly into another application.

What's next?

Transforma provides a foundation for experimenting with Cloudinary image-transformation pipelines. Future improvements could include richer responsive-image generation, repeatable benchmark reports, additional transformation presets, and more export options. The broader goal is to help developers understand what a transformation does, inspect its output, and make informed decisions about media delivery.

Try Transforma

GitHub repository: https://github.com/ab2030909/Transforma
Live demo: https://transforma-zeta.vercel.app/

Transforma is an independent developer project built with Cloudinary. It is not an official Cloudinary product.

I'd love to hear how other developers approach image transformation pipelines, responsive media delivery, and performance benchmarking.

How do you balance image quality, payload size, and delivery performance in your applications?

Building DreamCanvas: An AI Agent That Imagines a New World Every Day | 10 Days of Building AI Agents on AWS | Day 10

abdullah haroon — Tue, 01 Sep 2026 03:24:00 +0000

Building DreamCanvas: An AI Agent That Imagines a New World Every Day

10 Days of Building AI Agents on AWS | Day 10

Tag: #agents

DreamCanvas is an always-on AI creative agent that imagines a new fictional world every day before you even open the app.

Vision: Creativity That Does Not Wait

Most creative applications wait for a user to open them, enter a prompt, and request something new.

I wanted to explore a different idea:

What if a creative application could continue creating even when nobody was actively using it?

That idea became DreamCanvas.

DreamCanvas is an autonomous AI creative agent that generates a brand-new fictional world every day.

Instead of opening an application and asking an AI to imagine something, the user can return later and discover that a completely new world has already been created.

The experience is simple:

You leave → DreamCanvas keeps working → You return → A new world is waiting

The goal was to create an experience where inspiration is already waiting.

What Does DreamCanvas Create?

Each generated world has its own identity and creative details.

A world can include:

Unique world name
Genre
Atmosphere
Tagline
World overview
Environment
Inhabitants
A special rule of the universe
Main conflict
A surprising discovery
A story seed that could become the beginning of a larger story

This means DreamCanvas does not simply generate a short idea or random paragraph.

It creates the foundation of an entirely new fictional universe.

Every day, the agent has the opportunity to create something completely different.

One day, it might imagine a civilization living beneath an endless ocean.

The next day, it could create a city where memories are traded as currency.

Another day, it might imagine a forgotten kingdom floating between planets.

The user does not need to ask for these worlds.

They are already waiting.

The Always-On Agent Workflow

DreamCanvas works differently:

User leaves
        ↓
EventBridge wakes the agent automatically
        ↓
Agent checks recent worlds
        ↓
Agent remembers previous creative directions
        ↓
Agent chooses a different direction
        ↓
Groq generates a new fictional world
        ↓
Lambda validates the response
        ↓
World is stored in DynamoDB
        ↓
User returns later
        ↓
A new world is already waiting

The application does useful creative work without waiting for a user to request it.

That is the main idea I wanted to explore.

Lightweight Agent Memory

One of the important features of DreamCanvas is memory.

Before generating a new world, the agent retrieves recent creations from Amazon DynamoDB.

The recent worlds provide context such as:

Previous world names
Genres
Atmospheres
Settings
Main concepts
Inhabitants
Conflicts
Summaries

This information is provided to the AI during the next generation.

The agent is instructed to avoid repeating similar creative directions.

For example, if recent worlds have focused on:

Futuristic cities
Fantasy kingdoms
Dark mysterious worlds

The next generation can be encouraged to explore something meaningfully different.

Perhaps:

A peaceful alien ecosystem
A world inside a living machine
A civilization existing in people's dreams
An ancient world where time moves differently

This gives DreamCanvas a lightweight form of memory.

I deliberately did not use a vector database or a complicated AI framework.

For this use case, recent DynamoDB records provide enough context to influence future generations while keeping the architecture simple.

This was an important design decision.

Not every AI agent needs a complex memory system. Sometimes remembering the most recent actions is enough.

How I Built It

I intentionally kept the project architecture simple and focused.

Frontend

The frontend uses:

HTML
CSS
Vanilla JavaScript

I did not use a large frontend framework because the main purpose of the project was to demonstrate the always-on AI agent architecture.

The website allows users to:

View today's generated world
Explore complete world details
Browse previously imagined worlds

When the user opens the application, the frontend requests the latest generated world from the backend.

Because the autonomous workflow has already run, the new world is ready to display.

The Autonomous Backend

The most important part of DreamCanvas runs on AWS.

An Amazon EventBridge schedule automatically wakes the agent every day.

The scheduled event invokes an AWS Lambda function.

The workflow begins with an important check.

Step 1: Check for Today's World

Lambda first checks whether a world has already been generated for the current day.

This makes the workflow idempotent.

Has today's world already been created?

YES → Stop

NO → Continue generation

This prevents accidental duplicate generations and unnecessary AI API usage.

Step 2: Retrieve Recent Memory

If no world exists for the current day, Lambda retrieves several recent worlds from Amazon DynamoDB.

These records act as the agent's memory.

Step 3: Choose a New Creative Direction

The recent worlds are used as context.

The AI is instructed to create something meaningfully different from recent generations.

The goal is not simply randomness.

The goal is informed variety.

The agent knows what it recently created and uses that information when creating something new.

Step 4: Generate the World

Lambda sends the creative context to the AI through the Groq API.

Groq acts as the creative generation engine.

Step 5: Validate the AI Response

The backend does not blindly store the AI response.

The Lambda validates the generated data before saving it.

This is important because the application expects structured information.

The validation checks that the required data exists and that the response can be safely processed.

If the AI response is malformed, the application handles the problem safely and can retry generation rather than storing invalid data.

Step 6: Save the New World

Once validation succeeds, the new world is stored in Amazon DynamoDB.

The generated world then becomes available through the application's API.

When the user returns later, the frontend can immediately display it.

Separating AI Generation from Infrastructure

One of the key architectural decisions was separating the AI generation service from the always-on application infrastructure.

Groq handles creative AI generation.

AWS handles:

Scheduling
Serverless execution
Storage
API access
Security
Logging
Monitoring
Deployment

The separation looks like this:

AWS EventBridge
        ↓
AWS Lambda
        ↓
DynamoDB Memory
        ↓
Groq API
        ↓
AWS Lambda Validation
        ↓
DynamoDB Storage

This allows the application to combine an external AI model with AWS serverless infrastructure.

AWS Services Used

DreamCanvas uses a lightweight serverless architecture built with the following AWS services.

AWS Lambda

AWS Lambda runs the DreamCanvas agent and backend API logic.

It handles:

Daily world generation
Checking for duplicates
Retrieving recent worlds
Preparing AI prompts
Calling the Groq API
Validating responses
Storing new worlds
Serving API requests

Amazon EventBridge

Amazon EventBridge automatically triggers the DreamCanvas agent every day.

This is what transforms the project from a normal AI application into an always-on system.

The user does not need to press a button.

The scheduled event wakes the agent automatically.

Amazon DynamoDB

Amazon DynamoDB stores the generated fictional worlds.

It also acts as lightweight agent memory.

Before creating a new world, the agent retrieves recent records and uses them as context to avoid repetitive output.

Amazon API Gateway

Amazon API Gateway provides API endpoints for the frontend.

The frontend can use these endpoints to:

Retrieve today's world
Browse previous worlds
View individual world details

Amazon S3

Amazon S3 hosts the static frontend.

The frontend consists of:

HTML
CSS
JavaScript

AWS Secrets Manager

AWS Secrets Manager securely stores the Groq API key.

The key is never exposed in browser code or committed to the repository.

The Lambda backend retrieves the secret using AWS permissions.

The security flow looks like this:

Frontend
    ↓
API Gateway
    ↓
Lambda
    ↓
Secrets Manager
    ↓
Retrieve Groq API Key
    ↓
Groq API

Amazon CloudWatch

Amazon CloudWatch provides logs and monitoring.

It helps monitor:

Scheduled generation events
Lambda execution
Validation failures
API errors
Application debugging

AWS SAM

I used AWS SAM to define and deploy the serverless infrastructure.

SAM uses AWS CloudFormation underneath and makes it easier to define serverless resources as infrastructure as code.

This means the AWS environment can be deployed consistently from the project instead of manually creating resources one by one.

DreamCanvas is an always-on AI creative agent that remembers recently imagined worlds, automatically creates a new one every day using Groq, and uses AWS serverless services to make sure the next world is waiting before the user even opens the application.

App and Source Code

Live App:
[http://dreamcanvas-frontend-305218268847-us-east-1.s3-website-us-east-1.amazonaws.com/]

Building FridgeChef AI: Turning Available Ingredients into Recipes | 10 Days of Building AI Agents on AWS | Day 9

abdullah haroon — Mon, 31 Aug 2026 02:28:00 +0000

10 Days of Building AI Agents on AWS | Day 8

Opening the fridge and still not knowing what to cook is a frustrating daily problem.

You may already have chicken, eggs, vegetables, rice, spices, and other ingredients at home, but still spend more time searching for recipes than actually preparing a meal.

That was the problem behind FridgeChef AI.

FridgeChef AI is an AI-powered recipe assistant that transforms the ingredients already available in your kitchen into personalized meal ideas using generative AI and AWS serverless technologies.

The idea is simple:

Available Ingredients → Preferences → AI → Personalized Recipe

Instead of searching through multiple recipe websites, users can enter what they already have and let AI suggest what they can cook.

Vision and What FridgeChef AI Does

One of the most common everyday frustrations is standing in front of the refrigerator wondering:

What can I actually cook with this?

Even when we have several ingredients available, it can be difficult to combine them into a complete meal idea.

This often leads to:

Wasted time searching for recipes
Unnecessary grocery purchases
Ingredients being forgotten
Food eventually expiring unused

I wanted to build a focused application that solves this one problem.

With FridgeChef AI, users simply enter the ingredients available in their kitchen and select optional preferences such as:

Preferred cuisine
Dietary restrictions
Cooking time

The AI then generates personalized recipe suggestions in seconds.

Each response can include:

Recipe suggestions
Required ingredients
Cooking instructions
Estimated cooking time
Additional cooking tips

The goal was not to build a complete recipe platform with thousands of manually created recipes.

Instead, the focus was on one useful experience:

Tell FridgeChef what you have, and let AI help you decide what to cook.

By encouraging users to cook with ingredients they already have, the application can also help reduce unnecessary food waste.

How I Built It

I wanted the project to use a modern serverless architecture while keeping the deployment process automated and reproducible.

Frontend

The frontend was built using:

React
Vite

The interface uses a warm, kitchen-inspired design focused on making the experience simple and intuitive.

Users can:

Add available ingredients
Select cuisine preferences
Choose dietary options
Specify their preferred cooking time
Generate personalized recipes

The frontend communicates with the backend through an API.

Backend

The backend was developed using Node.js and deployed as an AWS Lambda function.

Instead of maintaining a traditional server, the backend runs only when a request is received.

The request flow is:

User enters ingredients
        ↓
Frontend sends request
        ↓
Amazon API Gateway
        ↓
AWS Lambda
        ↓
Groq API
        ↓
Recipe generation
        ↓
Structured JSON response
        ↓
Frontend displays recipes

This architecture keeps the backend lightweight and serverless.

The AI Recipe Generation

For AI-powered recipe generation, I integrated the Groq API.

The backend receives the user's ingredients and preferences and creates a structured prompt.

For example, the input may contain:

`
Ingredients:
Chicken, rice, onions, tomatoes, garlic

Cuisine:
Pakistani

Dietary Preference:
None

Cooking Time:
30 minutes
`plaintext

The backend sends this information to the AI model and requests a structured recipe response.

The AI can generate information such as:

Recipe name
Description
Ingredients
Cooking instructions
Estimated preparation time
Cooking tips

The response is then formatted into structured JSON before being returned to the frontend.

Using structured responses makes it easier for the application to reliably display the generated recipes.

Why I Chose a Serverless Architecture

This project did not need a traditional server running continuously.

Recipe generation happens only when a user submits ingredients.

That makes a serverless architecture a good fit.

The backend can remain inactive until a request arrives:

No request → No backend processing

When a user generates a recipe:

Request arrives → Lambda runs → AI generates recipe → Response returns

This allowed me to focus on the application rather than managing servers.

AWS Services and Architecture

The application uses several AWS services.

AWS Amplify Hosting

AWS Amplify hosts the React frontend and makes the application publicly accessible.

It provides the hosting layer for the user interface.

Amazon API Gateway

Amazon API Gateway receives requests from the frontend and routes them to the serverless backend.

The frontend does not communicate directly with the AI provider.

Instead:

Frontend ↓ API Gateway ↓ AWS Lambda ↓ Groq APIplaintext

This keeps the AI integration inside the backend.

AWS Lambda

AWS Lambda runs the Node.js backend.

It is responsible for:

Receiving recipe requests
Processing ingredients and preferences
Creating the AI prompt
Calling the Groq API
Processing the AI response
Returning structured recipe data

Lambda runs when the application receives a request, so there is no continuously running backend server.

AWS SAM

I used AWS SAM (Serverless Application Model) to simplify the development and deployment of the serverless backend.

SAM makes it easier to define and deploy resources such as:

Lambda functions
API Gateway endpoints
IAM permissions
Environment configuration

AWS CloudFormation

The infrastructure is provisioned using AWS CloudFormation.

Rather than manually creating resources through the AWS Console, the infrastructure is defined as code.

This means the deployment can be repeated consistently.

The infrastructure definition includes:

AWS Lambda configuration
API Gateway configuration
IAM roles and permissions
Environment variables
Required service connections

The workflow becomes:

Infrastructure Code → AWS SAM → CloudFormation → AWS Resources

Amazon CloudWatch

Amazon CloudWatch is used for monitoring and debugging.

During development, CloudWatch logs helped identify deployment and runtime issues.

Architecture Overview

The complete architecture looks like this:

USER │ ▼ AWS Amplify React + Vite App │ ▼ Amazon API Gateway │ ▼ AWS Lambda Node.js │ ▼ Groq API AI Recipe Generation │ ▼ AWS Lambda Process AI Response │ ▼ Amazon API Gateway │ ▼ React Frontend │ ▼ Personalized Recipes

The application starts when a user submits a list of ingredients through the frontend.

API Gateway receives the request and invokes the Lambda function.

Lambda prepares the AI prompt and sends it to the Groq API.

Once the AI generates recipe suggestions, the backend formats the result into structured JSON and returns it through API Gateway.

The frontend then displays the recipes to the user.

Infrastructure as Code

One of my main goals was to avoid manually configuring cloud resources.

I used AWS SAM and AWS CloudFormation to automate the infrastructure deployment.

Instead of creating resources one by one through the AWS Console, the backend infrastructure can be deployed using the AWS CLI.

This approach makes deployments:

Repeatable
Easier to manage
Easier to update
Less dependent on manual configuration

During development, I encountered challenges related to CloudFormation parameter handling and environment variables.

After debugging the deployment scripts and configuration, I was able to automate the deployment workflow and deploy the backend consistently.

This was an important learning experience because it showed me that building an application is not only about writing the frontend and backend code.

Deployment and infrastructure configuration are also important parts of the development process.

Challenges I Faced

Like other serverless projects, the main challenges were related to deployment and configuration.

Some of the issues involved:

CloudFormation parameters
Environment variable configuration
Deployment scripts
AWS resource configuration

Debugging these issues helped me better understand how the different parts of a serverless application connect together.

Using Infrastructure as Code also made it easier to identify configuration problems because the infrastructure was defined explicitly instead of being hidden inside manual AWS Console settings.

What I Learned

Building FridgeChef AI gave me valuable hands-on experience with serverless application development on AWS.

Infrastructure as Code

I strengthened my understanding of Infrastructure as Code by deploying the backend through AWS SAM and CloudFormation.

This helped me understand how cloud resources can be defined and managed as part of the application codebase.

API Gateway and Lambda

I learned more about integrating Amazon API Gateway with AWS Lambda.

The project required designing the flow between:

The React frontend
API Gateway
Lambda
The external AI provider

This gave me more experience with serverless APIs and event-driven backend architecture.

AI Integration

Another important learning was integrating an external AI provider into an AWS application.

Groq handles the AI inference, while AWS provides the infrastructure required to deliver the application.

The combination looks like this:

AWS manages the application infrastructure → Groq provides AI generation

This separation allows the application to use managed cloud services while integrating specialized AI capabilities.

Debugging Deployments

Working through CloudFormation and deployment issues also improved my troubleshooting skills.

I learned more about:

Managing deployment parameters
Working with environment variables
Reading deployment errors
Debugging CloudFormation configuration
Structuring applications for repeatable deployment

FridgeChef AI is an experiment in combining generative AI with AWS serverless technologies to solve a simple everyday problem.

The application takes ingredients that users already have and transforms them into personalized meal ideas.

The complete workflow is simple:

Open the App → Enter Ingredients → Choose Preferences → Generate Recipes

Building the project gave me more experience with:

React and Vite
AWS Amplify
Amazon API Gateway
AWS Lambda
AWS SAM
AWS CloudFormation
Amazon CloudWatch
Serverless architecture
Infrastructure as Code
Groq AI integration

More importantly, it demonstrated how quickly a useful AI-powered application can be built by combining managed AWS services with a focused product idea.

Sometimes the best project is not the one with the most features.

It is the one that solves a small, annoying problem well.

Try FridgeChef AI

Live Application:

https://staging.d2rlx4nfgtm79o.amplifyapp.com/

Building VibePlaylist AI: Turning Everyday Moods into AI-Curated Playlists | 10 Days of Building AI Agents on AWS | Day 8

abdullah haroon — Sat, 29 Aug 2026 02:18:00 +0000

10 Days of Building AI Agents on AWS | Day 8

Tag: #agents

Have you ever had a very specific mood but could not find the right music for it?

Maybe it is a late-night drive after a long day, a quiet evening when you are feeling nostalgic, a study session that needs focus, or simply a moment that feels difficult to describe with a normal playlist.

That is the idea behind VibePlaylist AI.

VibePlaylist AI is a generative AI application that turns a user's situation, feeling, memory, place, or activity into a personalized themed playlist.

Instead of manually searching through hundreds of songs, users can describe what they are experiencing, choose a vibe, and let AI curate a musical concept around that idea.

The Idea Behind VibePlaylist AI

A user can enter something like:

Late-night drive through Islamabad after a long and exhausting day.

They can then select a vibe such as:

Chill
Romantic
Sad
Energetic
Dreamy
Nostalgic
Focus

After clicking Create Playlist, VibePlaylist AI generates:

A playlist name
A short description
The selected vibe
Eight song recommendations

For example, the result could become Midnight Miles, with a description inspired by quiet roads, city lights, and reflective thoughts, followed by eight songs that fit the atmosphere.

The core experience is simple:

Your Moment → Choose a Vibe → AI Curates → Discover Your Playlist

The application is not intended to replace music streaming platforms. There is no music playback or Spotify integration.

The creative part is the curation itself.

A simple sentence from the user becomes a complete musical concept that they can explore on their preferred streaming platform.

Building the Experience

For this project, I deliberately kept the scope focused.

The application has one primary purpose: turn a feeling or situation into a themed playlist.

Almost every part of the interface supports that single interaction.

Frontend

The frontend was built using:

HTML5
CSS3
Vanilla JavaScript

I chose a lightweight frontend because the application did not require complex state management or a large component system.

The visual design uses a cinematic black-and-gold theme with clean typography and simple interactive elements.

The main interface contains:

A text input for describing the moment
Vibe selection buttons
A single Create Playlist action

Once the AI response arrives, the playlist is displayed in a dedicated result section containing the playlist name, description, vibe, and track list.

The AI Behind the Playlist

The AI layer is powered by the Groq API.

The backend sends two important pieces of information to the model:

What the user is experiencing
The vibe they selected

I designed the prompt so the model behaves more like a music curator rather than simply returning random song names.

The AI is instructed to:

Create a suitable playlist title
Match the requested mood
Generate exactly eight tracks
Avoid duplicate songs
Create a relevant playlist description
Return a predictable JSON response

The request flow is:

User describes a moment
          ↓
User selects a vibe
          ↓
Frontend sends request
          ↓
AWS Lambda processes it
          ↓
Groq analyzes the mood
          ↓
AI creates playlist JSON
          ↓
Frontend displays the playlist

Why Structured AI Output Matters

One of the practical challenges was making sure the AI response could be reliably consumed by the frontend.

AI-generated text can be unpredictable.

Rather than asking the browser to interpret a large block of generated text, the backend requests structured JSON containing information such as:

json { "playlistName": "Midnight Miles", "description": "A soundtrack for quiet roads and reflective thoughts.", "vibe": "Nostalgic", "tracks": [ { "title": "Song Name", "artist": "Artist Name" } ] }json

This makes the response much easier to:

Validate
Process
Display
Handle when errors occur

It also keeps the frontend logic simple.

This project reinforced an important lesson for me:

A good AI application is not only about the prompt. The format and reliability of the response matter just as much.

Keeping the API Key Secure

Another important consideration was API security.

The Groq API key is never placed inside the frontend code.

The browser does not communicate directly with Groq.

Instead:

Browser ↓ AWS API Gateway ↓ AWS Lambda ↓ Groq APIplaintext

This keeps the AI API key away from client-side JavaScript.

The serverless backend handles communication with the external AI service.

AWS Architecture

VibePlaylist AI uses a serverless AWS architecture.

There is no traditional server that needs to remain running continuously.

The main AWS services used are:

Amazon S3 for storing the static frontend
Amazon CloudFront for global delivery and HTTPS
Amazon API Gateway for exposing the POST /generate endpoint
AWS Lambda for running the Node.js backend
AWS IAM for permissions and access control
AWS CloudFormation for defining and provisioning infrastructure

The complete architecture looks like this:

USER │ ▼ CloudFront │ ▼ Amazon S3 HTML / CSS / JavaScript │ │ Create Playlist Request ▼ Amazon API Gateway │ ▼ AWS Lambda Node.js │ ▼ Groq API │ ▼ Playlist JSON │ ▼ User Interface

Infrastructure as Code

One of my goals was to avoid manually building the AWS environment through the console.

The infrastructure is described in an AWS CloudFormation YAML template.

This includes:

AWS resources
Permissions
Service connections
API configuration
Stack outputs

This makes the infrastructure part of the project itself.

Instead of manually recreating the environment, it can be provisioned from the template.

Managing Multiple AWS Accounts

For deployment, I used a dedicated AWS CLI profile named account2.

Because multiple AWS accounts were configured on my development machine, I added identity verification to the deployment process.

Before creating or updating resources, the workflow checks the AWS identity being used.

This helped prevent deploying infrastructure to the wrong AWS account.

The deployment process follows this idea:

Verify Account → Deploy Infrastructure → Confirm Outputs

It is a small safeguard, but useful when working across multiple AWS accounts.

What I Learned

Building VibePlaylist AI gave me practical experience with the complete lifecycle of a small AI application.

Designing Frontend and Backend APIs

I learned more about designing communication between a frontend and a serverless backend, including:

Sending JSON requests
Handling asynchronous responses
Validating generated data
Managing API errors
Displaying results cleanly

Working with API Gateway and Lambda

The project helped me better understand the serverless model.

Instead of running a Node.js server continuously, the Lambda function is invoked when the application receives a request.

The flow is event-driven:

Request arrives → Lambda runs → AI is called → Response is returned

Infrastructure as Code with CloudFormation

CloudFormation was another important learning experience.

Defining the AWS environment as YAML changed how I think about deployment.

Instead of treating the AWS Console as the place where the application is built, the infrastructure becomes part of the project.

That means it can be:

Versioned
Reproduced
Updated
Deployed consistently

AI Responses Need More Than a Good Prompt

One of the biggest lessons from this project was that the prompt is only one part of an AI application.

A complete application also needs to consider:

Response structure
Data validation
Error handling
API security
Frontend integration
User experience

Generating good output is important.

Making that output reliable and useful inside a real application is equally important.

Keeping the Product Focused

Most importantly, VibePlaylist AI reinforced the idea that a creative AI application does not need dozens of features.

A simple idea, a focused interface, and one useful AI interaction can create an enjoyable experience.

The entire application revolves around one question:

What does this moment sound like?

The user provides the moment.

AI creates the musical direction.

Final Thoughts

VibePlaylist AI is a small experiment in turning everyday moments into musical ideas using generative AI.

A late-night drive, a difficult day, a nostalgic memory, a study session, or any other feeling can become the starting point for a curated playlist.

By combining Groq with AWS serverless services, I built a simple workflow:

Describe Your Moment → Select a Vibe → Generate a Playlist

This project demonstrates how AI can take a simple piece of human input and transform it into a creative experience.

It also gave me more hands-on experience with serverless architecture, API design, structured AI responses, CloudFormation, and secure backend integration.

Sometimes, a creative AI application does not need to do everything.

It only needs to do one thing well.

Try VibePlaylist AI

Live App:
https://d1u2qhbqs932dd.cloudfront.net/

ReplyPilot AI: Generating Email Replies with AI | 10 Days of Building AI Agents on AWS | Day 7

abdullah haroon — Fri, 28 Aug 2026 02:08:00 +0000

10 Days of Building AI Agents on AWS | Day 7

One of the most repetitive tasks in my daily workflow is replying to emails.

Whether it is acknowledging a meeting request, responding to a client, replying to a colleague, or sending a professional follow-up, I often spend more time thinking about how to phrase the message than actually writing it.

To solve this problem, I built ReplyPilot AI, an AI-powered email reply assistant that generates professional email responses within seconds.

Instead of manually drafting every response, users simply:

Paste the email they received
Choose the desired tone
Generate a polished AI reply

The application also keeps a history of generated replies, allowing users to revisit previous responses without generating the same reply again.

The Problem

Writing an email is usually not technically difficult.

The difficult part is deciding how to write it.

Questions such as these can slow down even a simple reply:

How formal should I be?
Should I sound friendly or strictly professional?
How do I politely decline?
How should I follow up?
How can I acknowledge a request professionally?
What is the best way to phrase my response?

These small decisions happen repeatedly throughout the day.

ReplyPilot AI was built to reduce that friction.

The goal is simple:

Received Email → Select Tone → AI Generates Reply

Instead of starting from a blank page, the user receives a polished draft within seconds.

What ReplyPilot AI Does

ReplyPilot AI is a web application that uses generative AI to create professional email replies.

Users provide the received email and select a desired writing style or tone.

The AI analyzes the content and generates an appropriate response.

The application allows users to:

Paste a received email
Choose a writing tone
Generate a professional reply
Copy the generated response
Browse previously generated replies
Revisit reply history
View simple usage statistics

Every generated reply is stored in Amazon DynamoDB.

This provides a searchable history and prevents users from losing previous AI-generated drafts.

The application also tracks statistics such as:

Total replies generated
Processed emails
Application usage

How I Built It

I wanted the application to be:

Lightweight
Serverless
Responsive
Scalable
Inexpensive to operate

Frontend

The frontend was developed using:

React
Vite

The interface allows users to generate replies, browse previous replies, and view application statistics.

Backend

The backend is built using:

Node.js
Express
serverless-http
AWS Lambda

Express runs inside AWS Lambda using serverless-http, allowing the API to operate in a serverless environment.

The frontend communicates with the backend through Amazon API Gateway.

AI Generation

For AI inference, I integrated the Groq API.

The Lambda backend sends the received email and selected tone to the AI.

Groq generates a professional response based on that context.

The workflow is:

Received Email
       ↓
Choose Tone
       ↓
React Frontend
       ↓
Amazon API Gateway
       ↓
AWS Lambda
Express.js Backend
       ↓
Groq API
       ↓
Generated Reply
       ↓
Amazon DynamoDB
       ↓
Reply History

AWS Architecture

ReplyPilot AI uses a fully serverless AWS architecture.

The main AWS services used are:

AWS Amplify
AWS Lambda
Amazon API Gateway
Amazon DynamoDB
AWS CloudFormation
AWS SAM
Amazon CloudWatch

The overall architecture is:

User
        │
        ▼
AWS Amplify
React Frontend
        │
        ▼
Amazon API Gateway
        │
        ▼
AWS Lambda
Express API
        │
   ┌────┴────┐
   ▼         ▼
Groq API   Amazon DynamoDB
   │         │
   └────┬────┘
        ▼
Generated Reply and History

How the Workflow Works

The complete workflow follows these steps:

The user opens ReplyPilot AI on AWS Amplify.
The user pastes the email they received.
The user selects the desired tone.
The React frontend sends the request to Amazon API Gateway.
API Gateway invokes AWS Lambda.
Lambda processes the request through the Express backend.
Lambda sends the prompt to the Groq API.
Groq generates a professional email reply.
The generated reply is returned to the frontend.
The reply is also stored in Amazon DynamoDB.
The user can later access the reply from the history section.

This creates a simple but useful workflow:

Email → AI → Professional Reply → Stored History

Infrastructure as Code

The backend infrastructure is managed using:

AWS SAM
AWS CloudFormation

Instead of manually creating resources through the AWS Console, the infrastructure is defined as code.

This makes the deployment:

Repeatable
Easier to reproduce
Easier to update
More consistent

The complete serverless backend can be recreated through the deployment workflow.

Challenges I Faced

Building ReplyPilot AI involved several deployment and infrastructure challenges.

CloudFormation Parameter Validation

One of the early issues involved CloudFormation parameter validation.

Infrastructure templates must match expected configurations precisely, and incorrect parameter definitions can prevent deployments before the application even starts.

This helped me better understand the importance of validating infrastructure configuration.

Lambda Configuration Problems

I also encountered Lambda configuration issues during deployment.

These required reviewing the function settings and ensuring the deployed environment matched what the application expected.

API Gateway Routing Issues

Another challenge involved API Gateway routing.

The frontend and backend both worked individually, but requests needed to be correctly routed from API Gateway to the Express application running inside Lambda.

Debugging this helped me understand how API Gateway and Lambda integrate in a serverless API.

Out of Memory Error

After deployment, I encountered an out-of-memory error.

The application required adjustments to its Lambda memory configuration during testing.

Using logs and deployment tools, I identified the issue, updated the configuration, and redeployed successfully.

This was an important reminder that serverless applications still require resource planning.

Even though there are no servers to manage, memory and runtime configuration still directly affect application performance.

Debugging with CloudWatch

One of the most valuable tools during development was Amazon CloudWatch.

CloudWatch logs helped me diagnose Lambda runtime issues and understand what was happening after deployment.

When something worked locally but failed in the cloud, logs provided the information needed to investigate the actual serverless execution environment.

The development workflow involved:

Deploy → Test → Check CloudWatch Logs → Identify Issue → Update Configuration → Redeploy

This gave me practical experience debugging production-style serverless applications.

What I Learned

Building ReplyPilot AI gave me hands-on experience with several AWS services and modern application development concepts.

AWS Serverless Development

I gained practical experience using:

AWS Lambda
Amazon API Gateway
Amazon DynamoDB
AWS Amplify

These services work together to create a complete application without managing traditional servers.

Infrastructure as Code

Using AWS SAM and CloudFormation helped me understand the value of defining infrastructure as code.

Resources can be deployed consistently instead of manually recreating them through the AWS Console.

Connecting Frontend and Serverless Backend

I learned more about connecting a modern React application with a serverless backend.

The flow between Amplify, API Gateway, Lambda, and DynamoDB became a complete end-to-end application architecture.

Debugging Serverless Applications

CloudWatch logs, AWS SAM, and repeated testing helped me understand how to troubleshoot problems in deployed serverless environments.

Building Around Everyday Problems

Most importantly, this project reinforced a simple lesson:

A small everyday annoyance can become a genuinely useful application.

Writing professional email replies is something many people do every day.

Reducing the time spent drafting them can make a small but meaningful difference.

The application demonstrates how:

AI can automate repetitive communication tasks
Serverless architecture can keep infrastructure simple
DynamoDB can provide persistent reply history
AWS SAM and CloudFormation can make deployments repeatable
CloudWatch can help debug real deployment issues

The core workflow remains simple:

Received Email → Choose Tone → AI Generates Reply → Save to History

Sometimes the most useful AI applications are not the most complicated ones.

They simply remove friction from tasks we already do every day.

Try ReplyPilot AI

Live Demo:
Open ReplyPilot AI

Building DevDigest AI: An Always-On Agent That Prepares Your Daily Developer Briefing | Day 6

abdullah haroon — Wed, 26 Aug 2026 01:57:00 +0000

10 Days of Building AI Agents on AWS | Day 6

Developers live in a world of constant information.

Every day brings new AI models, AWS announcements, cloud updates, open-source releases, developer tools, frameworks, GitHub projects, and learning opportunities.

Access to information has never been easier.

Keeping up with everything, however, has become increasingly difficult.

That is the problem I wanted to solve with DevDigest AI.

DevDigest AI is an always-on AI agent that prepares a daily developer briefing before you even open the app.

Instead of manually visiting multiple websites, checking feeds, and deciding which updates actually matter, the agent works in the background and prepares a concise digest automatically.

The vision behind the project is simple:

The best tool is one that does useful work before you ask it to.

The Vision: Your Developer World, Summarized Every Day

DevDigest AI collects fresh information from reliable developer-focused sources and transforms it into a short, readable daily briefing.

The digest can include important updates from areas such as:

AI
AWS and cloud computing
Open source
Developer tools
Frameworks and technologies
Relevant opportunities

It also includes a Learn Today section that highlights one useful technical concept or topic.

The goal is not to collect as much information as possible.

The goal is to identify what matters and make it easier for developers to stay informed without manually searching through dozens of sources.

Most importantly, the user does not need to press a button to start the process.

Every day, the autonomous workflow runs in the background:

EventBridge wakes the agent
        ↓
The agent collects fresh information
        ↓
Duplicate and low-value items are filtered
        ↓
Recent digests are checked
        ↓
Groq analyzes and summarizes the information
        ↓
The AI response is validated
        ↓
The completed digest is stored
        ↓
The user returns later
        ↓
Today's briefing is already waiting

This is what makes DevDigest AI an always-on AI agent.

It independently gathers information, remembers what it has previously reported, creates a new briefing, and prepares the result before the user returns.

How I Built DevDigest AI

I intentionally kept the architecture simple and serverless.

For the frontend, I chose plain HTML, CSS, and JavaScript instead of introducing a large frontend framework.

The goal was to focus on the autonomous agent rather than add unnecessary complexity.

The frontend retrieves the latest digest from an API and presents it in a clean, developer-focused interface.

For the backend, I used Node.js and AWS Lambda.

The core daily agent is triggered automatically on a schedule.

It performs several tasks:

Collects information from reliable sources
Removes duplicate items
Filters low-value information
Checks previous digests
Selects relevant fresh updates
Sends the selected information to Groq
Validates the AI-generated response
Stores the completed digest

Keeping the AI Grounded in Real Sources

One of my key decisions was to avoid giving the AI unrestricted freedom to invent information.

DevDigest AI provides Groq with collected source material and instructs it to summarize only that information.

The generated response is then validated before it is stored.

This includes checking that generated source URLs correspond to actual collected sources.

The goal is to reduce the risk of the AI:

Inventing news
Creating fake announcements
Adding events that did not happen
Generating incorrect source links

The AI acts as an analysis and summarization layer rather than an unrestricted source of information.

The workflow looks like this:

Collected Sources → Filtered Information → AI Analysis → Validation → Daily Digest

Lightweight Agent Memory with DynamoDB

DevDigest AI also has a lightweight form of memory.

Before generating a new briefing, the system checks recent digests stored in Amazon DynamoDB.

This gives the agent context about what it has already reported.

For example, if an important AI announcement was already included in yesterday's digest, the agent can avoid repeatedly presenting the same update unless there is meaningful new information.

This helps:

Reduce repetition
Provide more variety
Prioritize genuinely new information
Give the agent context about previous outputs

I deliberately did not use a vector database or a complex agent framework.

For this project's requirements, recent digest history in DynamoDB provides a simpler and more appropriate memory mechanism.

Not every AI agent needs complex memory. Sometimes recent structured history is enough.

AWS Services and Architecture

I used AWS SAM (Serverless Application Model) to define and deploy the infrastructure as code.

The main services used are:

AWS SAM for serverless infrastructure and deployment
Amazon EventBridge to automatically wake the agent every day
AWS Lambda to run the daily agent and backend API logic
Amazon DynamoDB to store daily digests and provide lightweight memory
AWS Secrets Manager to securely store the Groq API key
Amazon API Gateway to expose backend endpoints to the frontend
Amazon S3 to host the static HTML, CSS, and JavaScript frontend
Amazon CloudWatch for logs and monitoring

The architecture follows this flow:

EventBridge Schedule
        ↓
DevDigest Daily Agent
AWS Lambda
        ↓
Reliable RSS Feeds and APIs
        ↓
Filter and Deduplicate Information
        ↓
Check Recent Digests
Amazon DynamoDB
        ↓
Retrieve Groq API Key
AWS Secrets Manager
        ↓
Groq AI Analysis and Summarization
        ↓
Validate AI Output
        ↓
Store Daily Digest
Amazon DynamoDB
        ↓
API Gateway + Lambda
        ↓
HTML, CSS and JavaScript Frontend
Amazon S3

Infrastructure as Code with AWS SAM

I used AWS SAM because I wanted the infrastructure to be reproducible.

Instead of manually creating resources through the AWS Console, the infrastructure is defined and deployed as code.

The project includes:

Serverless infrastructure definitions
Automated deployment scripts
Resource configuration
IAM permissions
API configuration
Account verification before deployment

The deployment workflow verifies the currently authenticated AWS account before making infrastructure changes.

This helps ensure that the project is deployed only to the intended AWS account.

Challenges and Key Decisions

Automation vs Information Quality

One of the biggest challenges was balancing automation with information quality.

An autonomous agent should not simply collect everything it finds.

That would recreate the same information overload the project is designed to solve.

To address this, the workflow focuses on:

Collecting a limited number of reliable items
Removing duplicates
Preferring newer information
Filtering low-value items
Using recent digests as memory

The goal is not more information.

The goal is better information.

Preventing AI Hallucinations

Another important challenge was preventing the AI from inventing information.

The agent must not create fake news, events, announcements, or source links.

For this reason:

Information is collected first.
The AI receives the collected source material.
The AI is instructed to summarize only that material.
The generated response is validated.
Source URLs are checked against the collected source data.
Only validated output is stored.

This makes the system more reliable than simply asking an AI model to tell the user what happened today.

Keeping the Architecture Affordable

I also wanted to keep the architecture simple and affordable.

Serverless services allow the application to run without maintaining an always-running server.

The daily workload is event-driven.

The infrastructure performs work when the agent is scheduled to run rather than continuously consuming resources.

This makes serverless architecture a good fit for an autonomous agent that performs a scheduled daily task.

What I Learned

Building DevDigest AI taught me several important lessons about AWS and autonomous systems.

Event-Driven Serverless Architecture

I gained hands-on experience with an architecture where Amazon EventBridge triggers work automatically without user interaction.

A scheduled event can completely change how an AI application works.

Instead of:

User opens app → User asks → AI responds

The workflow becomes:

Schedule → Agent wakes up → Information is collected → AI analyzes → Result is stored → User discovers it later

Infrastructure as Code

I learned more about using AWS SAM and infrastructure as code to define and deploy cloud resources consistently.

Instead of treating infrastructure as a collection of manually created services, I could define the system as code and reproduce the deployment.

Simple Agent Memory

Another important lesson was that an agent does not always need a complicated framework or vector database.

For DevDigest AI, DynamoDB provides memory by allowing the system to review recent outputs before creating something new.

The memory is simple, but it directly supports the agent's purpose.

Validating AI Output

AI is powerful for summarization and analysis, but external information should be handled carefully.

Restricting the AI to collected source material and validating its final response makes the system more reliable.

This was one of the most important design decisions in the project.

Thinking Beyond Reactive AI

Finally, this project helped me think differently about AI applications.

Many AI applications are reactive.

The user opens an app and asks the AI to do something.

But an always-on agent can work proactively.

It can:

Wake up automatically
Collect information
Review its previous outputs
Analyze new data
Create something useful
Prepare the result before the user asks

That changes the relationship between the user and the application.

Final Thoughts

DevDigest AI is my experiment in building an autonomous developer intelligence agent.

Every day, it wakes up automatically, remembers what it has already reported, collects fresh information, filters duplicates, analyzes relevant updates, validates its output, and prepares a new briefing.

The user simply returns to the application.

Today's digest is already waiting.

The core idea behind the project is simple:

AI applications do not always need to wait for the user to start the conversation.

Sometimes, the most useful agent is one that does the work while you are away.

DevDigest AI in One Sentence

DevDigest AI is an always-on AI agent that wakes up every day, remembers recent developer updates, collects and analyzes fresh information, and prepares a new developer briefing before you even open the application.

Try DevDigest AI

Live App:
Open DevDigest AI

Building Meeting2Tasks: Turning Meeting Conversations into Actionable Tasks with AI and AWS | 10 Days of Building AI Agents on AWS | Day 5

abdullah haroon — Mon, 24 Aug 2026 01:40:00 +0000

10 Days of Building AI Agents on AWS | Day 5

Meetings are essential for collaboration, but they often create another problem: someone has to spend time reviewing notes, writing summaries, extracting action items, and documenting key decisions.

Whether it is a team stand-up, client discussion, or project planning session, this repetitive work can sometimes take almost as long as the meeting itself.

To solve this problem, I built Meeting2Tasks, an AI-powered web application that automatically transforms meeting transcripts into structured summaries, actionable tasks, key decisions, risks, and unanswered questions.

Instead of manually organizing notes after every meeting, users simply paste their meeting transcript, and the application does the rest in seconds.

The Problem

One of the most repetitive tasks in project management is documenting meetings.

After almost every meeting, someone needs to:

Read through lengthy meeting notes or transcripts
Summarize the discussion
Identify action items
Record important decisions
Highlight project risks
Capture unanswered questions
Save everything so it can be reviewed later

This process is repetitive, time-consuming, and can result in inconsistent documentation.

I wanted to build a tool that could eliminate much of this manual work while producing structured and consistent results.

What Meeting2Tasks Does

Meeting2Tasks is a web application designed to automate meeting documentation.

Users simply:

Paste a meeting transcript
Click Analyze
Let AI process the conversation
Receive structured insights

The application generates:

A concise meeting summary
Actionable tasks
Important decisions
Identified risks
Open questions

Once the analysis is complete, the application stores the meeting and its generated insights in Amazon DynamoDB.

Users can revisit previous meetings whenever needed, while the dashboard provides statistics and access to meeting history.

The result is a faster and more organized workflow for teams that regularly conduct meetings.

How It Works

The workflow is straightforward:

Meeting Transcript → AI Analysis → Structured Insights → Stored Meeting History

When a user submits a transcript, the application sends it through the backend for AI analysis.

The Groq API processes the meeting content and returns structured results.

These results are then stored in DynamoDB for future access.

User submits transcript
        │
        ▼
React + Vite Frontend
        │
        ▼
Amazon API Gateway
        │
        ▼
AWS Lambda
        │
   ┌────┴─────┐
   ▼          ▼
Groq API   DynamoDB
   │          │
   └────┬─────┘
        ▼
Structured Meeting Insights

How I Built It

The application consists of a React frontend and a serverless backend running on AWS.

Frontend

The frontend was developed using:

React
Vite

This provides a fast and responsive interface for submitting transcripts, viewing results, and accessing previous meetings.

The frontend communicates with a REST API exposed through Amazon API Gateway.

Backend

The backend uses:

Express.js
Node.js
AWS Lambda

The Express.js application runs inside AWS Lambda, allowing the backend to scale automatically without managing traditional servers.

When a user submits a transcript, the backend processes the request and sends the transcript to the Groq API.

The AI then generates structured insights including summaries, tasks, decisions, risks, and open questions.

The processed results are stored in Amazon DynamoDB.

Deployment

The frontend is deployed using AWS Amplify.

The backend infrastructure is built and deployed using AWS SAM, which helps define and manage the serverless application.

Using this architecture allowed me to focus more on building the application instead of managing servers and infrastructure manually.

AWS Services Used

AWS Amplify

Used to host and deploy the React frontend.

This makes the application publicly accessible and simplifies frontend deployment.

Amazon API Gateway

Provides REST API endpoints connecting the frontend with the backend.

AWS Lambda

Runs the Express.js backend in a serverless environment.

The backend executes when requests arrive without requiring an always-running server.

Amazon DynamoDB

Stores:

Meeting records
AI-generated summaries
Action items
Decisions
Risks
Open questions

This allows users to revisit and manage previous meeting results.

AWS SAM

AWS Serverless Application Model was used to:

Define the backend infrastructure
Build the serverless application
Test deployments
Deploy Lambda and API resources

Groq API

Groq handles the AI analysis.

It transforms raw meeting transcripts into structured and actionable insights.

Architecture Overview

The complete architecture looks like this:

                         User
                           │
                           ▼
                 React + Vite Frontend
                           │
                           ▼
                     AWS Amplify
                           │
                           ▼
                  Amazon API Gateway
                           │
                           ▼
               AWS Lambda (Express.js)
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
              Groq API         Amazon DynamoDB
                 │                   │
                 └─────────┬─────────┘
                           ▼
            AI Analysis and Stored Meetings

The workflow starts whenever a user submits a meeting transcript through the web application.

The backend handles the AI request, processes the response, stores the relevant data, and returns structured results to the user.

Challenges I Faced

Like most real-world projects, building Meeting2Tasks involved several technical challenges.

Running Express.js with AWS Lambda

One of the biggest challenges was integrating an Express.js application with AWS Lambda while ensuring API Gateway correctly routed requests.

This required understanding how a traditional web framework could work inside a serverless execution environment.

DynamoDB Reserved Attribute Names

I also encountered issues with DynamoDB because some attribute names conflicted with reserved words.

This required modifying database queries and expressions to avoid those conflicts.

It was a useful reminder that database design and query syntax need careful attention, even in serverless applications.

Deployment to the Wrong AWS SAM Stack

Another significant challenge involved deployment.

During debugging, I discovered that updates were being deployed to the wrong AWS SAM stack.

This caused new API routes not to appear in production, even though everything worked correctly locally.

After identifying the stack configuration issue and deploying to the correct stack, all endpoints functioned as expected.

This experience helped me better understand:

Serverless deployments
Stack configuration
Production debugging
The difference between local and deployed environments

What I Learned

Building Meeting2Tasks gave me valuable hands-on experience with modern serverless application development.

Some of the key things I learned include:

Building Serverless APIs

How to build REST APIs using AWS Lambda and API Gateway without managing traditional servers.

AWS SAM Deployments

How AWS SAM can simplify building, testing, and deploying serverless applications.

Hosting React Applications

How AWS Amplify can be used to deploy and host a modern React frontend.

Serverless Architecture Design

How services such as API Gateway, Lambda, and DynamoDB can work together as a complete backend architecture.

Integrating External AI

How to connect an external AI service such as Groq with an AWS-based application.

Debugging Deployments

How configuration mistakes, stack selection, and deployment environments can cause production issues even when an application works locally.

Persistent Data with DynamoDB

How DynamoDB can store application data and make AI-generated results available for future use.

Why This Matters

The main idea behind Meeting2Tasks is simple.

Teams should spend more time making decisions and completing important work, not repeatedly documenting conversations.

AI can help automate the repetitive part.

Instead of manually reviewing a long transcript, users can receive structured information within seconds.

Transcript → Summary → Tasks → Decisions → Risks → Questions

This does not replace the meeting itself. It reduces the administrative work that follows it.

Final Thoughts

Meeting2Tasks started with one simple problem: manually documenting meetings is repetitive and time-consuming.

By combining AI with serverless AWS technologies, I built an application that transforms lengthy meeting transcripts into structured, actionable insights within seconds.

The project demonstrates how AI can help eliminate repetitive work while allowing teams to focus more on making decisions instead of documenting them.

It also showed me how services such as AWS Lambda, API Gateway, DynamoDB, Amplify, and SAM can work together with an external AI provider to build a scalable application.

Source Code and Live Application

GitHub Repository:
Meeting2Tasks on GitHub

Live Application:
Open Meeting2Tasks

Building VerseCraft AI: Turning Ideas and Emotions Into Original Poems | 10 Days of Building AI Agents on AWS | Day 4

abdullah haroon — Fri, 21 Aug 2026 19:00:00 +0000

Building VerseCraft AI: Turning Ideas and Emotions Into Original Poems

10 Days of Building AI Agents on AWS | Day 4

Tag: #creative-expression

VerseCraft AI transforms simple ideas, emotions, memories, and thoughts into original poems using generative AI.

The project combines Groq with a serverless AWS architecture to explore how a focused creative experience can bring together AI, web development, and cloud services.

Vision and What the App Does

What if you could turn a simple thought, feeling, memory, or idea into a poem in seconds?

That was the idea behind VerseCraft AI, a simple AI-powered creative writing application.

Instead of asking users to write a complete poem themselves, VerseCraft lets them provide a simple idea and choose a mood. The application then transforms that input into an original poem.

For example, a user can enter:

"A lonely person watching the rain from a rooftop at midnight."

They can then select a mood such as:

Emotional
Romantic
Sad
Inspirational
Dark
Peaceful
Funny

After clicking Generate Poem, VerseCraft creates a title and an original poem inspired by the user's idea and selected mood.

The goal was not to build a complicated AI platform.

I wanted to create one focused creative experience that is simple to understand, enjoyable to use, and produces something people can share.

The generated poem is displayed in a clean, artistic interface with options to copy the poem and generate another one.

The application is designed to make creative writing feel accessible, even when someone does not know where to start.

How I Built It

I decided early that I wanted to keep the application focused and avoid unnecessary complexity.

There are no:

User accounts
Databases
Payment systems
Complicated dashboards

The entire application revolves around one simple interaction:

Idea → Mood → AI → Poem

The frontend was built using HTML, CSS, and JavaScript.

I wanted the interface to feel more like a small digital writing studio than a traditional AI dashboard, so I focused on a minimal design with a black, white, and yellow or gold visual theme.

AI Generation with Groq

For AI generation, I used the Groq API.

The backend receives the user's idea and selected mood and sends them to the AI with a carefully designed prompt.

The prompt instructs the model to generate:

A suitable title
An original poem
A structured response that the frontend can display cleanly

The generation flow is:

User Idea → Selected Mood → Backend → Groq AI → Generated Poem

One important decision was to keep the Groq API key completely away from the frontend.

The browser communicates with the backend API instead of communicating directly with Groq.

This prevents the API key from being exposed in client-side JavaScript.

Serverless Backend

The backend uses Node.js running on AWS Lambda.

When a user requests a poem:

The user enters an idea and selects a mood.
The frontend sends the request to API Gateway.
API Gateway invokes AWS Lambda.
Lambda processes the input.
Lambda securely calls the Groq API.
Groq generates the poem.
Lambda returns the structured result.
The frontend displays the poem.

User
  │
  ▼
Frontend
  │
  ▼
API Gateway
  │
  ▼
AWS Lambda
  │
  ▼
Groq API
  │
  ▼
Poem JSON
  │
  ▼
Frontend displays poem

AWS Services Used and Architecture

VerseCraft AI uses several AWS services:

Amazon S3 for storing and hosting the static frontend files, including HTML, CSS, and JavaScript.
Amazon CloudFront for delivering the frontend globally through a CDN and providing HTTPS.
Amazon API Gateway for providing the public API endpoint used by the frontend.
AWS Lambda for running the serverless Node.js backend that communicates with Groq.
AWS IAM for providing permissions and execution roles required by AWS services.
AWS CloudFormation for defining and provisioning infrastructure using YAML.

The overall architecture is:

                         USER
                           │
                           ▼
                    ┌──────────────┐
                    │  CloudFront  │
                    │ HTTPS / CDN  │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │      S3      │
                    │ HTML/CSS/JS  │
                    └──────────────┘

       User clicks "Generate Poem"
                           │
                           ▼
                    ┌──────────────┐
                    │ API Gateway  │
                    │POST /generate│
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │    Lambda    │
                    │   Node.js    │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   Groq API   │
                    │ Generative AI│
                    └──────┬───────┘
                           │
                           ▼
                       POEM JSON

CloudFormation ties the AWS infrastructure together and makes deployment reproducible.

Instead of manually creating every AWS resource, the infrastructure can be provisioned from a YAML template.

This serverless architecture also means there is no always-running application server to maintain.

The backend runs when requests arrive, making the architecture a good fit for a focused creative application.

Why I Kept It Simple

A key decision behind VerseCraft AI was to focus on one experience and do it well.

It would have been easy to add:

User profiles
Saved poem collections
Social features
Multiple dashboards
Complex AI settings
Payment systems

But none of those were necessary for the core idea.

The most important workflow is simply:

A person has an idea. AI helps turn that idea into something creative.

Keeping the application focused allowed me to concentrate on the experience and the underlying serverless architecture.

What I Learned

Building VerseCraft AI gave me the opportunity to combine several areas I had been learning separately into one complete application.

Connecting AI to a Frontend

It is easy to call an AI API from a simple script.

Building the complete flow is different.

I had to think about:

Browser requests
API design
Request formats
Error handling
Structured AI responses
Backend security

The complete flow became:

Browser → API Gateway → Lambda → Groq → Lambda → Browser

Serverless Backend Development

I learned more about how AWS Lambda and API Gateway can create a backend without maintaining a traditional server.

The application only runs backend code when a request arrives.

Infrastructure as Code

Using CloudFormation made me think about AWS infrastructure as a complete system rather than a collection of resources manually created through the AWS Console.

Defining resources, permissions, dependencies, and outputs in YAML makes deployments easier to reproduce.

Simple AI Experiences Can Still Be Useful

One of my biggest takeaways was that a creative AI application does not need to be complicated to be useful.

The most important part of VerseCraft AI is the experience:

Give someone a blank box, let them express an idea, and turn that idea into something creative.

Final Thoughts

VerseCraft AI is a small experiment in combining creative expression, generative AI, and serverless AWS infrastructure.

The core idea is simple:

Idea → Mood → AI → Poem

Sometimes, a focused application can create a better experience than a feature-heavy platform.

VerseCraft AI gives users a simple starting point. They bring an idea, feeling, memory, or even just one sentence, and the AI helps transform it into something creative.

Try VerseCraft AI

Live App:
Open VerseCraft AI

If you have an idea, a feeling, a memory, or simply a sentence in your head, give it to VerseCraft AI and see where it takes you.

Building StoryForge: An Always-On AI Agent That Creates a New Story | 10 Days of Building AI Agents on AWS | Day 3

abdullah haroon — Fri, 21 Aug 2026 01:26:05 +0000

Building StoryForge: An Always-On AI Agent That Creates a New Story Every Day

10 Days of Building AI Agents on AWS | Day 3

Tag: #agents

What if your creative app didn't wait for you to open it?

That was the idea behind StoryForge, an always-on AI storytelling agent that creates a brand-new story every day before you even visit the application.

Traditional AI writing tools are reactive. You open a website, enter a prompt, choose some options, and ask the AI to generate something.

StoryForge takes a different approach.

It works in the background as an autonomous creative agent.

Every day, it:

Wakes up automatically
Remembers what it has created recently
Chooses a new creative direction
Generates a fresh story
Validates the result
Saves it for the user

So when the user comes back, a brand-new story is already waiting.

The user leaves → the agent wakes up automatically → it remembers recent stories → it creates something new → the user returns to discover it.

The Vision

I wanted to build something simple while demonstrating an important idea:

The best creative tool does not always need to wait for instructions.

StoryForge is built around the concept of passive creativity.

Instead of opening an application and asking:

What should I write today?

The user can simply return and discover what the AI agent has already created.

The goal wasn't to build a complicated multi-agent system or a massive AI platform.

I wanted to demonstrate one clear always-on agent workflow.

The agent should:

Act without waiting for the user
Run automatically
Remember recent context
Use that context to influence its next action
Create something new
Have its work ready before the user returns

Lightweight Agent Memory

One challenge with generating stories automatically is repetition.

If the AI receives the same instructions every day, it may repeatedly generate similar genres, themes, settings, or story structures.

To reduce this, StoryForge has a lightweight form of memory.

Before generating a new story, the agent retrieves recent stories from its database, including information such as:

Title
Genre
Theme
Setting
Summary

This recent creative history is provided to the AI as context.

The generation instructions tell the agent to avoid repeating:

Similar premises
Recent genres
Themes
Settings
Story structures

This means StoryForge isn't simply running the exact same prompt every day.

It uses its recent creative history to influence what it creates next.

How StoryForge Works

The entire workflow begins automatically.

Step 1: EventBridge Scheduler wakes up the agent

Every day, Amazon EventBridge Scheduler triggers the story-generation workflow.

The user doesn't need to click a button.

The agent wakes up automatically.

EventBridge Scheduler
        ↓
AWS Lambda
        ↓
Check today's story
        ↓
Retrieve recent memory
        ↓
Generate a new story with Groq
        ↓
Validate response
        ↓
Save to DynamoDB
        ↓
Story is ready for the user

Step 2: Check for duplicate generations

The Lambda function first checks whether a story has already been generated for the current day.

This makes the workflow idempotent and prevents:

Duplicate stories
Unnecessary AI API calls
Extra costs
Multiple executions creating conflicting data

Step 3: Retrieve recent stories from DynamoDB

The agent retrieves recently generated stories from Amazon DynamoDB.

These stories act as the agent's lightweight memory.

For StoryForge, I didn't need a vector database or complex memory architecture.

The last few stories provide enough information for the AI to understand what it has recently created and move in a different creative direction.

Step 4: Generate a fresh story with Groq

The Lambda function sends the generation request to the Groq API.

Groq acts as the creative AI engine, while AWS handles the infrastructure, automation, storage, and security surrounding the agent.

The AI returns a structured story containing:

Title
Genre
Theme
Setting
Summary
Full story
Moral

The Lambda validates the response before saving it.

If the AI returns malformed or incomplete data, the system handles the failure safely instead of storing corrupted information.

AWS Architecture

The architecture is intentionally simple and serverless:

EventBridge Scheduler
        ↓
AWS Lambda
        ↓
Amazon DynamoDB
        ↓
Groq API
        ↓
Amazon DynamoDB
        ↓
API Gateway
        ↓
Static HTML, CSS and JavaScript
        ↓
Amazon S3

AWS Services Used

AWS Lambda: Autonomous story-generation agent and backend API logic
Amazon DynamoDB: Story storage and lightweight memory
Amazon EventBridge Scheduler: Automatically wakes the agent every day
Amazon API Gateway HTTP API: Connects the frontend with the backend
AWS Secrets Manager: Securely stores the Groq API key
Amazon S3: Hosts the static frontend
Amazon CloudFormation: Infrastructure as Code and automated deployment
Amazon CloudWatch Logs: Monitoring and debugging

Security

The Groq API key is never exposed in the frontend or committed to source code.

It is securely stored in AWS Secrets Manager, and Lambda retrieves it using IAM permissions following the principle of least privilege.

Frontend
    No API Key
        ↓
API Gateway
        ↓
Lambda
        ↓
AWS Secrets Manager
        ↓
Groq API

Why HTML, CSS, and Vanilla JavaScript?

I deliberately kept the frontend simple.

The goal wasn't to demonstrate a complex frontend framework. The focus was on the autonomous AI agent architecture.

The frontend only needs to:

Display today's story
Browse previous stories
View individual stories
Communicate with the backend API

HTML, CSS, and vanilla JavaScript were enough.

This allowed me to focus on:

Automation, Memory, AI, and Serverless Architecture

Challenges and Key Decisions

The biggest challenge was balancing the idea of an AI agent with the need to keep the project simple.

It would have been easy to add:

Vector databases
Complex agent frameworks
Multiple AI models
Several interacting agents

But those additions weren't necessary for this use case.

Instead, I focused on the essential characteristics of an always-on agent:

It acts without waiting for the user.
It runs on a schedule.
It remembers recent context.
It uses that context to influence its next action.
It creates something new.
Its output is ready when the user returns.

Why DynamoDB Was Enough for Memory

A major lesson from this project was that not every AI agent needs a complex memory system.

For StoryForge, the agent only needs to know what it created recently.

Retrieving recent:

Titles
Genres
Themes
Settings
Summaries

provides enough context to encourage creative variety.

Sometimes the simplest memory architecture is the one that best fits the problem.

What I Learned

Building StoryForge helped me better understand:

Serverless Architecture

How Lambda, API Gateway, DynamoDB, and S3 can work together to create a complete application without managing servers.

Event-Driven Automation

How EventBridge Scheduler can transform a traditional reactive AI application into an always-on system.

Instead of:

User → Request → AI → Result

The workflow becomes:

Schedule → Agent → Memory → AI → Storage → User discovers the result

The user is no longer responsible for initiating every action.

Lightweight Agent Memory

Not every agent needs a vector database or complicated retrieval system.

For StoryForge, DynamoDB provides enough recent context to influence future generations.

Infrastructure as Code

CloudFormation makes infrastructure deployment more repeatable and consistent while reducing manual configuration.

Secure AI Integration

AWS Secrets Manager keeps the Groq API key away from the frontend and source code, while IAM controls access.

What's Next?

StoryForge currently focuses on one simple promise:

A new story every day.

In the future, I would like to explore allowing the agent to develop a stronger creative identity over time.

It could:

Analyze patterns in previous stories
Experiment with different narrative styles
Track genres it has used most
Explore underused creative directions
Adapt to genres users enjoy

But for now, I intentionally kept the project focused.

Final Thoughts

StoryForge proves that an always-on AI agent doesn't need to be complicated.

Sometimes, all it takes is:

A scheduled event, a little memory, an AI model, storage, and the ability to act while the user is away.

That combination can transform a traditional reactive AI application into something proactive.

The key idea behind StoryForge is simple:

The user doesn't have to ask for creativity every day. The system can create while they're away.

StoryForge in One Sentence

StoryForge is an always-on AI storytelling agent that automatically remembers its recent stories, creates a new one every day using Groq, and saves it with AWS before the user even opens the app.

Try StoryForge

Live App:
Open StoryForge

Building ByteMentor AI: An Always-On Learning Agent with AWS Serverless | 10 Days of Building AI Agents on AWS | Day 2

abdullah haroon — Fri, 24 Jul 2026 05:00:00 +0000

Self-learning has never been easier, yet staying consistent remains one of the biggest challenges. We have access to countless tutorials, courses, documentation, and videos, but deciding what to learn next often becomes a task of its own. Even after choosing a topic, preparing study material, finding practice exercises, and creating revision questions can consume valuable time before any actual learning begins.

I wanted to solve this problem by building ByteMentor AI, an autonomous learning companion that prepares personalized daily learning content before the learner even opens the application.

Instead of functioning as another AI chatbot that waits for user input, ByteMentor proactively generates structured learning sessions on a schedule. Every day, it analyzes the learner's roadmap, determines the next topic, generates a complete lesson with practical examples, coding exercises, quizzes, and revision material, then stores everything so it is immediately available when the learner returns.

The objective was straightforward:

Allow learners to focus on learning instead of planning what to learn.

The Idea

Learning roadmaps have become increasingly popular, but they usually stop after listing topics in order. The learner is still responsible for researching each concept, finding quality resources, and deciding what to study every day.

I wanted to extend the roadmap into something more intelligent.

Instead of simply displaying a list of topics, ByteMentor continuously transforms that roadmap into daily learning sessions. Once a roadmap has been created, the application knows exactly what should come next and prepares everything automatically.

Each generated lesson includes:

Detailed explanation of the topic
Practical coding examples
Hands-on programming exercises
Multiple-choice quiz questions
Learning summary
Productivity tips

When the learner opens the application, today's lesson is already waiting.

System Architecture

                GitHub
                   │
                   ▼
             AWS Amplify
                   │
                   ▼
          React + TypeScript
                   │
                   ▼
            Amazon API Gateway
                   │
                   ▼
              AWS Lambda
        (ByteMentor AI Agent)
           │             │
           ▼             ▼
        Groq API     DynamoDB
           ▲             │
           └──────┬──────┘
                  ▲
                  │
      Amazon EventBridge Scheduler

Each AWS service is responsible for a single part of the workflow, resulting in a scalable and event-driven architecture.

Frontend

The frontend is built using:

React
TypeScript
Vite
Tailwind CSS

The interface allows learners to:

Generate personalized learning roadmaps
View today's lesson
Browse previous lessons
Track learning history

The application is deployed using AWS Amplify, which automatically builds and deploys the frontend directly from GitHub.

Backend

The backend is built using Node.js and AWS Lambda.

Amazon API Gateway exposes REST endpoints that communicate with Lambda functions responsible for handling business logic.

The backend is responsible for:

Reading learning roadmaps
Determining the next lesson
Generating AI content
Saving generated lessons
Retrieving previous learning sessions

Because everything runs inside Lambda, there are no servers to manage, making the application lightweight and cost-effective.

AI Content Generation

ByteMentor integrates with a large language model to generate structured educational content.

Rather than requesting plain text responses, the application prompts the model to return structured JSON, making it easy to render lessons consistently across the interface.

Each lesson contains:

Topic overview
Step-by-step explanation
Code snippets
Practical exercise
Quiz questions
Key takeaways

This approach creates a much richer learning experience than simply displaying AI-generated paragraphs.

Persistent Storage

Amazon DynamoDB stores all generated learning content.

This includes:

Learning roadmaps
Daily lessons
Learning history
Generated quizzes
Coding exercises

Since lessons are stored after generation, learners can revisit previous sessions without requiring the AI model to generate them again.

Making the Agent Autonomous

The defining feature of ByteMentor is that it operates proactively rather than reactively.

Instead of waiting for a user to request a lesson, Amazon EventBridge Scheduler automatically invokes the Lambda function every morning.

The scheduled workflow looks like this:

EventBridge Scheduler
        │
        ▼
AWS Lambda
        │
        ▼
Read learning roadmap
        │
        ▼
Determine today's topic
        │
        ▼
Generate lesson
        │
        ▼
Create coding challenge
        │
        ▼
Generate quiz
        │
        ▼
Store in DynamoDB
        │
        ▼
Lesson ready before user logs in

This means the learner is welcomed with fresh learning content every day without initiating any manual action.

AWS Services Used

The project combines several AWS services into a single serverless workflow.

AWS Amplify
Amazon API Gateway
AWS Lambda
Amazon EventBridge Scheduler
Amazon DynamoDB
Amazon CloudWatch
AWS IAM
AWS SAM

Each service contributes a focused responsibility, making the system easy to maintain and extend.

Development Process

The project began with designing a clean learning workflow rather than focusing solely on AI generation.

The roadmap became the central source of truth for determining future lessons. Once that workflow was established, the backend was designed around AWS Lambda functions capable of generating and storing lessons independently.

The frontend was then built to consume those generated lessons, allowing users to view content without worrying about how or when it was created.

Finally, EventBridge Scheduler transformed the application from an on-demand AI tool into an autonomous learning agent by moving lesson generation to a scheduled background process.

What I Learned

Building ByteMentor provided valuable experience across several AWS services and architectural patterns.

Some of the key takeaways include:

Designing event-driven serverless applications
Building production deployments using AWS SAM
Using Amazon EventBridge Scheduler for background automation
Connecting API Gateway with AWS Lambda
Designing DynamoDB data models
Building structured AI prompts that consistently return machine-readable responses
Separating frontend and backend responsibilities for easier maintenance

More importantly, the project reinforced the idea that AI becomes significantly more useful when it performs work proactively instead of waiting for user requests.

Future Improvements

There are several features I plan to add in future iterations:

Amazon Cognito authentication
Progress tracking and learning analytics
Achievement badges and learning streaks
PDF lesson exports
Voice narration
AI-generated diagrams
Spaced repetition for long-term retention
Multi-user support

These additions will further enhance the personalized learning experience while maintaining the autonomous nature of the platform.

Conclusion

ByteMentor AI demonstrates how serverless AWS services can be combined to create an autonomous learning system that works continuously in the background.

By leveraging AWS Lambda, EventBridge Scheduler, DynamoDB, API Gateway, and Amplify, the application generates personalized learning sessions without requiring user intervention. Instead of deciding what to study every day, learners can simply open the application and begin learning immediately.

Building this project was an excellent opportunity to explore event-driven architectures, serverless development, and AI-powered automation while creating a practical solution to a real productivity problem.

Live Demo

https://main.d2qeklo0lut2is.amplifyapp.com/

GitHub Repository

https://github.com/ABDULLAH408/ByteMentor_AI