DEV Community: Cess Mbugua

Day 17 of 60: I Deployed My First Production AI API and It's Live 24/7 (This Changes Everything)

Cess Mbugua — Tue, 19 May 2026 18:56:52 +0000

Today everything became real.

Every system I've built over the past 16 days lived only on my local machine. The moment I closed my laptop it went offline. n8n Cloud couldn't reach it without ngrok running. No client could access it. I couldn't share it with anyone without being physically present.

Today I fixed that. My AI Agent API is live. 24/7. No laptop required.

## The Gap This Closes

There is a clear line between a developer project and a professional product.

A portfolio of systems that only run locally is a collection of demos. A deployed API that runs 24/7 from a cloud server is a product; something you can hand to a client, link to from your LinkedIn, or build a business on.

Today I crossed that line.

## What Got Deployed

A production-ready FastAPI server combining the capabilities from the last three projects into one unified AI agent API:

Document Q&A endpoint: ask questions against any document
Research endpoint: multi-agent research and report generation
Data analysis endpoint: CSV analysis with AI-generated insights

Deployed to Render's free cloud hosting. Permanently accessible at a real URL. n8n Cloud workflows can now call it directly. Clients can access it. It's in my portfolio.

## What I Learned

requirements.txt: the dependency file that tells cloud platforms what to install. Standard for every Python deployment.

Environment variables in production: storing API keys securely on Render so they are never in code or GitHub. This is non-negotiable in production.

Production start command: the uvicorn command Render uses to start the server. Different from how you run it locally.

Health check endpoint: the GET / endpoint that tells Render your service is alive.

Auto-deploy from GitHub: every time I push new code Render redeploys automatically. Continuous deployment from day one.

*🌐 Live API → https://ai-agent-api-w7uh.onrender.com
🔗 GitHub → https://github.com/mbuguacessy-glitch
*
43 more to go!.

python #fastapi #deployment #render #claudeapi #automation #learninpublic #buildinpublic #100DaysOfCode

Day 15 of 60: I Built a Multi-Agent Research System That Researches, Writes and Reviews Reports in Under 60 Seconds

Cess Mbugua — Mon, 18 May 2026 14:01:00 +0000

Today's build is the most sophisticated thing I've shipped so far.

A single AI call handles one task well. But complex research requires four fundamentally different cognitive tasks; finding information, synthesising it, writing a structured report, and reviewing its quality. Each needs different instructions. Different tools. Different evaluation criteria.

So I stopped using one agent and built three.

## The Real World Problem

When you send a complex research question to a single Claude prompt you get a single pass. The response might be well-written but poorly researched. Or well-researched but poorly structured. Or both good but containing errors nobody checked.

In the real world every high-quality deliverable goes through multiple specialist hands. Research agencies, law firms, consulting firms, and newsrooms all use teams, not because one person cannot do the work, but because specialisation and review produce dramatically better results.

## The Analogy That Made It Click

Think of a newspaper editorial team. When a breaking story comes in three people handle it:

The journalist: gathers facts, interviews sources, finds the data. Does not write the final article.
The writer: takes the journalist's notes and turns them into a polished, structured article. Was not at the scene.
The editor: reads the finished article before it publishes. Checks facts, identifies gaps, suggests improvements. Did not gather or write anything.

Three specialists. Three distinct roles. One final product better than any one of them could produce alone.

## How the System Works

Topic comes in
↓
Researcher Agent: searches the web via Tavily
                   summarises findings
↓
Writer Agent: takes research output
               produces structured written report
↓
Reviewer Agent: reads the report
                 returns quality score + specific improvements
↓
Final reviewed report delivered in under 60 seconds

The cast:

Researcher = The journalist: finds information via Tavily web search
Writer = The writer: turns research into a structured report
Reviewer = The editor: checks quality and flags improvements
Orchestrator = The news desk: coordinates handoffs between agents
Claude = The intelligence powering all three with different instructions
Tavily = The press pass: gives the Researcher access to live web search

## What I Learned

The biggest shift today was thinking in roles not prompts. Every agent has its own identity, its own instructions, and its own output format. The output of each becomes the input of the next.

This is the architecture behind every serious AI product being built in 2026. Content agencies, research firms, legal teams, and marketing departments all need research-to-report pipelines that don't require a human at every step.

**🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

45 more to go.**

ai #multiagent #claudeapi #python #automation #learninpublic #buildinpublic #100DaysOfCode

Day 14 of 60: I Completed RAG and Now I Understand Why It Changes Everything

Cess Mbugua — Sat, 16 May 2026 15:15:25 +0000

Today I finished what I started yesterday. RAG is done. And I finally understand why every serious AI engineer needs to know this.

## Quick Recap: What is RAG?

Retrieval Augmented Generation. Instead of relying purely on what an LLM was trained on, RAG retrieves relevant information from an external knowledge base and passes it to the model as context before generating a response.

The model doesn't need to have been trained on your data. It just needs to be able to read it at the moment you ask.

##: The Complete RAG Pipeline

Documents ingested → chunked into pieces
↓
Each chunk converted into a vector embedding
↓
Embeddings stored in a vector database
↓
User query comes in
↓
Query converted to embedding
↓
Vector database searched for similar chunks
↓
Relevant chunks retrieved
↓
Chunks + query passed to Claude
↓
Claude generates grounded response

## What I Learned

Three concepts that finally clicked today:

Chunking: you can't pass an entire document to an LLM at once. You split it into smaller overlapping pieces so nothing important falls through the gaps.

Vector embeddings: text converted into numbers that capture meaning. Similar concepts end up close together in vector space. That's how the search knows what's relevant.

Grounding: the difference between an AI that guesses and an AI that knows. RAG grounds every response in real retrieved data.

## Why This Changes My Builds

Every automation I've built so far sends data directly in the prompt. RAG means I can now build systems that reference entire company knowledge bases, months of historical data, or hundreds of documents, and still return accurate, grounded responses.

The builds coming next are on a completely different level.

No GitHub link today, pure learning day documented publicly.

46 more to go.

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 13 of 60: Today I Started Learning RAG

Cess Mbugua — Fri, 15 May 2026 18:32:35 +0000

RAG. Retrieval Augmented Generation.

No build today. Just learning. And honestly it was one of the most mind-expanding study sessions since I started this challenge.

What is RAG?

Every AI model I've worked with so far: Claude, GPT, any LLM, has a knowledge cutoff. It knows what it was trained on and nothing else. Ask it about your company's internal documents, your client's data, or anything that happened after training; it has no idea.

RAG fixes that.

Instead of relying purely on what the model was trained on, RAG retrieves relevant information from an external source; a database, a document store, a knowledge base — and passes it to the model as context before generating a response.

The model doesn't need to have been trained on your data. It just needs to be able to read it at the moment you ask.

Why This Changes Everything for Automation

Every automation I've built so far sends data directly to Claude in the prompt. That works for small, structured inputs.

But what about:

A chatbot that answers questions about a company's entire document library?
A support system that references hundreds of past tickets to resolve new ones?
A report generator that pulls from months of historical data?

You can't paste all of that into a prompt. RAG is how you solve that.

What I Learned Today

The core RAG pipeline:

User query
↓
Search knowledge base for relevant chunks
↓
Pass retrieved chunks + query to LLM
↓
LLM generates response grounded in real data

The builds that are coming next are going to be on a completely different level.

No GitHub link today, just a study day documented publicly.

47 more to go.

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 12 of 60: I Built the Final Piece That Completes a Full AI Automation Stack (Zero Human Reporting)

Cess Mbugua — Thu, 14 May 2026 19:27:58 +0000

Today I closed the loop.

Every business running automations eventually faces the same question: what actually happened this week? Someone has to pull data from multiple sources, count the records, write a summary, and send it. For one client that's 30 minutes. For ten clients it's half a day. Every single week.

Today I automated that entirely.

*## What I Built
*
A Python script that:

Connects to Airtable and reads all lead records
Sends the data to Claude with a reporting prompt
Receives a clean written summary report back
Saves it as a timestamped .txt file
Prints it to the terminal

The report includes lead counts by urgency, status breakdowns, key highlights, and recommended next actions. No human involved.

Why This Matters: The Full Stack

**
This was Challenge 5 of 5 in Phase 1. Here's what the complete pipeline looks like:

Challenge 4 → Intake comes in
              Raw client text → Claude extracts → Pydantic validates → Airtable stores

Challenge 5 → Report goes out
              Airtable data → Claude analyses → Written report → saved as .txt

Intake in. Report out. No human touches either end.

## The Analogy That Made It Click

Think of a bank branch manager's end-of-day report. The teller system holds every transaction. Every evening a junior manager spends an hour pulling numbers and writing a summary for the regional director.

What I built is the automated equivalent; a script that reads every record, hands them to Claude who writes the summary in plain English, and delivers the report automatically. Same quality. Every day. Zero manual effort.

The junior manager now spends that hour on something that actually requires human judgement.

What I Learned

Phase 1 is complete. Five challenges. Five scripts. One complete automation stack.

The biggest lesson across all five: the most valuable automations aren't the flashy ones; they're the ones that eliminate the invisible repetitive work nobody talks about but everyone does.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

48 more to go.

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode

Day 11 of 60: I Built a Script That Reads Raw Client Intake Text and Creates Clean CRM Records Automatically

Cess Mbugua — Wed, 13 May 2026 21:02:19 +0000

Every agency hits the same wall. A potential client fills out an intake form. What comes back is a block of unstructured text. Someone has to read it, extract the budget buried in the prose, assess urgency, and manually create a CRM record.

For five clients a week that's an annoyance. For fifty it becomes a part-time job. For a hundred it breaks the business.

So I automated it.

What I Built

A Python script that:

Reads raw intake text exactly as a client types it
Sends it to Claude with a structured extraction prompt
Receives a clean JSON object back
Validates every field with Pydantic
Saves the complete record to Airtable automatically

No human reads the intake. No human creates the CRM entry. A clean lead appears in Airtable ready for follow-up — in seconds.

New Skills This Introduced

Structured extraction prompting
Telling Claude to return only JSON with specific fields, making AI output predictable and parseable.

Pydantic field validation
Catching bad AI output before it corrupts your data, defining exactly what shape the data must be.

@field_validator
Custom rules that fix or reject individual fields e.g. if urgency is not Low/Medium/High, default to Medium.

pyairtable
Writing records to Airtable via API from Python — your CRM integration layer.

glob()
Looping over all files matching a pattern, process 2 intakes or 200 with the same code.

What I Learned

The most valuable thing today wasn't the code, it was the pattern. Unstructured text in. Validated structured data out. Saved to a system of record.

This same pattern applies to support ticket classification, lead qualification, invoice extraction, contract review, and survey analysis. Once you understand it, you can deliver one of the highest-value automations in the market.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

49 more to go.

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode

Day 10 of 60 of learning AI automation in public

Cess Mbugua — Tue, 12 May 2026 17:07:42 +0000

Today I solved a problem that has been sitting in the back of my mind since Day 1.
My n8n workflows and my Python scripts have been living in completely separate worlds. Today I connected them.

## The Problem

I've built powerful automation pipelines in n8n. I've built Python scripts that call Claude directly. But they couldn't talk to each other.

Every time I needed complex data transformation or custom AI logic that n8n couldn't handle natively. I had to build a whole separate system with no connection between the two. Duplicated effort. Disconnected systems. Limited capability.

This is the gap that stops most automation engineers from reaching the next level.

## What I Built

A FastAPI Python server that runs locally and exposes Python logic as HTTP endpoints. My n8n workflows send data to these endpoints via HTTP Request nodes, the same way they call any external API.

Python processes the data
Calls Claude API
Returns a structured JSON response back to n8n

From n8n's perspective, Python is just another API to call.
From Python's perspective, n8n is just a client sending requests.
Both systems stay independent but now work together seamlessly.

## New Skills This Introduced

FastAPI: building a Python web server
@app.post() decorator: creating API endpoints
Pydantic BaseModel — validating incoming request data
uvicorn: running the FastAPI server
HTTP Request node in n8n: calling Python from a workflow
async def: asynchronous function basics

## What I Learned

The biggest mindset shift today was realising that every tool communicates through HTTP. n8n, Make.com, Zapier, they all have HTTP Request nodes. That means any Python logic I wrap in a FastAPI endpoint becomes instantly callable from any automation platform in the world.

I didn't just learn FastAPI today. I learned how to make Python a first-class citizen in any automation stack.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch/ai-webhook-processor

Day 10 of my 60-day public AI automation build challenge. Learning by doing.. every day.

50 more to go.

python #fastapi #n8n #claudeapi #automation #learninpublic #buildinpublic #100DaysOfCode

Day 9 of 60: Today I built something cool and then spent just as long trying to push it to GitHub.

Cess Mbugua — Mon, 11 May 2026 15:51:29 +0000

Today I built something cool and then spent just as long trying to push it to GitHub.
Both experiences taught me something valuable.

## What I Built

An AI Batch Document Classifier: a Python script that scans a folder of documents, sends each one to Claude API, and produces a master JSON report classifying every document by category, urgency, required action, and whether a deadline was mentioned. Urgent documents are surfaced first.

The real world problem it solves: manually reading 30+ documents to triage them takes hours. This script does it in under 60 seconds.

## How the Pipeline Works

**scan_documents()** finds all .txt files in documents/ folder
↓
**read_document()** reads full content of each file
↓
**classify_document()** sends content to Claude API → returns JSON
↓
**json.loads()** converts response into Python dictionary
↓
**save_results()** sorts by urgency → writes master JSON → prints summary

Urgency Levels

urgent | standard | low

## What I Learned About Reading Python Code

Today something clicked that hasn't before: how to read a Python script by sections rather than line by line.

Every professional Python script tells a story:

Imports: what tools the script needs
Functions: what jobs each section does
main(): how all the jobs connect into a pipeline

Reading it section by section instead of trying to understand every line at once made the whole structure suddenly make sense.

The GitHub Struggle Was Real

Pushing to GitHub today was an unexpected lesson in itself. My .env file was committed in the first push but GitHub's push protection blocked it immediately.

What followed was a deep dive into:

git rm --cached, removing files from tracking
git filter-branch, rewriting commit history to scrub secrets
.gitignore, understanding why it needs to be set up correctly before the first commit
Regenerating exposed API keys immediately

Biggest lesson: set up your .gitignore before your first commit. Not after. Before.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch/ai-batch-document-classifier

Day 9 of my 60-day public AI automation build challenge. Learning by doing,
every mistake included.

51 more to go. 🚀

python #claudeapi #automation #learninpublic #buildinpublic #github #100DaysOfCode

Day 8 of 60 and this is me learning AI integration and automation in public

Cess Mbugua — Sat, 09 May 2026 20:04:25 +0000

**Today I called the Claude API from Python for the very first time.

What I Was Learning

The exercise was built around a relatable scenario, an account manager who manually writes weekly performance summaries for 10 clients every Monday. Same structure every week. Only the numbers change.
The goal wasn't to ship a product. The goal was to learn how to connect Python to Claude API and move data through a structured pipeline from start to finish.

What the Exercise Taught Me

The full data pipeline looked like this:

clients.csv → read_client_data() → list of dictionaries
↓
for loop picks up first client
↓
build_prompt() constructs personalised prompt
↓
generate_report() calls Claude API → returns report text
↓
save_report() writes to disk → returns filepath
↓
loop moves to next client
↓
summary printed + results logged to JSON

Three things I will carry into every project from here:

`Path(file).parent': how to make scripts work regardless of where they are run from
client.messages.create(): the exact pattern for calling Claude API in Python
The function-per-job pattern: organising a script into small single purpose functions connected by main().

Why This Feels Like a Milestone

Every workflow I've built in the first 3 days used n8n to handle the Claude API connection visually. Today I learned how to do that same thing in raw Python. No drag and drop. No visual nodes. Just code.

That's a different kind of understanding. And it opens up a completely different level of what I can build next.

Still learning. Still building. One day at a time.

52 more to go.

python #claudeapi #learninpublic #buildinpublic #automation #100DaysOfCode

Day 7 of 60 — today I stopped doing abstract Python challenges and started solving problems I could see myself automating in the real world.

Cess Mbugua — Thu, 07 May 2026 19:09:37 +0000

I'm a student learning AI integration and automation by building one real workflow every day for 60 days.

Day 8 of 60 — today I stopped doing abstract Python challenges and started solving problems I could see myself automating in the real world.

5 challenges. All automation-relevant. All humbling in different ways.

## The 5 Challenges I Tackled Today

### 1. Product Inventory
Building logic that tracks stock levels, flags low inventory, and updates records. Sounds simple until you're handling edge cases — what if a product doesn't exist? What if the quantity goes negative?

2. Processing a Sales Report

Taking raw sales data and transforming it into something meaningful — totals, averages, top performers. This one was a loop and data structure workout.

3. Lead Qualification System

This one hit close to home. Writing logic that scores and qualifies leads based on defined criteria — exactly the kind of thinking that powers the AI workflows I've been building since Day 1, but now in raw Python.

4. Bulk SMS Validator

Validating a list of phone numbers before sending — checking format, length, and country codes. A real lesson in how much can go wrong with raw user input before it even reaches an API.

5. Daily Sales Target Tracker

Tracking progress toward a daily target, calculating percentages, and flagging whether the target is on track or behind. Simple concept, precise execution required.

What Today Taught Me

Every single one of these challenges maps directly to something I could build as a real automation workflow. The inventory tracker becomes a stock alert pipeline. The lead qualifier becomes an AI scoring system. The SMS validator becomes a data cleaning step before a bulk messaging workflow.

Python isn't separate from the automation work — it's the engine underneath it.

Where This is Heading

Once I'm confident writing Python scripts for these kinds of problems, the next step is connecting them to APIs, databases, and AI models. That's when the real automation work begins.

52 more to go.

python #automation #learninpublic #buildinpublic #ai

Day 6 of 60 — and today Python stopped being theory.

Cess Mbugua — Wed, 06 May 2026 19:53:59 +0000

No new concepts today. Instead I sat down with real life challenges built around everything I've learned so far: variables, data types, operators, strings, lists, functions, loops, classes, objects, inheritance, exception handling and file handling.

And that's where it got interesting.

Why Real Life Challenges Hit Different

Reading about Python concepts and actually applying them to solve a problem are two completely different things. The moment you're staring at a challenge with no step-by-step guide, your brain has to start making decisions:

Which data structure fits this problem?
Where does a loop make sense vs a function?
What could go wrong and where do I hane it?

That gap between knowing and doing is where real learning lives.

What the Challenges Revealed

The basics I thought I understood looked different under pressure. Stringing multiple concepts together in one solution, a function that reads a file, handles exceptions, processes a list and returns a result — exposed exactly which parts I actually understood and which parts I just recognised.

Recognising syntax and writing working code from scratch are not the same thing. Today made that very clear.

Why This Matters for AI Automation

Every Python automation script I will write from here will be a real life challenge. APIs fail. Data comes in messy. Logic needs to be airtight. Solving structured problems now is the exact training ground for writing automation scripts that actually work in production.

Theory is done. The real work has started.

54 more to go.

python #learninpublic #buildinpublic #ai #automation #100DaysOfCode

Day 4 of 60 — and today I put the workflows down and picked up Python.

Cess Mbugua — Tue, 05 May 2026 14:52:11 +0000

No build today. Just fundamentals. And honestly? It humbled me in the best way.

Why Python?

Every automation I've built so far has relied on no-code/low-code tools like n8n to handle the logic. But I kept hitting moments where I thought , if I knew Python, I could do this faster, cleaner, and with more control. So I decided to fix that.

And then I hit Exception Handling and File Handling and that's where things got real.

For someone coming from a workflow automation background where errors are just red nodes on a canvas, handling them in raw code requires a completely different mental model.

I'm not through it yet. But I'm in it.

Why This Matters for AI Automation

Python is the backbone of serious AI integration work. Every API wrapper, every data transformation, every custom agent , it's Python underneath. Learning it properly now means the workflows I build from Day 10 onwards will be on a completely different level.

No GitHub link today — just a honest study day documented publicly.

This is what Day 4 looks like. Not every day is a finished product and that's okay.

56 more to go.

DEV Community: Cess Mbugua

Day 17 of 60: I Deployed My First Production AI API and It's Live 24/7 (This Changes Everything)

Today everything became real.

python #fastapi #deployment #render #claudeapi #automation #learninpublic #buildinpublic #100DaysOfCode

Day 15 of 60: I Built a Multi-Agent Research System That Researches, Writes and Reviews Reports in Under 60 Seconds

ai #multiagent #claudeapi #python #automation #learninpublic #buildinpublic #100DaysOfCode

Day 14 of 60: I Completed RAG and Now I Understand Why It Changes Everything

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 13 of 60: Today I Started Learning RAG

What is RAG?

Why This Changes Everything for Automation

What I Learned Today

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 12 of 60: I Built the Final Piece That Completes a Full AI Automation Stack (Zero Human Reporting)

Why This Matters: The Full Stack

What I Learned

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode

Day 11 of 60: I Built a Script That Reads Raw Client Intake Text and Creates Clean CRM Records Automatically

What I Built

New Skills This Introduced

What I Learned

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode

Day 10 of 60 of learning AI automation in public

python #fastapi #n8n #claudeapi #automation #learninpublic #buildinpublic #100DaysOfCode

Day 9 of 60: Today I built something cool and then spent just as long trying to push it to GitHub.

Urgency Levels

Reading it section by section instead of trying to understand every line at once made the whole structure suddenly make sense.

The GitHub Struggle Was Real

python #claudeapi #automation #learninpublic #buildinpublic #github #100DaysOfCode

Day 8 of 60 and this is me learning AI integration and automation in public

**Today I called the Claude API from Python for the very first time.

** What I Was Learning**

What the Exercise Taught Me

Why This Feels Like a Milestone

python #claudeapi #learninpublic #buildinpublic #automation #100DaysOfCode

Day 7 of 60 — today I stopped doing abstract Python challenges and started solving problems I could see myself automating in the real world.

2. Processing a Sales Report

3. Lead Qualification System

4. Bulk SMS Validator

5. Daily Sales Target Tracker

What Today Taught Me

Where This is Heading

python #automation #learninpublic #buildinpublic #ai

Day 6 of 60 — and today Python stopped being theory.

Why Real Life Challenges Hit Different

What the Challenges Revealed

Why This Matters for AI Automation

python #learninpublic #buildinpublic #ai #automation #100DaysOfCode

Day 4 of 60 — and today I put the workflows down and picked up Python.

Why Python?

Why This Matters for AI Automation

What I Was Learning