ruddercrewby RudderStack
An agent, not a campaign

The email that brought you here wasn’t sent to a list. It was sent to you.

RudderCrew gives every customer their own agent. Yours read your signals, weighed the moment against everything else it could have done, and decided this was worth reaching you. Then it wrote down exactly why.

Become a design partner →

How it works

This page looks the same to everyone who lands here. The decision that brought you here didn’t.

RudderCrew did three things before you received the email that brought you here.

Observed

It read your behavior where it already lives.

Your activity off the event stream in real time, weighed against the fuller history in the warehouse — plus anything else exposed to it as an API or MCP: your CRM, your support desk, your own services. Not one stale copy in a marketing tool that only knows a slice of you.

Reasoned

It asked whether now was the right time, and what to say.

Not “did this person match a rule.” A judgment call, weighed against everything else it could have done with your attention.

Acted

It wrote the message itself, then sent it.

Not a template with your first name dropped in — the subject line and the body were drafted for you, from your activity. Sent instantly, with the reasoning logged.

One agent per customer

Real 1:1 personalization, finally

Most “personalization” is everyone walking the same branches. What just reached you wasn’t a one-off, it’s how RudderCrew works for every customer you have. Rules-based journeys fan all of them through one if-this-then-that tree somebody drew months ago. RudderCrew runs an agent per relationship instead.

Rules-based journeys

One tree, drawn once

Every customer flows through the same branches. The logic ages the day it ships, and nobody re-decides per person.

It only improves when a human notices, reads a report, and redraws the tree.

RudderCrew

One agent, per customer

Each one makes fresh judgment calls about a single customer, not about the segment they happened to get dropped into.

And it learns from what that customer actually did. Ignored, opened, bought — each outcome feeds the next decision, without anyone redrawing anything.

Which raises the real question — what should it be deciding?

Where teams point it

What would you want an agent to decide?

Four places teams point it. Each one is a worked example that runs the same three steps — observed, reasoned, acted — on a different kind of decision.

1:1 lifecycle marketingworked example

Onboarding, decided one step at a time

A direct-to-consumer health brand. 40,000 new signups a month, one lifecycle team. Today every one of them gets the same five-email welcome series on the same schedule, and roughly nine in ten never finish it.

Observed
  • Priya signed up six days ago. Returned to the same product category three times this week. Opened both emails. No purchase yet.
    event stream
  • Sara signed up the same day. Opened nothing. Left a mobile number at checkout and viewed a high-intent page twice.
    event stream · profile
  • Marcus signed up from a company domain. Built a cart worth six times the average order value, then left it.
    event stream · enrichment
Reasoned
Three people, same cohort, same day, three different next moves. Priya is engaged over email, so keep going there and lead with the category she keeps coming back to. Sara has ignored two emails — a third is wasted; she gave us a number, so try SMS. Marcus looks like a business buyer with a basket this size, so a rep should reach out rather than an automated message.
Acted
  • EmailSends Priya a message anchored on the category she keeps returning to. Waits 48 hours before deciding the next step.
  • SMSSends Sara a short message on the channel she has actually engaged with.
  • Sales taskCreates a task for an account rep with the cart contents and the company attached.
The job here is choosing the next single action for each person, across whichever channel that person actually responds to. You set the goal and the guardrails; the agent picks the move.
The agent decides one step at a time. It does not schedule Priya's next four emails today — it waits to see what she does with this one, then decides again.
Lead enrichment and routingworked example

Turning an anonymous signup into a qualified lead

A B2B analytics company. 300 trial signups a week, most of them a personal email address and nothing else. Sales works the list on gut feel, and the good ones go cold while someone figures out who they are.

Observed
  • A trial signup with a personal Gmail address. No company, no title, no context.
    product signup
  • The UTM path shows paid search, keyword: reverse etl snowflake.
    campaign data
  • Inside the first ten minutes, they connected a Snowflake warehouse and ran a test sync.
    event stream
  • Public web and enrichment lookups tie the address to a named person: data platform lead at a 900-person retailer.
    external sources
Reasoned
The signup looks anonymous, but the surrounding evidence is not. The search keyword names the exact use case. The first ten minutes of product behaviour confirm it — they didn't browse, they connected a warehouse. The identity lookup gives a company, a size, and a role with real budget authority. This is a qualified lead that the CRM would have filed as an unknown Gmail address.
Acted
  • SalesforceWrites the enriched record: company, size, inferred use case, role, and a confidence score on each inferred field.
  • SlackPosts an alert to the sales channel with the reasoning attached, so the rep opens the conversation already knowing why.
The job is inference and write-back: pull scattered evidence together, work out what it means, and put the answer where your team will actually see it.
Nothing is sent to the customer here. Every action lands inside systems your team already works in — which is why this one is usually the easiest to run live from day one.
Decisioning across the stackworked example

Deciding across ten systems at once

A global consumer brand operating in 112 markets. The customer picture is split across a warehouse, an event stream, Salesforce, a support desk, an email platform, and a production database. No single tool can see the whole person — so every tool decides on a slice.

Observed
  • Contract renews in 34 days.
    warehouse
  • Configured a new integration twice this month — usage is climbing.
    event stream
  • Opened a support ticket four days ago about a billing discrepancy. Still unresolved.
    support desk
  • Two renewal emails already sent this week by the campaign platform.
    email platform
  • An account rep logged a call attempt yesterday. No answer.
    Salesforce
Reasoned
Each system, on its own, says send the renewal push. The warehouse sees a renewal window. The event stream sees healthy usage. The campaign tool sees an unopened email and queues another. But put them together and the picture inverts: this customer has an open billing complaint and has already been contacted three times in five days. A fourth renewal message right now damages the relationship it's meant to protect.
Acted
  • HoldSuppresses the scheduled renewal message until the support ticket closes.
  • SlackFlags the account to the rep with the ticket linked, so the objection gets handled before the ask.
The job is assembling the whole customer at the moment of the decision, across sources that were never designed to be read together. Connect the tools where your context lives; the agent reconciles and decides on top of them.
The most valuable decision here was to do nothing — and no single system in the stack had enough of the picture to make it.
Explainability and controlworked example

Changing what the agent does, on a Tuesday

A lifecycle marketer, mid-afternoon. She has a hunch the agent has become too free with discounts — margin is drifting and she wants to know why before she escalates it. In most systems this is a data-team ticket and a two-week wait.

Observed
  • Opens the decision log and filters to every discount decision from the last 14 days.
    decision log
  • Reads the reasoning on three of them. Two look right. One offered 15% to a customer who was already going to buy.
    decision log
  • The pattern is clear: the agent treats any repeat visit as hesitation.
    review
Reasoned
She does not need an engineer to fix this, because the logic is written in language she can read and edit. She rewrites the instruction: only offer a discount when a customer has viewed the product three or more times and has not purchased in the last 30 days. Then she clones the agent into shadow mode and lets it run against live traffic.
Acted
  • Shadow runThe cloned agent makes its next 200 decisions without sending anything. She compares them side by side against what the live agent would have done.
  • PromoteThe change goes live. Total elapsed time: one afternoon, no ticket, no deploy.
The job is staying in control of a system that acts on your behalf. Read the reasoning, change it in plain language, test it against real traffic before anything reaches a customer.
Every decision the agent makes shows which signals drove it and why — which is what makes the other three something you can actually put your name on.
Auto-generated, never auto-deployed

Agents run autonomously, but only after humans build the guardrails

RudderCrew drafts playbooks based on your goals. You review and approve them before anything ships, so agents only ever act inside the boundaries a human signed off on. Nothing reaches customers unless the playbook is approved.

Warehouse-native by design

It reasons on your data where your data already is

No partial copy synced into a SaaS silo. RudderCrew works on the same governed, complete customer record your business already trusts, so its decisions stay consistent with everything else you know. As agents replace dashboards and UIs, that structural advantage only compounds.

Want to give your team 1:1 personalization agents?

RudderCrew is rolling out with design partners now. A few weeks with our team to work out which of these decisions is actually worth handing to an agent — and you keep everything we build together.

Become a design partner →
ruddercrew
RudderCrew is built warehouse-native by RudderStack. Agents decide; humans approve; everything is logged.