How to Use AI for SaaS Growth: My Production Agent Lessons
Last year, we launched a new SaaS product. It had a solid core, but our onboarding conversion numbers were just… fine. Not bad, not great. We were sending generic welcome emails, showing the same in-app tour to everyone. We knew we could do better, but building out truly personalized flows for every user segment felt like a massive engineering sink. Every new idea meant more API calls, more database schemas, more conditional logic to maintain. It was a bottleneck, plain and simple.
We tried the usual marketing automation platforms. They helped a bit, but they were too rigid. Customizing a user’s journey based on their initial actions, their industry, or even their stated goals during signup quickly became a spaghetti mess of if-then statements. Hiring more dedicated dev time for this wasn’t an option; we had core product features to build. That’s when I started looking at AI agents, not as a magic bullet, but as a way to offload some of that dynamic decision-making and content generation.
The Onboarding Problem: Why Generic Doesn’t Grow
Our initial onboarding flow was a classic funnel: signup, welcome email, product tour, maybe a follow-up email if they didn’t activate. The problem? A new user signing up for a project management tool might be a solo freelancer, a small team lead, or an enterprise admin. Each has wildly different needs, different features they care about, and different paths to activation. Treating them all the same meant we were missing opportunities to connect, to show them the exact value proposition that mattered to them.
We needed a system that could observe a user’s initial behavior, understand their likely persona, and then adapt the onboarding experience in real-time. This meant dynamically selecting which in-app tips to show, which tutorial videos to recommend, and even the tone and content of follow-up emails. Doing this with traditional code would have meant an explosion of conditional branches and A/B test permutations that would be impossible to manage. It’s a classic problem for how to use AI for SaaS growth: personalization at scale without burning out your engineering team.
Building a Smarter Onboarding Agent: Frameworks vs. Platforms
I decided to build a custom agent. Not a fully autonomous, self-improving entity, but a structured workflow that could make decisions and take actions based on user data. I considered a few options: agent frameworks like LangGraph or CrewAI, and agent platforms like Lindy or Bardeen. For our specific need—deep integration with our existing systems and fine-grained control over logic—a framework was the clear choice. Platforms are great for simpler, more contained automation tasks, but they often hit a wall when you need complex, multi-step reasoning or custom tool integrations.
We settled on a LangGraph-based agent. It allowed us to define states (e.g., ‘User Signed Up’, ‘User Explored Feature X’, ‘User Inactive’) and transitions between them. Each state could trigger specific actions: an LLM call to generate personalized copy, an API call to our CRM to update a user’s profile, or a notification to our in-app messaging service. The agent’s ‘brain’ was a small, fine-tuned LLM that, given a user’s initial data and recent actions, would decide the next best step in their onboarding journey. For example, if a user immediately created a project, the agent would infer they were a ‘doer’ and prioritize tutorials on project creation and task management. If they spent time in settings, it might suggest admin-focused guides.
Here’s a simplified look at a tool definition for our agent to send an email:
from langchain_core.tools import tool@tooldef send_onboarding_email(recipient_email: str, subject: str, body: str): """Sends a personalized onboarding email to the user.""" # In a real system, this would call an email API (e.g., SendGrid, Mailgun) print(f"Sending email to {recipient_email} with subject '{subject}'") print(f"Body: {body}") return {"status": "success", "message": "Email sent"}This tool, along with others for updating user profiles or triggering in-app messages, gave our agent the ability to act. The LLM’s job was to decide *when* and *how* to use these tools, based on the user’s context. This approach let us iterate on onboarding flows much faster than traditional development cycles. We could tweak prompts, add new tools, and adjust state transitions without redeploying core application code. That’s a huge win.
What Breaks When AI Agents Touch Your Users?
Building these agents isn’t all sunshine and rainbows. The debugging pain is real. When an agent silently fails, or worse, sends a completely inappropriate message, finding the root cause can be a nightmare. Traditional logs just show an API call was made; they don’t tell you *why* the agent decided to make that call, or what its internal reasoning was. This is where observability tools become non-negotiable. We quickly integrated LangSmith (LangChain’s own offering) and later explored Langfuse. These tools let you trace the entire execution path of an agent, seeing every LLM call, every tool invocation, and the intermediate thoughts of the model. Without them, you’re just guessing why an agent decided to send a ‘welcome back’ email to a brand new user, which, yes, is annoying.
One time, our agent, trying to be helpful, pulled an outdated product feature from our documentation and started recommending it to new users. We caught it because our analytics showed a sudden drop-off in engagement for that segment. This highlights the need for robust data sources and constant monitoring. We had to implement a content moderation step, where the agent’s generated text was checked against a list of banned phrases and factual inaccuracies before being sent. It’s an extra layer, but it prevents embarrassing mistakes.
Another challenge is governance. When an agent can directly interact with users and modify their data, you need clear audit trails. Who authorized this action? What was the agent’s reasoning? We had to build a system that logged every significant agent decision and action, linking it back to the specific user interaction that triggered it. This isn’t just good practice; it’s essential for compliance, especially if your agents touch real money or sensitive user data.
We also used feature flags extensively to manage the rollout of our agent-driven onboarding. We used LaunchDarkly to roll out our agent-driven onboarding to 10% of new sign-ups. It let us compare conversion rates directly against the old flow without risking our entire user base. That kind of control is invaluable, especially when you’re experimenting with something as unpredictable as an agent. It’s how you set up analytics for agent performance, too: segmenting users by agent-driven vs. control group and comparing key metrics. This is a critical part of any feature flag tutorial for agent deployments.