DEV Community: Ayush S Pangaonkar

Data Engineering Log 3/3: Data Storage and Queries

Ayush S Pangaonkar — Fri, 23 Oct 2026 05:00:00 +0000

I finished Data Storage and Queries, the third course in the DeepLearning.AI + AWS Data Engineering Professional Certificate, on October 3, 2026. The labs were hands-on on AWS, and I cleared the final exam.

Course

Data Storage and Queries, DeepLearning.AI and Amazon Web Services, on Coursera.

Verify certificate: https://coursera.org/verify/6AY7BEQK4RBQ

What I did

Studied how data is physically stored. That covers storage on disk and in memory, then object, block and file storage, and the databases built on top of those.
Followed the evolution of storage architectures. From data warehouses to data lakes to data lakehouses, comparing the advantages and drawbacks of each.
Designed a simple data lake with AWS Glue, then built a data lakehouse with AWS Lake Formation and Apache Iceberg.
Looked at how queries work behind the scenes. I wrote more advanced SQL, compared query performance on row-oriented versus column-oriented storage, and ran streaming queries with Apache Flink.

What I took from it

Storage and queries are connected. How data is laid out on disk, row or column, decides how fast a query can run on it, so the storage choice has to be made with the queries in mind.

Series: Data Engineering Log, part 3 of 3, from the DeepLearning.AI + AWS Data Engineering Professional Certificate.

More of my work is on GitHub.

Data Engineering Log 2/3: Source Systems, Data Ingestion, and Pipelines

Ayush S Pangaonkar — Wed, 21 Oct 2026 05:00:00 +0000

I finished Source Systems, Data Ingestion, and Pipelines, the second course in the DeepLearning.AI + AWS Data Engineering Professional Certificate, on October 3, 2026. The labs were hands-on on AWS, and I cleared the final exam.

Course

Source Systems, Data Ingestion, and Pipelines, DeepLearning.AI and Amazon Web Services, on Coursera.

Verify certificate: https://coursera.org/verify/FWGU74AERQUM

What I did

Explored source systems. I looked at how different source systems generate and update data, and how to connect to them and troubleshoot common connection issues.
Compared batch and streaming ingestion. I identified the use cases and trade-offs of each pattern, and compared the ETL and ELT paradigms.
Built a batch and a streaming ingestion pipeline on AWS. Both pulled data in from source systems, using AWS services for each pattern.
Automated and orchestrated pipelines. The course covers infrastructure as code and pipelines as code, with Apache Airflow as the orchestration tool.
Looked at monitoring and data quality. I explored AWS and open source tools for watching both the data systems and the quality of the data moving through them.

What I took from it

Batch versus streaming is a decision driven by the use case, not by which one sounds more modern. ETL versus ELT comes down to where the transformation happens: before the data is loaded, or after it lands in the destination.

Series: Data Engineering Log, part 2 of 3, from the DeepLearning.AI + AWS Data Engineering Professional Certificate.

More of my work is on GitHub.

Data Engineering Log 1/3: Introduction to Data Engineering

Ayush S Pangaonkar — Mon, 19 Oct 2026 05:00:00 +0000

I finished Introduction to Data Engineering, the first course in the DeepLearning.AI + AWS Data Engineering Professional Certificate, on October 2, 2026. The labs were hands-on on AWS, and I cleared the final exam.

Course

Introduction to Data Engineering, DeepLearning.AI and Amazon Web Services, on Coursera.

Verify certificate: https://coursera.org/verify/AGUYGXWGDWE7

What I did

Walked the full data engineering lifecycle. Data is generated in source systems, ingested, transformed, stored and then served to downstream consumers. Alongside those stages sit the undercurrents that touch all of them.
Turned stakeholder needs into system requirements. The course has you start from what the business actually needs, write that down as requirements, and only then choose tools and technologies. The order matters, because it keeps the tool choice from driving the design.
Spun up batch and streaming pipelines on AWS. The end goal of the course is pipelines that serve product recommendations. Batch processes data collected over a window of time. Streaming processes events as they arrive. Building both side by side made the difference concrete.
Provisioned infrastructure with Terraform. Instead of clicking resources together by hand, the setup is described as code and applied, so the environment can be recreated.

What I took from it

The lifecycle works as a checklist I can run against any pipeline: where does the data come from, how does it get in, where does it live, how is it transformed, and who consumes it.

I had already built this kind of system before. For a previous project I handled 500GB of data and wrote ETL pipeline scripts that parsed it, cleaned it and loaded it into databases. The course made me realize I already had hands-on practice with this, and the certificate now confirms it.

Series: Data Engineering Log, part 1 of 3, from the DeepLearning.AI + AWS Data Engineering Professional Certificate.

More of my work is on GitHub.

Three Things I Found When I Revisited My Gender Classification Project

Ayush S Pangaonkar — Sun, 11 Oct 2026 04:00:00 +0000

I went back to my Gender Classification project, a learning exercise on a small tabular dataset, and found three things worth writing down. (It is a classroom-style dataset of facial and physical measurements, not something I would build a real product on.)

The setup

The dataset, gender_classification.csv, has 5,001 rows. The features are long_hair, forehead_width_cm, forehead_height_cm, nose_wide, nose_long, lips_thin and distance_nose_to_lip_long. The target is Male or Female. My pipeline: drop duplicates, encode the target with LabelEncoder, scale with MinMaxScaler, split 80/20 (random_state=42), then compare Logistic Regression, KNN (k=3) and a Decision Tree.

1. A third of the dataset was duplicates

1,768 of the 5,001 rows, about 35%, were duplicates. After dropping them, 3,233 rows remained. The class balance also moved, from an almost even 2,500 / 2,501 to 1,783 Male (55.1%) and 1,450 Female (44.9%). I now run duplicated().sum() before I trust any dataset's size or balance.

2. The simplest model generalized best

Model	Train acc	Test acc
Logistic Regression	95.1%	96.0%
KNN (k=3)	97.0%	94.4%
Decision Tree	99.8%	94.4%

The Decision Tree has the biggest train/test gap (99.8% vs 94.4%), the same overfitting pattern from my admissions project. For Logistic Regression, precision and recall are balanced across both classes (F1 of 0.958 for Female, 0.962 for Male).

3. The feature I expected to matter did not

Looking at the Logistic Regression coefficients on the scaled features:

Feature	Coefficient magnitude
nose_wide	3.60
lips_thin	3.34
distance_nose_to_lip_long	3.28
nose_long	3.27
forehead_width_cm	2.18
forehead_height_cm	1.81
long_hair	0.07

I would have guessed hair length mattered most. Its coefficient is 0.07, next to nothing. The facial measurements carry the model.

Two corrections to my old write-up

My original README said the model used "age and height". Neither column exists in this dataset, and I rewrote it to list the real features. I also found a copy-paste bug where the Decision Tree's accuracy print statement shows the KNN variable. It only affects that printed line, not the final comparison.

Takeaway

Accuracy tells you a model works. The coefficients tell you why.

Code: github.com/bluntjudg/Gender_Classification

Series: Part 7 of 7 in my ML fundamentals revisit. That wraps up the seven basics. Next, I move on to the apps I deployed.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

My Near-Perfect R2 Was Fake: Debugging a Speed and Distance Model

Ayush S Pangaonkar — Sat, 10 Oct 2026 04:00:00 +0000

The result looked great: R2 of 0.9993 and a correlation of 0.9994 between speed and distance. The problem was that the data had no real relationship in it.

What the script does

Generates 1,000 random speed values (10 to 1,000) and 1,000 random distance values (100 to 10,000) independently with random.randint.
Sorts both arrays ascending, separately.
Pairs them by index into a DataFrame and saves speed_dist.csv.
Splits 97/3 into train and test (970 and 30 rows).
Fits a LinearRegression of distance on speed and reports R2 on the test set.

How I caught it

Speed and distance were generated independently, so by construction there should be no relationship between them. A near-perfect fit should not have been possible. That mismatch made me look at step 2.

Sorting two unrelated arrays and lining them up by index forces a monotonic pattern. Row 1 gets the smallest speed and the smallest distance, row 1,000 gets the largest of both, and nothing about speed and distance is actually connected.

Testing the suspicion

I generated the same two arrays with the same seed and skipped the sorting step:

	Correlation	Test R2
With sorting (original script)	0.9994	0.9993
Without sorting (random pairing)	0.0055	-0.0168

Without the sort, the correlation falls to about zero, and R2 goes negative. A negative R2 means the model does worse than predicting the average distance every time. The high score came entirely from how I assembled the data.

What I do differently now

A high R2 or accuracy only means something if you know exactly how the data was built. Since this project, I check how any synthetic or generated data was assembled before I trust a metric computed from it.

Code: github.com/bluntjudg/Speed-distance-model-

Series: Part 6 of 7 in my ML fundamentals revisit. Next in the series: Gender Classification.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

96.5% Accurate Spam Filter, and the 58 Spam Messages It Let Through

Ayush S Pangaonkar — Fri, 09 Oct 2026 04:00:00 +0000

My spam classifier scores 96.5% accuracy on the test set. That sounds great. The confusion matrix tells a more useful story.

The setup

The dataset is mail_data.csv, with 5,572 messages: 4,825 ham (86.6%) and 747 spam (13.4%), no missing values. I mapped labels to 0 (spam) and 1 (ham), split 70/30 with random_state=3, fit a TfidfVectorizer (English stopwords removed, vocabulary of 6,896 terms) on the training messages, and trained a LogisticRegression model.

Metric	Value
Train accuracy	96.6%
Test accuracy	96.5%
Always predict ham	86.6%

Test accuracy beats the always-ham baseline by about ten points, so the model is learning something real.

What the accuracy hides

On the test set (232 actual spam, 1,440 actual ham):

	Predicted spam	Predicted ham
Actual spam	174	58
Actual ham	1	1,439

Spam precision is 99.4%. Only one real message was flagged as spam.
Spam recall is 75.0%. 58 of 232 spam messages got through.
Ham recall is 99.9%.

So the filter almost never blocks a real message, but it misses about one spam message in four. For a spam filter, letting spam through is usually the safer failure compared with blocking real mail, but that is a trade-off worth stating plainly instead of only quoting 96.5%.

Two corrections I had to make

When I went back through this project, my own write-up did not match my code.

I had described the project as using Naive Bayes and SVM. The script only trains and evaluates Logistic Regression. There is no Naive Bayes or SVM anywhere in it.
The notebook builds a clean_message column with NeatText, but the model is trained on the raw Message text. The cleaning step had no effect on the results.

I fixed the README to describe what the code does.

Takeaway

This was the first project where I looked past one accuracy number into a confusion matrix. The model trades recall for precision on the minority class, and that is a measurable choice, not just a score to quote. It also taught me to re-read my own project descriptions against the code before I publish them.

Code: github.com/bluntjudg/Spam-Classifier-

Series: Part 5 of 7 in my ML fundamentals revisit. Next in the series: Speed Distance Model.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

Eight Emotions, 34,792 Tweets, and One Label I Don't Fully Trust

Ayush S Pangaonkar — Thu, 08 Oct 2026 04:00:00 +0000

One example in my sentiment project still bothers me. The dataset contains the text "I have a feeling i will fail french #fuckfrench", and its label is joy. A human would read that as anxious or frustrated.

I will come back to that. First, the project.

What I built

This is not a positive/negative classifier. It predicts one of eight emotions: joy, sadness, fear, anger, surprise, neutral, disgust or shame. The dataset has 34,792 short, mostly Twitter-style texts, and the classes are very uneven:

Emotion	Count	Share
joy	11,045	31.8%
sadness	6,722	19.3%
fear	5,410	15.6%
anger	4,297	12.3%
surprise	4,062	11.7%
neutral	2,254	6.5%
disgust	856	2.5%
shame	146	0.4%

The pipeline:

Clean the text with NeatText (strip user handles and stopwords).
Vectorize with CountVectorizer.
Train a LogisticRegression model inside a scikit-learn pipeline.
Compare with a MultinomialNB baseline.

I used a 70/30 split, stratified by emotion.

Results

Model	Test accuracy
Logistic Regression	63.5%
Naive Bayes	57.2%
Always predict "joy"	31.8%

Logistic Regression beats the majority baseline by a wide margin. Macro F1 is 0.60 and weighted F1 is 0.63.

A single accuracy number hides the spread between classes:

Emotion	Precision	Recall	F1	Test support
fear	0.74	0.68	0.71	1,623
joy	0.63	0.77	0.69	3,313
anger	0.64	0.55	0.59	1,289
surprise	0.60	0.42	0.49	1,219
disgust	0.54	0.18	0.27	257

Disgust is the weakest, with a recall of 0.18. Shame scores the highest F1 (0.75), but it has only 44 test examples, so I would not lean on that number.

Back to the "joy" label

If the model predicts joy for text like that, it is not necessarily wrong. It may simply have learned the pattern that is in the training labels, flaws included.

The dataset looks like it was built from hashtag-based labeling, which is a common way to build emotion datasets. I cannot verify how every row was labeled, but a hashtag does not guarantee the emotion in the sentence, so some noise in the labels would not be surprising.

What I took from it

This was my first time dealing with class imbalance and reading per-class metrics instead of one accuracy figure. It was also the first time a "wrong" prediction sent me to the raw labels instead of the model. Look at your labels before you blame your model.

Code: github.com/bluntjudg/Text-Sentiment-Analysis-

Series: Part 4 of 7 in my ML fundamentals revisit. Next in the series: Spam Classifier.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

When My House Price Model Hit 100% Accuracy, I Should Have Been Worried

Ayush S Pangaonkar — Wed, 07 Oct 2026 04:00:00 +0000

My first script on the Kaggle House Prices data reported 100% training accuracy. I was pleased for about as long as it took to look at my feature list.

The bug: the answer was in the inputs

The script was meant to predict SalePrice, but I had included SalePrice itself as one of the input columns. The model could simply read the answer off its own inputs. Once the leaked column was gone, the same setup gave a meaningless 52% on held-out data, because I was treating a price as if it were a class label.

A suspiciously perfect number is usually a sign that something is broken, not that the model is good.

Fixing it

The data is the standard Kaggle split: train.csv with 1,460 rows and 81 columns. I used these features: LotArea, BsmtFinSF1, TotalBsmtSF, GrLivArea, FullBath, HalfBath, BedroomAbvGr, GarageArea and SaleCondition.

Predicting SalePrice properly, as regression and without the leak:

Model	R2	RMSE	MAE
Decision Tree Regressor	0.75	$43,830	$29,724
Random Forest Regressor	0.84	$34,656	$21,784

The mean sale price is $180,921, so the Random Forest's average error of about $21.8k is roughly 12% of the average price. That is a believable result.

The second lesson: beat the baseline first

My second script classifies SaleCondition. About 82% of houses sell under "Normal" conditions, so the target is heavily imbalanced.

Model	Train acc	Test acc
Decision Tree	99.9%	70.2%
Random Forest	99.9%	80.8%
Always guess "Normal"	n/a	82.1%

Neither model beats a rule that always says "Normal". An 80% accurate model sounds good until you learn that guessing the majority class gets you 82%.

What I do now

Two habits came out of this project. I check my feature list for the target (or anything derived from it) before I train anything. And I compute a naive baseline before I trust any classification score.

Code: github.com/bluntjudg/House-Price-Predictions-

Series: Part 3 of 7 in my ML fundamentals revisit. Next in the series: Text Sentiment Analysis.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

A Book Recommender That Nails Harry Potter and Fumbles Seven Plays

Ayush S Pangaonkar — Tue, 06 Oct 2026 04:00:00 +0000

Let me start with the good result. I asked my book recommender for books similar to Harry Potter and the Order of the Phoenix, and it returned:

Rank	Recommended title	Similarity
1	Harry Potter and the Chamber of Secrets	0.782
2	Harry Potter and the Sorcerer's Stone	0.778
3	Harry Potter and the Half-Blood Prince	0.768
4	Harry Potter and the Prisoner of Azkaban	0.765
5	Harry Potter Boxed Set, Books 1-5	0.764

Nice. Now the other one. I asked for books similar to Seven Plays:

Rank	Recommended title	Similarity
1	Buried Child	0.458
2	See You Around, Sam!	0.263
3	Sam Walton: Made In America	0.246

The second and third results are there because of the name "Sam", not because the books are alike. Same model, very different quality. Here is why.

How it works

The dataset has 11,127 books with bookID, title, authors and average_rating, and no missing values.

I build a book_content field by joining each book's title and authors.
TfidfVectorizer (English stopwords removed) turns that text into vectors. The matrix is 11,127 by 17,937, and only 0.04% of its cells are non-zero.
linear_kernel computes cosine similarity between every pair of books, giving an 11,127 by 11,127 matrix, around 124 million scores.
For a queried title, I return the top 10 most similar books, excluding the book itself.

A simplified sketch of the idea:

tfidf = TfidfVectorizer(stop_words="english")
matrix = tfidf.fit_transform(books["book_content"])
similarity = linear_kernel(matrix, matrix)

Why Harry Potter works and Seven Plays doesn't

The only signal I gave the model is title and author text. A long series with a consistent author and naming pattern shares a lot of words, so it clusters well, with similarities between 0.66 and 0.78. A title with no such pattern leaves the model matching on incidental word overlap.

This is a content-based recommender, so it relies entirely on item text. There is no genre, no description, and no user ratings in it.

What I would do next

Add genre or description text to the content string, which gives the vectors something real to compare. If user rating histories were available, collaborative filtering could be layered on top.

The lesson I took away: a recommender is only as good as the features behind it, and testing the awkward queries tells you more than testing the easy ones.

Code: github.com/bluntjudg/Book-Recommendation-System-

Series: Part 2 of 7 in my ML fundamentals revisit. Next in the series: House Price Predictions.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

Five Classifiers, One Dataset: What I Learned About Model Choice

Ayush S Pangaonkar — Mon, 05 Oct 2026 04:00:00 +0000

If you hand five different classifiers the exact same data, how different do the results really look? That was the question behind my Admissions Predictions project, and the answer was more interesting than I expected.

The setup

The task is binary: given a student's entrance exam score and percentage, predict whether they get admitted.

The data is synthetic, 1,000 students, with both features drawn uniformly between 0 and 100. I generated the labels myself from a logistic function, then sampled each outcome from a Bernoulli distribution:

admission_prob = 1 / (1 + exp(-(0.1*X1 + 0.2*X2 - 10)))

That gave 755 admitted and 245 not admitted. I used an 80/20 split (800 train, 200 test) with random_state=42, and trained all five models on identical splits so the comparison was fair.

The results

Model	Train acc	Test acc	F1 (admitted)
Logistic Regression	94.13%	92.50%	95.05%
SVM (RBF)	93.75%	91.50%	94.46%
Decision Tree	100.00%	90.50%	93.77%
Random Forest (100 trees, entropy)	100.00%	93.00%	95.45%
KNN	95.50%	92.00%	94.81%

Three things I noticed

The decision tree memorized the training set. A perfect 100% on train and the lowest score on test, 90.5%. That roughly 9.5 point gap is what overfitting looks like in numbers.

Logistic regression held its own. It is the simplest model here and still scored 92.5%. Since I built the labels from a logistic function, a logistic model matching the data-generating process makes sense.

The gap between models was small. All five finished between 90.5% and 93.0%. The test set has 200 rows, so half a point is a single student. I would not call Random Forest a clear winner over Logistic Regression from this experiment alone.

What it changed for me

This was my first side-by-side model comparison, and it changed how I evaluate everything after it. I no longer trust train accuracy by itself, and I look at precision and recall next to accuracy, especially when the classes are not balanced (here, about 75% of students are admitted).

Code: github.com/bluntjudg/Admissions-Predictions

Series: Part 1 of 7 in my ML fundamentals revisit. Next in the series: Book Recommendation System.

Live projects I built after these basics:

ATS Resume Analyzer, a Streamlit app that scores resumes against job descriptions
AI-Based Loan Verification System, a Streamlit app for automated loan eligibility checks
Subreach, a two-agent Reddit tool

More of my work is on GitHub.

Subreach: Building Two AI Agents for Reddit

Ayush S Pangaonkar — Sun, 04 Oct 2026 13:42:52 +0000

Reddit is full of people describing problems out loud. Founders ask what others are building, site owners ask why Google is ignoring their pages, and small business owners ask for help they cannot find elsewhere. Every one of those threads is a chance to be useful, and for a product, a chance to be found.

Doing that by hand does not scale. So for my capstone I built Subreach, an automation system that reads Reddit, decides which threads are worth a reply, writes the reply and posts it. The product it promotes is a SaaS tool.

The interesting part was not the posting. It was deciding how the work should be divided between agents, and what each one is allowed to do. This article walks through that design.

Proof it runs

Both agents running live, combined into one short video.
Refer LinkedIn Article to verify videos

Subreach: Building Two AI Agents for Reddit

A capstone project in agent design, by Ayush S Pangaonkar Why I built it Reddit is full of people describing problems out loud. Founders ask what others are building, site owners ask why Google is ignoring their pages, and small business owners ask for help they cannot find elsewhere.

linkedin.com

The design in one picture

Subreach is two agents that share the same engine but have opposite jobs.

Agent 1, the marketing agent, is the only one allowed to mention the product.
Agent 2, the knowledge agent, is never allowed to mention it. Its only job is to give useful answers to real SEO problems.

Each agent runs in its own Chrome instance, with its own configuration, its own list of subreddits, its own search queries and its own prompt files. They do not share state, so a change to one cannot break the other.

The pipeline both agents follow

Every agent moves a post through the same stages:

Search. Build Reddit search requests from the subreddit list and query templates, sorted by newest, limited to the last day, 25 results per request and up to 2 pages.
Raw storage and duplicate check. Save what was fetched, then drop any post that was already commented on, so the same thread is never answered twice.
AI intent filter. A language model reads the post against the agent's rules and returns a single word, APPROVE or REJECT.
Queue. Approved posts go into a first-in-first-out queue with their URL, subreddit and timestamps.
Commenting. A comment is generated for the next post in the queue, then typed and submitted in a logged-in browser session.
Tracking. Every successful comment is recorded, which feeds the duplicate check on the next cycle.

Data files are append-only, and every model call is logged to a usage ledger, so nothing happens silently.

Agent 1: the marketing agent

Job: promote that one product, and nothing else.

Where it looks. It watches 30 subreddits and searches each one for five query templates: "what are you building", "saas ideas", "today I built", "looking for feedback" and "side project". These are the phrases that tend to show up in threads where sharing your own project is part of the point.

How it decides. The approval step checks every post against a rules file. The rule is deliberately narrow: only approve posts that explicitly invite people to share what they are building, such as a "What are you building?" thread, a build in public thread or a weekly check-in. Founder stories, indirect promotion and plain advice requests are rejected, even when they are on topic. The agent only speaks where self-promotion is welcome.

How it writes. The comment is generated by gpt-4o-mini from a prompt file. That prompt contains a hard rule for the product link: it cannot end a sentence or be followed by punctuation, and it has to flow straight into a lowercase word, so it reads like part of a sentence rather than a pasted ad. The generator checks that the exact link string is present in the output. If it is missing, it retries once at a higher temperature before giving up on that post.

Subreddits monitored (30): r/StartupAccelerators, r/startups, r/smallbusiness, r/GrowthHacking, r/microsaas, r/micro_saas, r/SaaSSolopreneurs, r/SaaS, r/indiehackers, r/buildinpublic, r/ShowMeYourSaaS, r/indie_startups, r/Entrepreneur, r/EntrepreneurRideAlong, r/SideProject, r/SideHustle, r/Startup_Ideas, r/StartupMarketing, r/GrowthMarketing, r/MarketingAutomation, r/ContentMarketing, r/SEO, r/TechStartups, r/IndieDev, r/DigitalMarketing, r/SaaSMarketing, r/Devpreneur, r/Solopreneur, r/NoCode and r/Automation.

Agent 2: the knowledge agent

Job: be genuinely useful to people with SEO problems, with no promotion at all.

Where it looks. It watches 8 subreddits and searches for seven query templates built around real problems: "why is my website not ranking", "google not indexing my site", "sitemap error", "meta description help", "impressions but no clicks", "on page seo help" and "keyword research beginner".

How it decides. It follows the same pipeline, but its goal is different. It looks for people who are stuck on a concrete SEO issue and can be helped with a real answer.

How it writes. Its comment prompt contains an explicit instruction not to promote anything. No product link and no mention of the product, ever, on this track. The writing itself is shaped by a detailed persona file: a 16-item personalization checklist, eight named comment patterns (for example short and direct, or a stack of reasons), a target mix of lengths across a day (roughly 35 percent short, 40 percent medium and 25 percent long) and a list of stock phrases to avoid because they read as machine-written. The aim is that a profile's recent comments read like they came from one consistent person.

Subreddits monitored (8): r/SEO, r/TechSEO, r/Wordpress, r/blogging, r/smallbusiness, r/Entrepreneur, r/digital_marketing and r/webdev.

Why two agents instead of one

Promotion and help pull in opposite directions. A single agent asked to do both has to balance them inside one prompt, and the balance tends to slide toward whichever instruction is stronger. Splitting by intent made each agent simpler to write, simpler to test and simpler to reason about. The marketing agent has one narrow permission. The knowledge agent has one hard prohibition. Neither can quietly drift into the other's job.

Cost-aware model routing

Not every step needs the same model. The filtering step runs on every fetched post and only has to output one word, so it uses gpt-5-nano, set through an environment variable and chosen for cost. Comment generation runs far less often and needs better writing, so it uses gpt-4o-mini. Matching the model to the job kept the running cost down without touching comment quality.

Pacing and reliability

Both agents share the same timing configuration:

A delay of 60 to 120 seconds between fetching a post and commenting on it
3 to 5 minutes between comments
A 15 minute break after each full cycle
A randomized wait between subreddits drawn from four tiers, so the rhythm is not a fixed interval
Exponential backoff when a subreddit fetch fails, and a longer backoff when Reddit returns a rate limit response

Comments are typed into an already logged-in Chrome tab over the Chrome DevTools Protocol using Playwright, with a small per-keystroke delay, and submitted with Ctrl+Enter.

What I learned

Separate agents by intent, not by task. The same pipeline can serve two very different goals when the rules around it are different.
A cheap model is enough for a yes or no decision. Save the stronger model for output a person will read.
Small constraints matter. The link rule and the narrow approval rule did more for quality than any amount of general instruction.
Configuration over code. Subreddits, queries and timing live in config files, so changing the target audience does not mean touching the logic.

A limitation worth stating

The cost estimate in the filter service applies one flat per-token rate, labelled with older model pricing, to every call. The filter actually runs on gpt-5-nano, which is cheaper, so the logged figure overestimates the real filtering cost. It is a useful ceiling, not an accurate bill, and it is the first thing I would fix next.

Explore the project

The full code, including both agents and their configuration, is on GitHub: github.com/bluntjudg/autopilot