Persona-driven suggested prompts for Addie (Slack + Home)

[bokelley]

Context

@pkras asked whether we could make Addie's suggested prompts more predictive — persona + engagement aware rather than static. Her direction:

Prompts change based on what we know about the member: their archetype (we already have the persona assessment), engagement stage (exploring → active → leading), working group memberships, certification progress, and last interaction with Addie.

Today there are two prompt systems, and they diverge:

System	File	Where it shows	Style
Slack Assistant thread pane ("Try these prompts:")	server/src/addie/prompts.ts → buildDynamicSuggestedPrompts	Top of a new thread with Addie in Slack	Static. 3 hardcoded tiers (unlinked / admin / member).
App Home + Web Home	server/src/addie/home/builders/suggested-prompts.ts → buildSuggestedPrompts	Slack App Home tab + web home	Partially context-aware. Bug: persona check uses wrong persona IDs (ad_tech_vendor, agency_tech, publisher_tech) — none match the real IDs in server/src/config/personas.ts, so that branch never fires.

Proposal: consolidate on one rule-based builder, feed it everything we already know about the member, and ship Piia's 5 examples in two stages.

Signals already on MemberContext

• persona.persona, persona.aspiration_persona, persona.journey_stage
• engagement.login_count_30d, last_login, interest_level, email_click_count_30d
• working_groups[] with is_leader per group
• community_profile.completeness
• addie_history.total_interactions, last_interaction_at
• is_member, is_mapped, slack_linked

Persona IDs in use: molecule_builder, data_decoder, pureblood_protector, resops_integrator, ladder_climber, simple_starter, pragmatic_builder.

Signals NOT yet hydrated

• Certification progress (data exists in certification_attempts — just not joined onto the context)
• Agent registration (adagents.json / brand.json lookup by org domain)
• Upcoming WG meetings — unclear if a data source exists; needs audit

Stage 1 — Unify + ship rules on existing data

One builder. Rule-based ({ id, when, label, prompt, priority }). Evaluated in priority order, top 4 wins (even count enforced for 2-col grid). Admin short-circuit preserved — admins still get the 4 ops prompts they use day-to-day.

Rule table (stage 1)

#	Trigger	Label	Priority
1	unlinked	What is AdCP?	100
2	unlinked	What brings you here?	95
3	unlinked	How do I join?	90
4	linked, not member	Membership options	85
5	member, profile <80% complete	Complete my profile	80
6	member, no working groups	Find working groups that match your interests	75
7	member, leads a WG	Working group to-dos	72
8	member, in WGs (not leader)	What's happening in my working groups?	70
9	persona=molecule_builder/pragmatic_builder	Build with AdCP	65
10	persona=data_decoder	What data can AdCP move?	65
11	persona=resops_integrator	Connect AdCP to my stack	65
12	persona=ladder_climber/simple_starter	Start with the Academy	65
13	persona=pureblood_protector	Governance and brand safety	65
14	member, last_login > 30d ago	What's new since you were last here?	60
15	addie interactions < 3	What can you help me with?	40
16	fallback	What's new?	10

Deliverables

• home/builders/rules/prompt-rules.ts — rule registry
• Rewrite suggested-prompts.ts to evaluate rules
• Retire buildDynamicSuggestedPrompts in prompts.ts; point handler.ts + bolt-app.ts at the unified builder
• Fix the broken persona IDs bug
• Replace tests/unit/dynamic-prompts.test.ts with rule-coverage tests
• Verify parity: same user sees same prompts in Slack Assistant, Slack App Home, and Web Home

Stage 2 — Hydrate missing signals, add remaining rules

Turns on the last 3 of Piia's examples:

• Cert continuation (priority 78): query latest certification_attempts for the user, add certification block to MemberContext
• Builder, no agent → Test your agent with Addie (priority 68): domain lookup for adagents.json / brand.json
• WG leader with meeting in <7d → Prep for the meeting (priority 82): blocked on finding an events data source. Stage 2 kicks off with a 30-min audit; if nothing exists, we ship cert + agent and punt meeting prep to a follow-up.

Out of scope (for now)

• A/B testing prompt variants (needs analytics)
• LLM-generated prompts (rules are cheaper and more predictable; revisit if rules feel limiting)
• i18n

---

@pkras — keeping this in your voice: does the priority ordering feel right? Two places I want your read:

1. Profile completeness (rule 5) at priority 80 — higher than the persona prompts (65). Means members with incomplete profiles see a "finish your profile" nudge before a persona-specific prompt. Correct, or should the persona prompt always win?
2. Disengaged (rule 14) at priority 60 — below personas. If someone hasn't logged in for 30+ days, do you want "what's new" to jump to the top instead?

Happy to reorder before we start building.

[pkras]

@bokelley

Rule 5: Looks correct - incomplete profile = partial data = finish your profile should be a prerequisite.
Rule 14: A lapsed member probs need a reason to come back vs a chore, so what's new/what i missed makes sense. Would bump above profile completeness at ~85

[bokelley]

@pkras — love these, all going in. Data check below so we know what's actually Stage 1:

Your additions → data availability

Your idea	Signal	Status
Low logins re-engagement	engagement.login_count_30d < 3	✅ on context — Stage 1
Disengaged "what's new"	engagement.last_login	✅ already Stage 1 (was rule 14 at 30d) — I'll keep that and add your softer <3 logins version as a second tier
Org owner → "Invite your team"	org_membership.role === 'owner'	✅ on context — Stage 1
Solo org → "Add teammates"	org_membership.member_count === 1	✅ on context — Stage 1
Large org, low WG participation	member_count > 5 && working_groups.length < N	⚠️ person-level WG count is on context; org-wide WG coverage needs an extra query (lightweight, keep in Stage 1)
Explorer tier → "Upgrade for Slack/WG access"	subscription.product_name	✅ on context — Stage 1 (need to map product names → tier)
Builder+ → "Set up API keys"	subscription tier + api_keys count	⚠️ api_keys table exists, not on context. Small query. Can be Stage 1
Agent not tested in 2wks	agent test timestamp	❌ no data yet — we don't log agent test results anywhere. Needs instrumentation (new feature). Stage 2+
Review meeting agenda	events source	❌ Stage 2 (already flagged)
Zero perspectives → "write one"	perspectives count	⚠️ table exists, not on context — Stage 2 hydration
Event registrations + days-to-event	event_registrations tables (087, 133)	⚠️ exists, not on context — Stage 2 hydration

Updated Stage 1 rule table (new/changed rows in bold)

#	Trigger	Label	Priority
1–4	(unchanged) unlinked / linked-not-member	...	100–85
5	member, Explorer tier (lowest paid)	Upgrade for Slack & working group access	85
6	member, profile <80% complete	Complete my profile	80
7	member, org owner, member_count === 1	Invite your team	78
8	member, org owner, small team but missing profile	Set up your company listing	76
9	member, no working groups	Find working groups that match your interests	75
10	member, Builder+ tier, 0 API keys	Set up your API keys	74
11	org owner, member_count > 5, low team WG coverage	Get your team into working groups	73
12	member, leads a WG	Working group to-dos	72
13	member, in WGs (not leader)	What's happening in my working groups?	70
14–18	persona-specific prompts	...	65
19	member, last_login > 30d ago	What's new since you were last here?	60
20	member, login_count_30d < 3 AND last_login < 30d	Here's what you missed	58
21	addie interactions < 3	What can you help me with?	40
22	fallback	What's new?	10

Top 4 wins. Admin short-circuit unchanged.

Open question for you

Priority ordering sanity check — the way I've stacked it, a profile-incomplete Explorer-tier owner would see:

1. Upgrade (85)
2. Complete profile (80)
3. Invite team (78)
4. Set up company listing (76)

…which skips their persona prompt and the WG prompt. Fine, because those 4 are all activation-critical. But if you'd rather have persona visible at all times (say, always reserve one slot for a persona prompt), say the word and I'll add a "one persona slot guaranteed" rule.

Also — agent test tracking: the "2 weeks since last test" signal is a good idea but doesn't exist in data today. Want me to open a separate issue to instrument agent test logging so it's available for Stage 2+? (Could be as simple as writing a row every time Addie's agent-testing MCP tool runs.)

[bokelley]

Thanks @pkras — bumping lapsed "what's new" to 86 (above profile-completeness at 80 and above the Explorer upgrade nudge at 85). Agreed: re-engagement beats chores for someone we're trying to win back.

Quick heads-up: I posted a second comment above yours on the 20th (while you were drafting) with 6 additional Stage 1 rules incorporating your adoption signals — owner → invite team, solo → add teammates, Explorer → upgrade, Builder+ → API keys, team-WG-coverage, low-login re-engagement. Also two questions I'd still love your read on:

1. Persona slot always visible? In my updated stack, a profile-incomplete Explorer owner sees 4 activation prompts and no persona prompt. Fine with that, or reserve one of the 4 slots for persona?
2. Instrument agent-test logging? Your "agent not tested in 2 weeks" idea is gold but needs a new agent_test_runs table first. Want me to open a separate issue to track that so it's available for Stage 2?

Once those land I'll start Stage 1.

[pkras]

on Q1 i see two paths:

a) slot reserved - so persona priority is at 65, but we hard-code one of the 4 display slots for it so it always shows regardless of activation tasks pending.

b) priority raised - nothing reserved, just persona bump to 90+ so it naturallly wins a slot on its own in the normal priority queue.

so the difference then is in the how, but get persona in front of new members early.

path a = ui rule to always show persona
path b = priority rule - aka persona beats most activation tasks.

path b is then cleaner as it reflects that persona genuinely is high priority, not just a courtesy slot.

Reserving a slot seems then like workaround for the wrong priority. If persona is foundational, because it makes every other prompt smarter, then it should be treated as foundational in the rule stack. Bumping it to 90+ then the fix as it fires early, addie learns intent and then all prompts that follow are more relevant because of it.

on Q2: aha so we need something to store test run data? i guess that does make sense yes. I guess also a prereq for Stage 2 if we want to keep it clean.

[bokelley]

@pkras — applied both:

1. Persona → priority 90 (path B). All 5 persona rules bumped from 65 → 90, sitting just below lapsed re-engagement (86) and just above Explorer upgrade (85). Means a persona prompt naturally wins a slot for any classified member, but doesn't trump re-engagement for someone we're trying to win back. Agreed: persona-as-foundational is a cleaner mental model than reserving slots.

2. Agent test instrumentation: opened Instrument agent test runs (prereq for staleness-aware prompts in #2299) #3254 — new `agent_test_runs` table + wire-up at certification and storyboard runner sites + `agent_testing` block on MemberContext. Marked as a prereq for Stage 2 of this issue.

I'll start on Stage 1 of this issue this week. Will ping when there's a PR to look at.