Welcome to the 66th issue of AI Agents Simplified 🍻
This issue is brought to you by CircleCI
I had a marketing idea in my head that I wanted to test. The process sounded simple enough: find the right companies, send them an email, follow up if they didn’t respond, and stop if they did.
I could have handled it manually, at least in the beginning, but I knew that approach wouldn’t scale very far. The other option was paying for another outreach platform every month, and I didn’t really want to do that for something that felt specific enough to build myself. So I opened n8n and started putting the workflow together.
What surprised me was how quickly a simple idea became a much bigger system. The first version had seven nodes. After using it, finding the weak points, and adding what I actually needed, it ended up with fourteen.
The First Version Was Pretty Simple
The first workflow did only the essentials. It ran on a schedule, pulled the contacts that needed an email from PostgreSQL, processed them, and decided whether it should send a new email or reply to an existing thread. After sending, it updated the database so the same contact wouldn’t be treated as new again.
In my head, the whole thing was basically:
Find contact
↓
Decide what to send
↓
Send email
↓
Update databaseAnd at first, that was enough. I wasn’t trying to build some highly autonomous agent. I just wanted to remove a repetitive piece of work and make sure the workflow could run without me sitting there and doing every step manually.
The problems started once I thought about what would happen after the first few emails went out.
Then the Real Questions Started Appearing
The first thing I kept coming back to was replies. What if somebody answered the first email before the next follow-up was scheduled? If the workflow didn’t know about that reply, it would happily send another automated message anyway.
Then there were other details. A follow-up should stay in the same email thread. Some contacts should be handled before others. The system had to remember which stage each person was in, and eventually I also wanted the message itself to change depending on the company I was contacting.
None of those things felt like a big feature on its own, but every one added another piece to the workflow. Eventually the seven-node version became the fourteen-node version I’m using now.
One of the biggest changes is actually at the beginning. The system now checks recent replies before it starts sending anything. It extracts the sender information, tries to match the reply to a contact in the campaign, updates that contact if necessary, and only then continues with outbound emails.
That made the workflow feel very different. It wasn’t only executing a sequence anymore. It was checking what had happened since the last run and using that information before deciding what to do next.
Open Positions*
If you are learning AI systems, MLOps, LLMs, or agentic workflows, these roles cover a strong mix of real production use cases.
Role: AI Engineer
Company: Booz Allen Hamilton
Location: San Antonio, Texas, US
Strong fit for people interested in ML, DevOps, CI/CD, cloud tooling, and AI agents applied to cyber infrastructure.
Role: Machine Learning Engineer
Company: ExaCare AI
Location: New York, US
Covers the full ML lifecycle, including LLM fine-tuning, RAG, experiment tracking, and model optimization.
Role: Machine Learning Engineer
Company: Aionia Group
Location: Mountain View, California, US
Focused on autonomous AI agents, RAG systems, ML infrastructure, and customer-facing AI applications.
The Database Ended Up Being More Important Than I Expected
When I started building this, I thought sending the emails would be the main part of the work. It wasn’t. Sending an email is relatively straightforward; remembering the history around that email is where things get more interesting.
The workflow has to know whether a contact has already received something, which follow-up should come next, when the previous message was sent, whether that person has replied, and whether the campaign should continue at all.
That’s when PostgreSQL stopped feeling like a place where I was simply storing a list of contacts. It became the part of the system that gave every new execution some memory of what had happened before.
Without that state, the automation would basically wake up every day with no idea what it had done yesterday.
Where I Decided to Use AI
The latest version also has an LLM inside the workflow, but I didn’t want to put AI everywhere just because I could.
There are parts of this system where I want exactly the same behavior every time. Checking campaign status, matching replies, deciding whether a message should be sent as a new email or as a reply, and updating the database are all much easier to trust when they’re handled with normal logic.
The part where AI made sense to me was the message itself. If I already have information about the company, its industry, and the person I’m contacting, an LLM can use that context to create something much more specific than the same template with a first name swapped in.
Building it this way gave me a rule that I’ve started using in other automations too: use normal software when the result needs to be predictable, and use AI where some variation is actually useful.
For me, that feels much more practical than trying to make the entire workflow “AI-powered.”
Looking at the Two Versions Side by Side
When I look at the first screenshot and the current one, the obvious difference is that the workflow got bigger. But the more interesting difference is where that complexity went.
The AI model itself is only one part of it. Most of the additional work is reply detection, campaign state, database queries, branching, thread handling, and making sure the workflow knows enough about what happened previously to make the next decision correctly.
That was probably the biggest lesson for me while building this. The model can make one part of the system smarter, but most of what makes the overall workflow useful comes from everything around the model.
The AI writes the message. The rest of the system makes sure that message is being written for the right person, at the right time, for the right reason.
Unmissable Event of Augest*
This is our very first AI Agents Simplified event, marking the start of a new ongoing series. We’re always looking for industry experts to feature, so please reply with 'Speaker' if you'd like to apply for a future session.
Join us online to learn how to optimize your CI/CD pipelines for auto-generated code. We’ll explore practical strategies, new tools, and real-world tips to keep your development cycles smooth and efficient. Perfect for teams ready to improve their automation processes.
My Take
What I like about this project isn’t really the fact that I automated outreach. There are already plenty of products that do that, and probably with far more features than I need.
What I found interesting was being able to take a fairly specific idea in my head and gradually turn it into software without starting a traditional software project. I could build a rough first version, run it, notice what was missing, change the logic, add another piece, and keep going.
The first version didn’t need to be impressive. It only needed to solve the first problem. The rest of the architecture appeared because I actually used it and started running into situations I hadn’t considered at the beginning.
I think that’s one of the bigger changes happening around AI and automation right now. A lot of small internal tools that would have felt too expensive or too annoying to build a few years ago are becoming realistic projects for one person.
For me, that might be more interesting than the idea of AI simply making existing software smarter. It’s making it possible to build software for problems that previously weren’t worth building software for.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.