I Built a Slack Bot That Answers Paid Media Questions in Real Time. Here's the Architecture.

Every few months a new AI tool for marketing gets announced with a demo that looks impressive in a 90-second video and breaks immediately when you try to use it on your actual data, in your actual tech stack, solving your actual problem. The demo is always a generic use case. Your situation is never generic.

I've spent the last 18 months building AI systems for demand gen rather than buying them. Not because I'm philosophically opposed to SaaS, but because the problems I needed to solve were specific enough that no off-the-shelf tool could have addressed them. The Slack bot I built works because it knows my exact campaign naming conventions, my specific ICP definition, and the context of our business at a point in time that a generic product can't have. That context is the difference between analysis that's useful and analysis that's technically correct and practically irrelevant.

But building isn't always the right answer. Here's the framework I actually use — and how the Slack bot fits into it.

When to buy

Buy when the problem is generic. If your need is "write better email subject lines" or "generate first-draft ad copy" or "summarize a long document," there are tools built specifically for those tasks that are good enough, fast to deploy, and cheap relative to the engineering time of building your own. The value of building is context and customization. If the task doesn't require either, buying wins on speed.

Buy when you need a UI your whole team can use. Systems I build are designed for me or for a technical operator. They run from command line, they require knowing which files to export and where to put them, they need someone who can read an error message. That's fine for a tool one person uses. It's not fine for a workflow your entire growth team needs to access daily. If the audience is non-technical and frequent, buy a tool with a proper interface — don't hand someone a Python script and expect it to stick.

Buy when the category is mature. Ad copywriting, SEO content generation, email personalization at scale — these are sufficiently mature use cases that the leading tools have been trained on massive amounts of good output. Your custom Claude prompt won't beat them on the core task. It might beat them on context, but if the context isn't critical to the task, why spend the time building?

When to build

Build when the value is in the data connection. Every system I've built that's actually changed how I work is valuable primarily because of what data it touches, not what AI model it uses. The Slack bot is useful because it pulls live API data from the platforms I actually run — LinkedIn Ads and Google Ads — in real time. No off-the-shelf tool has persistent, authenticated access to those specific accounts with campaign-level context. That access is the asset. The AI model is almost incidental.

Build when your use case requires connecting systems that don't talk to each other, or processing data that exists in a format no tool supports, or applying logic that's specific to your ICP definition or business model. The scoring, the persona, the output format — none of that is configurable in any existing product at the level of specificity that makes it actually useful.

The Slack bot architecture

The bot is a Node.js service that listens for Slack events via the Bolt SDK. When a message is posted in a designated channel with the right trigger format, it fires a pipeline: authenticate to LinkedIn Ads API and Google Ads API, pull the relevant data for the time window specified in the question, pass the data and the question to Claude with a structured prompt, format the response as a Slack block, post it as a threaded reply.

The prompt has three components. A system prompt that defines the analyst persona and output requirements — same as the weekly briefing, but tuned for conversational Q&A rather than structured reporting. A data block that contains the pre-processed API response — stripped of irrelevant fields, aggregated to the appropriate level, formatted as structured JSON. And the user's question, passed verbatim from Slack.

The most important design decision was making the bot read-only. It can answer questions about performance, trends, anomalies, and comparisons. It cannot take actions — no bid changes, no budget reallocations, no pausing campaigns. That constraint isn't a limitation; it's a feature. I wanted a fast, reliable way to get answers during meetings or async reviews. Adding write capability would have required a completely different safety model and slowed down the build by months.

Build when the problem needs a point of view

Generic AI tools give generic output because they're designed not to offend anyone. They hedge. They present multiple options. They avoid making strong recommendations. For a demand gen lead who needs to make a budget reallocation decision on Thursday with incomplete data, hedged output is worse than useless — it adds noise to a decision that already has too much uncertainty in it.

The Slack bot works because the prompt forces a position. When I ask "which LinkedIn campaigns underperformed last week," I don't want a list of all campaigns sorted by CPL. I want the bot to identify the two or three that are worth discussing, explain specifically why they underperformed, and say what it would watch for in the coming week. That kind of output requires a custom prompt with a custom persona. No product can give you that. You have to build it.

The question I ask before starting any build

Before I write a single line of code, I ask one question: if this system works exactly as designed, what decision does it change? Not "what does it automate" — what decision. Automation without a decision attached is a party trick. If I can't name the specific decision that becomes better or faster because this system exists, I stop and reconsider whether I'm solving the right problem.

The Slack bot changes the decision about what to focus on in any given week — surfaced in real time, without pulling up a dashboard or waiting for someone to run a report. The weekly briefing changes the Monday morning decision. The ICP pipeline changes the targeting and budget allocation decision. The Marketo diagnostic changes where ops resources go.

Start with the decision. The system follows from there.