I installed our own SDK as a customer. Standard sk_live_ API key, dedicated organization, no internal shortcuts. The rule was simple: if it doesn't work the way a customer would use it, we have a problem worth knowing about.

This is the story of what I built.

The goal

We run a SaaS platform. Like every SaaS platform, we send notifications. Unlike most, we build the infrastructure that makes notifications smarter — entity memory, behavioral recall, governed AI decisions.

The question I kept asking: if we don't use our own infrastructure for our own notifications, why would anyone else?

Two npm packages. That's the starting point.

npm install @personize/signal @personize/sdk

@personize/signal is the notification engine — open source, pluggable channels (in-app, SES, Slack), and it uses the Personize SDK under the hood for all AI decisions.

What I had to rebuild

The first version memorized identity data. Email, plan, organization ID, user type.

I pushed back on my own implementation: "I don't see anything insightful you are memorizing."

The profile was storing identity but not behavior. The AI could see "Plan: Pro" but had no idea what agents the user runs, what data they filter on, what they're actually trying to accomplish.

The fix: interpret events before memorizing them.

Before:

User filtered records by: companyName, revenue, industry

After:

[FILTER BEHAVIOR] User filtered Contact records using 3 dimensions:
companyName, revenue, industry.

Interpretation: Filtering by firmographic data suggests building a target
account list — a sales-oriented segmentation workflow.
Three additions that changed everything:
  1. Category prefixes — [FILTER BEHAVIOR], [GOVERNANCE], [SCHEMA], [AGENT USAGE]. The AI sees labeled behavioral clusters, not an undifferentiated stream.
  2. Interpretation paragraphs — developer-written intent inference. The AI doesn't have to guess why someone filtered by revenue and industry.
  3. enhanced: true — tells Personize to run AI extraction, creating structured facts and vector embeddings.

The evaluation engine

Every event passes through a decision pipeline before anything reaches a user.

Event → Pre-Check → Context Assembly → AI Scoring → Decision → Delivery
         (dedup,      (4 parallel        (4 axes,      SEND /     channel +
          daily cap)   SDK calls)         0–100)        DEFER /    memory
                                                        SKIP)      write-back

The four-axis scoring rubric:

  • Newness (0–25): Is this information they don't already know?
  • Relevance (0–25): How relevant is this to their role and goals?
  • Actionability (0–25): Can they take a specific action from this?
  • Timeliness (0–25): Is now the right time?

Score 60+: SEND. 40–59: DEFER to digest. Below 40: SKIP.

The most important outcome isn't SEND — it's SKIP. Silence, decided by the AI, because this notification doesn't warrant interrupting this person right now.

What broke in production

After turning on the engine for real traffic, something felt off. Lots of evaluations. Few notifications going out. $0.004 per evaluation to decide "don't bother."

The real-time AI evaluation was the right tool for calibrating the engine during development. In production, where most events aren't notification-worthy, it was spending tokens for no return.

The fix: two modes, one environment flag.

| Mode | Trigger | Cost | |------|---------|------| | EVALUATE=true (tuning) | Full 4-call pipeline per event | ~$0.004/event | | EVALUATE=false (production) | Behavior memorized, digest daily | ~$0.01/user/day flat | | Critical events | Template, bypasses both | ~$0 |

The behavioral digest runs once per day per user. One AI call: "Based on this person's recent activity, what 1–2 insights are worth surfacing?" Skip if nothing meaningful.

The governance variables

Three governance variables guide every notification decision — maintained in the Personize app, not in code:

  • notification-guidelines — frequency caps (max 3/day), channel selection rules, per-event policies
  • notification-tone — "a knowledgeable colleague, not a marketing tool. Specific beats generic."
  • digest-guidelines — when to compile, how to structure; explicitly: "not a newsletter, not a guilt trip"

Update them in the app and the AI adapts on the next evaluation. No deploy. No review cycle. That's the governance pattern.

The infrastructure is in production on our own users. What I haven't seen yet: another SaaS product shipping this same pattern to their users. The engine is open source. The SDK handles the integration.

If your product sends notifications and you've wondered whether they're helping or just adding noise — this is the pattern I'd start with.