Home
Syntrik

RAG / Guide

Most things don’t need RAG. A short guide to when it earns its keep.

RAGGuide

Retrieval augmented generation is the default answer for too many problems. Here are the few where it actually pulls its weight.

Syntrik team

Syntrik team

May 28, 2025·8 min read

When not to use RAG

The problem nobody wanted to fix

The client — a Series A SaaS — had eight sales reps and a HubSpot deal pipeline. After every meaningful Slack thread (a customer reply, an objection, a handoff), reps copied the relevant bits into the HubSpot deal record by hand. Some did it well. Some did it three days late. Some stopped doing it entirely. The pipeline looked clean in dashboards and rotten underneath.

We measured it with a quick stopwatch exercise: about three hours per rep per day spent on copy-paste and field-filling. Eight reps. Twenty-four hours of work a week, vanishing into Slack. The CRO had been quoting a headcount problem; it was really a tab problem.

What we shipped

One trigger, one pipeline, one confirmation. A rep reacts to a Slack thread with a custom emoji. n8n picks up the webhook, pulls the full thread, and sends it to OpenAI with a structured-extraction prompt: deal name, stage change, next step, owner. The HubSpot API updates the matching deal. A confirmation gets posted back in the thread so the rep knows it landed.

That’s the whole workflow. No UI to learn. No new tool in the stack the reps had to think about. The interface was an emoji they already understood.

Architecture, in prose

n8n runs self-hosted on a small instance inside the client’s AWS account. Slack sends events to a webhook listener with a shared signing secret. The workflow has three nodes that matter: a Slack thread fetcher, an OpenAI call with JSON mode, and a HubSpot deal updater. Around those, the boring stuff — rate-limit handling, deal-lookup fallbacks, an audit log table in Postgres, and a Slack alert on any failure.

  • TriggerSlack reaction event via webhook
  • ExtractOpenAI GPT-4o with structured JSON output
  • MatchHubSpot deal lookup by associated contact or company
  • WriteHubSpot API PATCH on the deal record
  • ConfirmSlack message back in the same thread
  • ObservePostgres audit log + alerting on failures
Architecture diagram of the Slack to HubSpot automation

We spent more time on the prompt than on any other piece. The model needed to handle three real-world cases: a clean update, a partial update with missing fields, and a thread that wasn’t a deal update at all (so the workflow had to bail out gracefully). The final prompt is about 60 lines and ships with a small evaluation set we re-run on every model swap.

Outcome

Eight days from signed scope to production. Twenty-four hours per week of manual entry disappeared. By week three, every rep had used the emoji at least once a day; the team stopped opening HubSpot tabs to update deals at all. The CRO redirected the “more headcount” budget to a second automation we’re scoping now.

What we’d do differently

Two things. First, we’d ship the confirmation message in day one instead of day three — reps didn’t trust the workflow until they saw it talking back. Second, we’d set up the eval harness before the prompt, not after. We hand-tuned for two days that an eval set would have replaced with two hours. Lesson logged, and applied on the next project.

Let’s build something that ships.

Tell us what you want to automate, productize, or rebuild. Reply within a day.

Syntrik builds AI, products, and apps that ship