From twelve products to one (a preview of Profiles)

2026. Forward-looking: describes the planned v1.21.0 “Profiles” release, not a shipped capability.

A memory store ships with knobs. Ours has a lot of them — access scope, PII mode, per-kind retention, audit level, allowed memory kinds, connectors, legal-hold defaults. That’s the honest cost of being configurable enough for compliance: a healthcare deployment and a call-center deployment and a developer-tool deployment genuinely need different postures.

But a wall of knobs is a product that says “figure it out.” Twelve different deployments shouldn’t mean twelve different learning curves.

The idea: a Profile is a posture, and posture is the product

Profiles (planned v1.21.0) turns the configurable surface into a small set of use-case postures — the “90% solution” that turns “twelve products” into “one product, twelve postures.” A Profile is a JSON bundle of the existing knobs, stored as one row per domain/tenant and applied at ingest and retrieval:

profile = {
  access_scope, pii_mode, per_kind_retention,
  audit_level, allowed_kinds, connectors, legal_hold_default
}

No new schema columns — a Profile just picks values the system already understands. That’s the design constraint that keeps it honest: we’re not adding capability, we’re making the capability you already have discoverable and repeatable.

Why this is the right 90%

• Onboarding wizard — an operator answers five questions (“what industry, what data sensitivity, who uses it, what should be gated, how long to keep”) and gets a Profile pre-filled from real defaults. The wall of knobs becomes a guided conversation.
• Consistency — the same industry deployment gets the same posture, because the Profile is a repeatable bundle, not tribal knowledge.
• Audit-ready — a Profile is a documented, reviewable artifact: “this deployment runs the healthcare Profile,” which the audit trail can show.
• De-risks tenancy — a Profile per tenant (v2.0) is the natural unit of isolation.

The honest framing

This is forward-looking. Profiles is planned v1.21.0; none of it is shipped code. We flag it here because the design is what we want feedback on now — before we build it. The configurable surface it packages already exists (v1.14/v1.15); Profiles is the ergonomic layer on top.

The takeaway: the difference between “a powerful memory store” and “a product” is whether the power is usable. If you have a deployment we should build a Profile for — or think a knob is missing from the bundle — tell us before v1.21.0, so the “90% solution” is built on real postures, not guesses.

See the roadmap’s v1.21.0 “Profiles” row. The knobs it packages are the ones documented in COMPLIANCE.md (access scope, PII, retention, audit).