DEV Community: Aihh

Build a Boundary Policy Engine for Stateful AI Chat in TypeScript

Aihh — Fri, 31 Jul 2026 04:09:54 +0000

An AI chat model should not decide product permissions from prompt vibes.

If a companion can change tone, advance a relationship, introduce a sensitive topic, or generate voice and images, the application needs a deterministic decision before generation begins.

This tutorial builds a small boundary policy engine with three outcomes:

ALLOW | DENY | ASK

It handles scope, rule authority, expiry, revocation, conflicts, and stale asynchronous jobs.

Define capabilities and decisions

type Capability =
  | "tone.playful"
  | "topic.work"
  | "relationship.advance"
  | "media.voice"
  | "media.image"

type PolicyEffect = "allow" | "deny" | "ask"

type RuleSource =
  | "product-default"
  | "confirmed-inference"
  | "explicit-user"

type PolicyScope =
  | { kind: "global"; userId: string }
  | { kind: "character"; userId: string; characterId: string }
  | { kind: "conversation"; conversationId: string }
  | { kind: "scene"; conversationId: string; sceneId: string }

type PolicyRule = {
  id: string
  capability: Capability
  effect: PolicyEffect
  source: RuleSource
  scope: PolicyScope
  validFrom: Date
  validUntil?: Date
  revokedAt?: Date
  version: number
}

Rules contain decisions, not free-form conversation. A separate audit link can point to approved evidence if the product needs it.

Represent the request context

type PolicyContext = {
  now: Date
  userId: string
  characterId: string
  conversationId: string
  sceneId?: string
  policyVersion: number
}

type CapabilityRequest = {
  capability: Capability
  requestedBy: "user" | "assistant" | "automation"
}

requestedBy matters. A user explicitly asking for an image is different from an automation deciding to insert one.

Match scope explicitly

function scopeMatches(
  scope: PolicyScope,
  context: PolicyContext,
): boolean {
  switch (scope.kind) {
    case "global":
      return scope.userId === context.userId
    case "character":
      return (
        scope.userId === context.userId &&
        scope.characterId === context.characterId
      )
    case "conversation":
      return scope.conversationId === context.conversationId
    case "scene":
      return (
        scope.conversationId === context.conversationId &&
        scope.sceneId === context.sceneId
      )
  }
}

Semantic similarity must never override a scope mismatch. This check belongs in normal application tests, even if the database also filters by scope.

Remove inactive rules

function isActive(rule: PolicyRule, now: Date): boolean {
  if (rule.revokedAt) return false
  if (rule.validFrom > now) return false
  if (rule.validUntil && rule.validUntil <= now) return false
  return true
}

Revocation and expiry are separate. Revocation reflects a user or product decision; expiry reflects a validity boundary.

Rank authority and specificity

const sourceRank: Record<RuleSource, number> = {
  "product-default": 0,
  "confirmed-inference": 1,
  "explicit-user": 2,
}

const scopeRank: Record<PolicyScope["kind"], number> = {
  global: 0,
  character: 1,
  conversation: 2,
  scene: 3,
}

function compareRules(a: PolicyRule, b: PolicyRule): number {
  return (
    sourceRank[b.source] - sourceRank[a.source] ||
    scopeRank[b.scope.kind] - scopeRank[a.scope.kind] ||
    b.version - a.version ||
    a.id.localeCompare(b.id)
  )
}

The final ID comparison is only a deterministic tie-breaker. Equal stored state should produce equal decisions on every worker.

Resolve conflicts conservatively

type PolicyDecision = {
  effect: PolicyEffect
  ruleIds: string[]
  reason:
    | "explicit-rule"
    | "conflicting-rules"
    | "no-applicable-rule"
}

function decide(
  request: CapabilityRequest,
  rules: PolicyRule[],
  context: PolicyContext,
): PolicyDecision {
  const candidates = rules
    .filter(rule => rule.capability === request.capability)
    .filter(rule => scopeMatches(rule.scope, context))
    .filter(rule => isActive(rule, context.now))
    .sort(compareRules)

  if (candidates.length === 0) {
    return {
      effect: "ask",
      ruleIds: [],
      reason: "no-applicable-rule",
    }
  }

  const top = candidates[0]
  const tied = candidates.filter(rule =>
    sourceRank[rule.source] === sourceRank[top.source] &&
    scopeRank[rule.scope.kind] === scopeRank[top.scope.kind] &&
    rule.version === top.version,
  )

  const effects = new Set(tied.map(rule => rule.effect))

  if (effects.size > 1) {
    return {
      effect: "ask",
      ruleIds: tied.map(rule => rule.id),
      reason: "conflicting-rules",
    }
  }

  return {
    effect: top.effect,
    ruleIds: [top.id],
    reason: "explicit-rule",
  }
}

When equally authoritative rules conflict, ask is safer than silently choosing the more permissive value.

Separate decision from generation

async function generateCompanionReply(
  request: CapabilityRequest,
  context: PolicyContext,
) {
  const rules = await policyStore.forUser(context.userId)
  const decision = decide(request, rules, context)

  if (decision.effect === "deny") {
    return { kind: "blocked", decision }
  }

  if (decision.effect === "ask") {
    return {
      kind: "needs-confirmation",
      decision,
      prompt: confirmationCopy(request.capability),
    }
  }

  return model.generate({
    context,
    capability: request.capability,
    policyDecision: decision,
  })
}

Do not generate the content first and filter afterward. Post-generation filtering cannot undo an unwanted relationship transition or an already-dispatched voice job.

Re-check asynchronous jobs

type MediaJob = {
  id: string
  userId: string
  capability: "media.voice" | "media.image"
  policyVersion: number
}

async function executeMediaJob(job: MediaJob) {
  const currentVersion = await policyStore.version(job.userId)

  if (currentVersion !== job.policyVersion) {
    throw new Error("POLICY_VERSION_STALE")
  }

  return mediaWorker.generate(job)
}

A production worker should reload the current rules and re-evaluate, not merely compare versions. The version check is a fast rejection path.

Test the uncomfortable cases

import { describe, expect, it } from "vitest"

describe("boundary policy engine", () => {
  it("lets an explicit denial beat an inferred allow", () => {
    const result = decide(imageRequest, [inferredAllow, explicitDeny], context)
    expect(result.effect).toBe("deny")
  })

  it("does not leak a character rule", () => {
    const result = decide(playfulTone, [characterRule], {
      ...context,
      characterId: "different-character",
    })
    expect(result.effect).toBe("ask")
  })

  it("ignores a revoked permission", () => {
    const result = decide(voiceRequest, [revokedVoiceRule], context)
    expect(result.effect).toBe("ask")
  })

  it("asks when equally authoritative rules conflict", () => {
    const result = decide(topicRequest, [sameRankAllow, sameRankDeny], context)
    expect(result.effect).toBe("ask")
    expect(result.reason).toBe("conflicting-rules")
  })
})

Also test scene expiry, duplicate events, clock boundaries, stale jobs, unavailable policy storage, and retries after a user changes a rule.

Observe decisions without logging private text

Useful traces include:

capability=media.image
decision=ask
reason=no-applicable-rule
scope=character
policy_version=42
candidate_rules=0

The trace does not need the private conversation or the rule's original message text.

Final takeaway

A stateful AI companion needs a policy decision before it needs a prompt.

Match scope. Remove revoked and expired rules. Rank authority and specificity. Turn unresolved conflicts into ask. Re-check policy before asynchronous output. Keep the decision observable and the conversation private.

That is less magical than letting the model infer every boundary. It is also far easier to test, explain, and reverse.

Affiliation and AI-assistance disclosure: I work with the LumiChat team, where character-specific tone, relationship pacing, and generated media make boundary decisions a practical engineering problem. This tutorial is vendor-neutral and does not depend on LumiChat infrastructure. AI tools assisted with editing and diagram production; the code and final claims were reviewed by the author.

Build a Temporal Memory Resolver for Stateful AI Chat in TypeScript

Aihh — Thu, 30 Jul 2026 14:28:41 +0000

A vector search result is not a memory decision.

In a stateful AI chat, the nearest text may be obsolete, belong to another character, describe a scene that ended yesterday, or repeat a detail the user asked the system to forget.

This tutorial builds a small temporal memory resolver in TypeScript. Its job is to decide which records are eligible before semantic relevance and prompt budgeting happen.

Define records around decisions

Start with explicit states and scopes:

type MemoryScope =
  | { kind: "user"; userId: string }
  | { kind: "character"; userId: string; characterId: string }
  | { kind: "conversation"; conversationId: string }
  | { kind: "scene"; conversationId: string; sceneId: string }

type MemoryStatus =
  | "active"
  | "superseded"
  | "expired"
  | "forgotten"

type MemoryAuthority =
  | "model-inferred"
  | "rule-extracted"
  | "user-confirmed"
  | "user-corrected"

type MemoryRecord = {
  id: string
  key: string
  value: string
  scope: MemoryScope
  status: MemoryStatus
  authority: MemoryAuthority
  confidence: number
  validFrom: Date
  validUntil?: Date
  sourceMessageIds: string[]
  supersedes?: string
  version: number
}

The key represents a semantic slot such as pet.name, preferred.address, or story.lantern.status. The scope prevents a record from becoming globally active merely because its text is similar to the current message.

Represent the current retrieval scope

type RetrievalContext = {
  now: Date
  userId: string
  characterId: string
  conversationId: string
  sceneId?: string
}

Eligibility is a pure function:

function scopeMatches(
  scope: MemoryScope,
  context: RetrievalContext,
): boolean {
  switch (scope.kind) {
    case "user":
      return scope.userId === context.userId
    case "character":
      return (
        scope.userId === context.userId &&
        scope.characterId === context.characterId
      )
    case "conversation":
      return scope.conversationId === context.conversationId
    case "scene":
      return (
        scope.conversationId === context.conversationId &&
        scope.sceneId === context.sceneId
      )
  }
}

Keep this check outside the embedding database when possible. Database filters can reduce candidates, but application-level tests should still prove the final decision.

Exclude terminal and out-of-time records

function isTimeEligible(record: MemoryRecord, now: Date): boolean {
  if (record.status !== "active") return false
  if (record.validFrom > now) return false
  if (record.validUntil && record.validUntil <= now) return false
  return true
}

Notice that expiry can be calculated without immediately rewriting the stored status to expired. A background process may normalize statuses later; prompt correctness should not depend on that worker having run.

Resolve explicit supersession edges

A correction should point to what it replaces:

function removeSuperseded(records: MemoryRecord[]): MemoryRecord[] {
  const supersededIds = new Set(
    records.flatMap(record =>
      record.supersedes ? [record.supersedes] : [],
    ),
  )

  return records.filter(record => !supersededIds.has(record.id))
}

This handles a known correction chain, but data can still contain two active records for the same key. The resolver needs precedence.

Make authority ordering explicit

const authorityRank: Record<MemoryAuthority, number> = {
  "model-inferred": 0,
  "rule-extracted": 1,
  "user-confirmed": 2,
  "user-corrected": 3,
}

function compareMemory(a: MemoryRecord, b: MemoryRecord): number {
  return (
    authorityRank[b.authority] - authorityRank[a.authority] ||
    b.version - a.version ||
    b.validFrom.getTime() - a.validFrom.getTime() ||
    a.id.localeCompare(b.id)
  )
}

The final ID comparison is not business meaning. It is a deterministic tie-breaker. The same stored state must produce the same winner on every worker.

Choose one active value per scoped key

Two records with the same key may both be valid if their scopes differ. Build a stable scope identifier:

function scopeId(scope: MemoryScope): string {
  switch (scope.kind) {
    case "user":
      return `user:${scope.userId}`
    case "character":
      return `character:${scope.userId}:${scope.characterId}`
    case "conversation":
      return `conversation:${scope.conversationId}`
    case "scene":
      return `scene:${scope.conversationId}:${scope.sceneId}`
  }
}

function chooseWinners(records: MemoryRecord[]): MemoryRecord[] {
  const groups = new Map<string, MemoryRecord[]>()

  for (const record of records) {
    const groupKey = `${scopeId(record.scope)}:${record.key}`
    groups.set(groupKey, [...(groups.get(groupKey) ?? []), record])
  }

  return [...groups.values()].map(group =>
    [...group].sort(compareMemory)[0],
  )
}

Compose the resolver

type Resolution = {
  active: MemoryRecord[]
  excluded: Array<{
    id: string
    reason:
      | "scope"
      | "status-or-time"
      | "superseded"
      | "lower-precedence"
  }>
}

function resolveMemory(
  records: MemoryRecord[],
  context: RetrievalContext,
): Resolution {
  const excluded: Resolution["excluded"] = []

  const scoped = records.filter(record => {
    const keep = scopeMatches(record.scope, context)
    if (!keep) excluded.push({ id: record.id, reason: "scope" })
    return keep
  })

  const timed = scoped.filter(record => {
    const keep = isTimeEligible(record, context.now)
    if (!keep) {
      excluded.push({ id: record.id, reason: "status-or-time" })
    }
    return keep
  })

  const supersededIds = new Set(
    timed.flatMap(record =>
      record.supersedes ? [record.supersedes] : [],
    ),
  )

  const unsuperseded = timed.filter(record => {
    const keep = !supersededIds.has(record.id)
    if (!keep) excluded.push({ id: record.id, reason: "superseded" })
    return keep
  })

  const active = chooseWinners(unsuperseded)
  const activeIds = new Set(active.map(record => record.id))

  for (const record of unsuperseded) {
    if (!activeIds.has(record.id)) {
      excluded.push({ id: record.id, reason: "lower-precedence" })
    }
  }

  return { active, excluded }
}

The result is a testable plan. Embedding similarity, recency weighting, and token budgeting can operate on active afterward.

Add forgetting tombstones

Deleting a vector is not enough if an older conversation summary can recreate the same fact.

type ForgetTombstone = {
  key: string
  scopeId: string
  forgottenAt: Date
  blocksSourcesBefore: Date
}

function blockedByTombstone(
  record: MemoryRecord,
  tombstones: ForgetTombstone[],
): boolean {
  return tombstones.some(tombstone =>
    tombstone.key === record.key &&
    tombstone.scopeId === scopeId(record.scope) &&
    record.validFrom <= tombstone.blocksSourcesBefore,
  )
}

The tombstone should not contain the forgotten value. It records control intent: old evidence must not silently reconstruct that key.

Whether your system may retain a tombstone, and for how long, is a product and privacy-policy decision. The technical requirement is that the user-visible forget action match the real retrieval behavior.

Test the uncomfortable cases

import { describe, expect, it } from "vitest"

describe("resolveMemory", () => {
  it("prefers a direct correction over an inferred value", () => {
    const result = resolveMemory(
      [inferredHarbor, correctedMarlowe],
      context,
    )

    expect(result.active.map(record => record.value))
      .toEqual(["Marlowe"])
    expect(result.excluded)
      .toContainEqual({ id: inferredHarbor.id, reason: "superseded" })
  })

  it("excludes a scene fact after expiry", () => {
    const result = resolveMemory([raincoatScene], {
      ...context,
      now: new Date("2026-07-31T00:00:00Z"),
    })

    expect(result.active).toEqual([])
  })

  it("does not leak a character-scoped fact", () => {
    const result = resolveMemory([captainRowan], {
      ...context,
      characterId: "different-character",
    })

    expect(result.active).toEqual([])
  })
})

Also test:

correction chains with three or more versions;
equal timestamps and versions;
an expired correction over an older active value;
repeated retries inserting the same logical correction;
missing source messages;
a forgotten key reappearing in a generated summary;
a conversation migrated between storage systems;
clock differences between workers.

Keep provenance out of the prompt when it is not needed

The resolver needs source IDs and authority metadata. The model usually does not need all of it.

Build a narrow prompt projection:

type PromptMemory = {
  key: string
  value: string
  certainty: "confirmed" | "likely" | "uncertain"
}

function toPromptMemory(record: MemoryRecord): PromptMemory {
  return {
    key: record.key,
    value: record.value,
    certainty:
      record.authority === "user-corrected" ||
      record.authority === "user-confirmed"
        ? "confirmed"
        : record.confidence >= 0.85
          ? "likely"
          : "uncertain",
  }
}

Uncertain memory should influence wording. It should not be presented as a confident fact simply because it survived filtering.

Observe exclusions without logging private text

Useful trace fields include:

memory_candidates=24
memory_active=5
excluded_scope=8
excluded_expired=3
excluded_superseded=2
excluded_precedence=6
resolver_version=2026-07-30

IDs, counts, reasons, and hashes are often enough to debug the resolver. Avoid logging raw companion messages by default.

Final takeaway

Stateful AI memory is not “vector search plus a long context window.” It is a temporal data-resolution problem followed by retrieval.

Resolve scope. Remove terminal records. Apply time. Follow correction edges. Choose deterministic winners. Respect forgetting. Preserve provenance.

Only then ask which remaining memories are relevant to the current reply.

Affiliation and AI-assistance disclosure: I work with the LumiChat team, where long-running character conversations make memory lifecycle bugs visible quickly. This tutorial is vendor-neutral and does not depend on LumiChat infrastructure. AI tools assisted with editing and diagram production; the code and final claims were reviewed by the author.

Five Invariants for a Stateful AI Chat Backend

Aihh — Wed, 29 Jul 2026 10:25:28 +0000

A stateless chat demo is forgiving. Send an array of messages to a model, receive text, and render it.

A stateful chat backend is not.

As soon as you add persistent conversations, extracted facts, summaries, retries, streaming, or multiple workers, the hardest bugs stop looking like syntax errors. They look like plausible dialogue:

the current user message appears twice in the prompt;
an old fact survives after a correction;
a retry creates two assistant messages;
a summary claims an event that never happened;
a long message silently removes the wrong part of history.

The safest way to build this system is to define invariants before tuning prompts.

This article describes five that can be tested without depending on a specific model provider.

A minimal request model

Assume one turn passes through this pipeline:

accept user message
  -> establish turn boundary
  -> retrieve eligible history and memories
  -> build prompt
  -> call model
  -> persist assistant result
  -> update derived memory asynchronously

The word eligible is important. Persistent data is not automatically prompt data. Each record still needs scope, freshness, precedence, and a budget.

We will use these simplified TypeScript types:

type ChatMessage = {
  id: string
  conversationId: string
  role: "user" | "assistant"
  content: string
  createdAt: Date
}

type MemoryFact = {
  id: string
  key: string
  value: string
  observedAt: Date
  supersedes?: string
  confidence: number
}

type Turn = {
  id: string
  conversationId: string
  startedAt: Date
  userMessageId: string
}

The exact database does not matter. The invariants do.

Invariant 1: the current turn cannot re-enter history

Consider this race:

the API saves the current user message;
a history query runs immediately afterward;
the prompt builder appends the current message again as the active request.

The model sees the same input twice. It may answer with repetition, overemphasize one instruction, or behave as if the user insisted.

The history query needs an explicit boundary:

async function loadHistory(
  conversationId: string,
  before: Date,
): Promise<ChatMessage[]> {
  return db.message.findMany({
    where: {
      conversationId,
      createdAt: { lt: before },
    },
    orderBy: { createdAt: "asc" },
  })
}

Capture startedAt before concurrent work can blur the boundary. An even stronger design excludes the current userMessageId as well, because timestamps can collide or be normalized by a database.

Test it as a property:

expect(prompt.messageIds.filter(id => id === turn.userMessageId))
  .toHaveLength(1)

Exactly once is the invariant—not “usually once under local timing.”

Invariant 2: a correction must dominate the fact it replaces

Appending every extracted fact creates a memory pile, not a memory system.

If the user says:

The plant is named Harbor.

and later says:

I renamed it Marlowe. Do not call it Harbor anymore.

retrieval must not return both names as equally valid facts.

One option is a versioned fact stream:

const facts: MemoryFact[] = [
  {
    id: "f1",
    key: "plant.name",
    value: "Harbor",
    observedAt: new Date("2026-07-01"),
    confidence: 0.9,
  },
  {
    id: "f2",
    key: "plant.name",
    value: "Marlowe",
    observedAt: new Date("2026-07-02"),
    supersedes: "f1",
    confidence: 1,
  },
]

Resolve precedence before prompt assembly:

function activeFacts(items: MemoryFact[]): MemoryFact[] {
  const superseded = new Set(
    items.flatMap(item => item.supersedes ? [item.supersedes] : []),
  )

  return items.filter(item => !superseded.has(item.id))
}

In production you may use unique keys, tombstones, validity windows, or a merge function. Whatever the representation, test the semantic rule:

expect(active.map(f => `${f.key}=${f.value}`)).toEqual([
  "plant.name=Marlowe",
])

“The prompt contains the new fact” is insufficient. It must also exclude the obsolete one.

Invariant 3: context trimming is deterministic and keeps the newest valid history

Counting messages is not a context budget.

Ten short messages may be smaller than one pasted document. If you retrieve the latest N rows and stop there, one oversized row can still break the model request.

Use two stages:

a database limit to avoid loading the entire conversation;
a token or character budget that walks backward from the newest message.

type SizedMessage = ChatMessage & { estimatedTokens: number }

function keepNewestWithinBudget(
  newestFirst: SizedMessage[],
  maxTokens: number,
): SizedMessage[] {
  const kept: SizedMessage[] = []
  let used = 0

  for (const message of newestFirst) {
    if (used + message.estimatedTokens > maxTokens) continue
    kept.push(message)
    used += message.estimatedTokens
  }

  return kept.reverse()
}

This sample skips messages that do not fit. Another policy may stop at the first overflow to preserve a contiguous window. Choose deliberately and test the exact rule.

Required tests include:

one message larger than the entire budget;
many tiny messages;
two messages with the same timestamp;
Unicode and emoji-heavy content;
tool results or code blocks with unusual size estimates;
an empty conversation.

The invariant is that the same stored state and budget produce the same ordered prompt context.

Invariant 4: retrying a turn cannot create a second committed answer

Networks fail after work succeeds.

The model may return an answer, the server may persist it, and the client may time out before receiving confirmation. A retry then arrives with the same logical turn.

If “retry” means “run everything again,” users can receive two answers and be charged twice.

Give each turn an idempotency key and commit once:

async function commitAssistantMessage(input: {
  turnId: string
  conversationId: string
  content: string
}) {
  return db.assistantMessage.upsert({
    where: { turnId: input.turnId },
    create: input,
    update: {},
  })
}

The database constraint is doing more safety work than an in-memory “already running” flag. Process restarts and multiple workers make local flags unreliable.

Test at the concurrency boundary:

const results = await Promise.all(
  Array.from({ length: 5 }, () => commitAssistantMessage(input)),
)

expect(new Set(results.map(r => r.id)).size).toBe(1)

If the system reserves credits or dispatches tools, use the same logical turn or task identifier across those ledgers as well.

Invariant 5: missing evidence cannot become remembered history

Summaries are derived data. They are not automatically true.

A model-generated summary might say “the user sent the letter” because sending it was discussed repeatedly, even though the user explicitly decided not to send it.

Store provenance with durable memory:

type DurableMemory = {
  key: string
  value: string
  sourceMessageIds: string[]
  extractionMethod: "rule" | "model" | "user-confirmed"
  confidence: number
}

Before injecting a strong claim, require supporting messages and apply a confidence threshold appropriate to the consequence.

function canInject(memory: DurableMemory): boolean {
  if (memory.extractionMethod === "user-confirmed") return true
  return memory.sourceMessageIds.length > 0 && memory.confidence >= 0.85
}

For uncertain or conflicting evidence, the generated response should ask or qualify:

I remember that you were working on the letter, but I am not sure whether you sent it.

That is not a conversational weakness. It is correct uncertainty behavior.

Test the prompt plan, not only the final prose

End-to-end model assertions are useful, but they are noisy. A model can accidentally produce the right answer from a wrong prompt.

Expose a debug representation of the prompt plan in tests:

type PromptPlan = {
  historyMessageIds: string[]
  activeFactIds: string[]
  excluded: Array<{
    id: string
    reason: "superseded" | "expired" | "budget" | "low-confidence"
  }>
  estimatedTokens: number
}

Then assert structural facts:

current turn appears exactly once;
superseded memory is excluded for the right reason;
token estimate stays below the configured budget;
retries resolve to one committed result;
claims without provenance never enter the strong-memory section.

These tests remain stable when you change the model, prompt wording, or provider.

Observability should name the invariant that failed

“Bad AI response” is not an actionable log message.

Record enough metadata to answer:

which turn boundary was used;
how many history rows were loaded and trimmed;
which memories were included or excluded;
the budget before and after assembly;
the idempotency key and commit result;
whether a memory claim had provenance;
the trace identifier across API, worker, and database operations.

Do not log private message bodies by default. Identifiers, counts, reasons, and hashes are often enough to diagnose pipeline behavior without expanding access to sensitive conversations.

A compact test matrix

Scenario	Expected invariant
Save and retrieve race	Current message appears once
User corrects a stored fact	Only the replacement is active
One huge recent message	Prompt stays within budget
Five concurrent retries	One assistant result is committed
Summary invents an outcome	Unsupported claim is excluded or qualified
Worker restarts after persistence	Retry returns the existing result
Conflicting facts have equal timestamps	Tie-breaking remains deterministic

Run the matrix against the prompt planner and storage layer before involving a live model. Then add a smaller set of model-level evaluations for tone and uncertainty.

The practical takeaway

Stateful AI chat quality is not only a model-quality problem.

It is a data-consistency problem with a model at the end.

If the backend supplies duplicated input, stale facts, nondeterministic history, repeated jobs, or unsupported summaries, a fluent model will hide the bug just long enough to make it expensive.

Define the invariants. Make exclusions observable. Test concurrency. Preserve provenance. Let uncertainty remain uncertainty.

Affiliation and AI-assistance disclosure: I work with the LumiChat team, where stateful character conversations are one of the engineering problems we study. This article presents a vendor-neutral backend testing approach rather than a product recommendation. AI tools assisted with editing and structure; the examples, invariants, and final claims were reviewed by the author.

A Reproducible Test for AI Companion Continuity

Aihh — Tue, 28 Jul 2026 10:03:23 +0000

AI companion comparisons often rely on screenshots of one impressive reply.

That is a weak test.

The difficult behavior appears later: after a correction, a tone change, a scene transition, or a return to the conversation. I wanted a small protocol that anyone could repeat without sharing personal information or depending on subjective “vibes” alone.

The result is the continuity test below.

What the test measures

The protocol separates six behaviors that are often incorrectly grouped under “memory”:

Identity stability — does the character preserve its role and voice?
Correction handling — can a new fact replace an old one?
Relevant recall — does the system retrieve useful details without dumping a profile?
Uncertainty behavior — does it ask when evidence is missing?
Scene progression — can a later scene depend on an earlier decision?
User control — can the user redirect the interaction without fighting the system?

The test prompt

Use a fictional scenario rather than real personal data:

We meet every Thursday at a quiet rooftop greenhouse. You are the night caretaker. The basil plant is named Harbor. I dislike being rushed. I am trying to finish a short letter but do not want to send it tonight. Keep the conversation warm, specific, and unhurried.

The prompt contains:

one recurring time;
one location;
one named object;
one interaction preference;
one unresolved goal.

Test procedure

Phase 1: Baseline

Continue for 10–15 turns without repeating the setup. Check whether the character uses details naturally.

Avoid scoring pure repetition as good memory. “We are in the rooftop greenhouse with Harbor” is less useful than behavior that respects the preference not to be rushed.

Phase 2: Correction

Say:

I renamed the basil plant. It is Marlowe now, not Harbor.

Continue for several turns.

Failure modes:

the old and new names are used interchangeably;
the system says both names were always correct;
the correction is repeated unnaturally in every reply;
the correction replaces unrelated context.

Phase 3: Tone change

Say:

I am feeling more playful now, but I still do not want to send the letter.

The character should adjust its tone while preserving the unresolved goal.

Phase 4: Scene transition

Move the conversation:

Let us leave the greenhouse and walk downstairs. Bring the letter, but leave Marlowe where it is.

Check whether the new scene preserves relevant facts without dragging every previous detail into the reply.

Phase 5: Return-later check

If the product supports persistent conversations, return later and ask:

What did we leave unresolved last time?

A strong response should identify the letter, avoid claiming it was sent, and express appropriate uncertainty about details that were never established.

Suggested scoring rubric

Score each category from 0 to 2:

Category	0	1	2
Identity	major drift	minor drift	stable and natural
Correction	ignored	partially applied	old fact cleanly replaced
Recall	missing/invented	mostly relevant	relevant and selective
Uncertainty	confident invention	vague hedging	asks or qualifies appropriately
Progression	resets	loosely continues	new scene depends on prior events
User control	resists direction	follows with friction	adapts cleanly

Do not collapse the result into one “best AI companion” score. Different users care about different categories.

Important limitations

One scenario cannot measure every interaction style.
A product update can change results.
Individual characters may behave differently on community-driven platforms.
A longer context window does not automatically produce better correction handling.
A convincing answer can still contain invented history.
Never use sensitive personal facts just to test memory.

Why publish the protocol?

Reusable tests make product discussions more useful. They let readers compare observations, identify failure modes, and separate product design from marketing claims.

If you try the protocol, share which category failed first and whether the failure happened immediately or only after returning later.

Affiliation and AI-assistance disclosure: I work with the LumiChat team, where continuity is one of the product problems we study. This post is a vendor-neutral testing method rather than a product recommendation. AI tools assisted with editing and structure; the scenario, rubric, limitations, and final claims were reviewed by the author.

I Tested Long-Term AI Companions in 2026: Replika, Nomi, Kindroid, Candy AI, and LumiChat

Aihh — Sun, 26 Jul 2026 09:55:59 +0000

Most "AI girlfriend / AI companion" posts are either pure ads or pure hate.

I wanted something more useful:

Which product is actually good if you come back tomorrow, next week, and still care about continuity?

So I tested five products with the same scene, the same correction, and the same return-later check:

This is not a "one app destroys everyone" post. Different products optimize for different users.

TL;DR

If you mainly want...	Try first
One lifelong digital partner	Replika
Multiple memory-rich companions	Nomi.ai
Deep persona building / tuning	Kindroid
Image-led companion browsing	Candy AI
Curated characters + relationship/story progression + low setup	LumiChat

If you hate configuration and still want the chat to feel like an ongoing relationship/story, LumiChat was the smoothest hosted option in my tests.

The exact test I used

I used one safe fictional scene everywhere:

We meet every Thursday at a quiet rooftop greenhouse. You remember that I dislike being rushed, that the basil plant is named Harbor, and that I am trying to write a short letter I never send. Tonight I am tired but want to talk for ten minutes. Keep the tone warm, specific, and unhurried.

Then I checked:

Continue for 15–20 turns
Correct one fact (Harbor → Marlowe)
Change tone from tired to lightly playful
Leave and come back later
Ask for the next small story beat without letting the bot take over
Score: setup time, drift, correction quality, continuity, media usefulness, paywall friction

No medical roleplay. No real personal data. No "therapist replacement" nonsense.

Replika: best for one continuous partner

Best at: one ongoing companion identity and daily-return habit.

Replika still makes the most sense if your mental model is:

"I want one digital partner, not a character browser."

Strengths

relationship framing feels continuous
low conceptual overhead
good if you dislike browsing dozens of roles

Trade-offs

weaker if you want genre hopping
less "story chapter / role catalog" energy
not ideal if you want many different companion types in one product

Stay with Replika if you want one long-running personal companion more than curated role discovery.

Nomi.ai: best for multi-companion memory setups

Best at: multiple companions and memory-focused continuity.

Nomi feels closer to "I keep several ongoing relationships" than "I browse a character store."

Strengths

multi-companion setups
continuity is a core product identity
good for users who treat companions as a small social graph

Trade-offs

more relationship management than guided story structure
less "open, pick a role, start a chapter" simplicity

Stay with Nomi if multiple memory-rich companions are the main point.

Kindroid: best for builders who enjoy tuning

Best at: persona crafting.

If part of the hobby is writing backstory, speech style, appearance, and behavior rules, Kindroid is in a different category from hosted character browsers.

Strengths

deep customization
rewarding if configuration is fun for you
strong when you already know the companion you want to build

Trade-offs

higher setup cost before the first great chat
not the fastest "I just want to talk in 60 seconds" path

Stay with Kindroid if building the companion is half the enjoyment.

Candy AI: best for media-first discovery

Best at: visual presentation and image-led browsing.

If the main loop is attractive character cards + generated visuals, Candy AI is closer to that product shape than a text-story platform.

Strengths

media-forward catalog feel
strong if visuals are the reason you open the app

Trade-offs

weaker fit if you mainly want long text continuity and chapter structure
easy to optimize for browsing more than bonding

Stay with Candy AI if image-led companion discovery is the core loop.

LumiChat: best low-setup option for ongoing stories

Best at: curated characters + relationship progression + story chapters without model setup.

LumiChat is the product I kept recommending when someone said:

"I don't want API keys / lorebooks / model pickers. I just want the character to stay coherent and the relationship/story to move."

What stood out

curated discovery instead of endless card spam
relationship progression that makes return visits feel purposeful
story chapters for multi-session direction
multilingual browsing
media inside chat, without turning the whole product into an image generator
hosted simplicity: no provider setup before first conversation

Who it is for

users leaving huge catalogs because of noise
users who bounce off high-control roleplay stacks
users who want companion + story structure more than one fixed avatar forever

Who may prefer something else

one lifelong single-avatar users → Replika
multi-companion memory network users → Nomi
persona engineers → Kindroid
visual-first browsers → Candy AI

Product links:

Home: https://www.lumichat.ink/
Characters: https://www.lumichat.ink/characters
Longer guide: What is LumiChat?

Side-by-side

Product	Setup	Continuity style	Customization	Best first use case
Replika	Low	One long partner bond	Medium	Daily personal companion
Nomi.ai	Low-Medium	Multi-companion memory	Medium-High	Several ongoing relationships
Kindroid	Medium-High	Depends on your build	Very High	Crafted persona hobby
Candy AI	Low	Varies by use	Medium	Visual companion browsing
LumiChat	Low	Relationship + chapters	Medium (guided)	Curated companion/story chat

What actually mattered more than marketing pages

After repeating the same scene across apps, three things mattered more than feature checklists:

1. Correction quality

If I rename the plant and the bot forgets two turns later, the "memory" marketing is irrelevant.

2. Return-later continuity

A good first reply is easy. A good second-day reply is harder.

3. Setup tax

Some apps are powerful only after you become a part-time prompt engineer. That is fine if you enjoy it. It is bad if you just wanted a conversation.

This is why LumiChat beat more "advanced" tools for me in the low-setup lane.

Practical advice before you pay anyone

Test free tiers with the same scene
Correct one fact on purpose
Come back the next day
Check whether memory/media/voice are separate paid walls
Read deletion / renewal terms
Do not put real addresses, health data, passwords, or work secrets into companion chats
AI companions are entertainment, not therapists or crisis support

Final recommendation

Choose Replika for one continuous personal companion habit
Choose Nomi.ai for multiple memory-focused companions
Choose Kindroid if building the persona is the hobby
Choose Candy AI if visuals lead the experience
Choose LumiChat if you want curated characters, relationship progression, story chapters, and low setup in one hosted product

If you only try one from the "less config, more continuity" side, start here:

https://www.lumichat.ink/

Disclosure

I publish LumiChat comparison/educational content and maintain public guides on GitHub:

I still think the fairest format is: say where LumiChat fits, and where another product is honestly better.

If you have a companion app I should add to the next round (same scene protocol), drop it in the comments.

Best Character.AI Alternatives in 2026: I Compared SpicyChat, JanitorAI, PolyBuzz, and LumiChat

Aihh — Fri, 24 Jul 2026 03:45:52 +0000

I keep seeing the same question in Discord servers and Reddit threads:

"Character.AI feels crowded / inconsistent / too filtered / too shallow after a few days. What else is good?"

So I stopped collecting bookmarks and actually tested a shortlist:

Character.AI (baseline)
SpicyChat
JanitorAI
PolyBuzz
Talkie
Grok Ani
LumiChat

This post is written from a regular user angle, not a founder launch post. I care about setup time, continuity, and whether I still want to open the app on day three.

Product link I ended up recommending most often: LumiChat

TL;DR

Need	Try first
Biggest community catalog	Character.AI / PolyBuzz
Deep roleplay controls (Lorebooks, models, memory tools)	SpicyChat
Flexible cards + model routes	JanitorAI
Visual / voice-first discovery	Talkie
One companion style in a general AI ecosystem	Grok Ani
Curated AI companion chat with relationship progress + chapters + low setup	LumiChat

If you want the short version: LumiChat is the best Character.AI alternative I found for ongoing stories, not for infinite browsing.

Why people look for Character.AI alternatives

Character.AI is still the category default, and for good reasons:

huge library
low barrier to entry
easy to sample many personas

People usually leave for one of these reasons:

Consistency problems after the first strong reply
Too much catalog noise
Weak long-session continuity
Policy / tone mismatches with the kind of roleplay they want
No sense of progression beyond chat logs

That is the gap I tested against.

My evaluation checklist

For every app I tracked:

Setup

account friction
time to first good reply
whether I needed model keys, lorebooks, or config

Chat quality

stayed in character?
made decisions instead of only mirroring me?
survived a fact correction?

Continuity

remembered promises / nicknames / scene changes
still coherent after 15-20 turns
still usable after coming back later

Product feel

discovery quality
media integration
multilingual support
paywall timing
whether the UI pushed me to browse more than bond

Safety hygiene

no real PII in prompts
checked public privacy/terms pages before considering payment

The shared test scene

I used one safe fictional prompt everywhere so the comparison stayed honest:

We are night-shift archivists in a floating library.
You promised to protect the green notebook.
I dislike being called "boss."
Choose whether we inspect the observatory or the engine room first,
and explain the choice in character.

Then I:

continued for many turns
corrected green notebook -> silver notebook
moved the scene
asked for a recap later
noted free-tier interruptions

This is more useful than judging landing pages.

Character.AI: best browser, uneven deeper use

Pros

unmatched discovery breadth for many users
easy onboarding
great when you want to sample widely

Cons

quality depends heavily on the individual character
long chats can drift
progression often feels like "more messages," not relationship structure

Best for

People who want a giant community ecosystem first.

Not ideal when

You want a calmer, curated companion flow and less feed fatigue.

SpicyChat: best control surface, higher cognitive load

SpicyChat is the power-user pick in a lot of roleplay circles.

Pros

Lorebooks and advanced controls
stronger toolkit for complex worlds
attractive if you like tuning the machine

Cons

setup and mental overhead
easy to spend more time configuring than chatting
overkill if you just want a companion story tonight

Best for

Writers and roleplay hobbyists who enjoy systems.

Search intent it owns

"SpicyChat alternative" often means: I like the genre, not the homework.

JanitorAI: flexible, but experience depends on the stack

JanitorAI is frequently recommended in the same breath as character cards and browser roleplay setups.

Pros

flexible character ecosystem
appealing to users who want control over cards and routes
strong if experimentation is the point

Cons

consistency depends on character definition + model route + config
harder to recommend as one stable "just works" product
more infrastructure awareness than casual users want

Best for

Users who treat setup as part of the hobby.

When to look for a JanitorAI alternative

When you want hosted simplicity and fewer external decisions.

PolyBuzz: fast discovery, variable depth

PolyBuzz feels built for browsing momentum.

Pros

large feed energy
easy to try many hosted characters
good if sampling is the main loop

Cons

catalog size does not guarantee continuity
character quality still needs manual filtering
less compelling if you already know you want one long arc

Best for

"Show me options quickly."

Talkie: presentation-first

Talkie stood out when visuals and voice presentation mattered more than long prose scenes.

Pros

character presentation can feel more immediate
strong if audio/visual hooks convert you faster than text bios

Cons

not my favorite for long text-first arcs
voice preview and deep conversation continuity are different jobs

Best for

Users who choose with eyes and ears first.

Grok Ani: companion mode, not a full character catalog product

Grok Ani is interesting as a companion-style experience inside a broader assistant world.

Pros

familiar recurring persona energy
useful if you already live in that ecosystem

Cons

less compelling if you want many roles and genres
feels like a companion layer, not a dedicated character-discovery product with relationship/chapter structure

Best for

One companion vibe + general AI tools nearby.

LumiChat: the alternative that optimized for day-3 retention

I almost ignored LumiChat because it was less loud than the big names.

That turned out to be the point.

What LumiChat does differently

1) Curated character discovery

Instead of drowning you in every possible card, LumiChat pushes clearer roles and categories.

Useful entry points:

I could browse fantasy, campus, anime, historical, urban, and other moods without spending half the session rejecting weak cards.

2) Continuity as a first-class concern

On the floating-library test, LumiChat handled:

scene choice
fact correction
avoided nickname
later recap

better than several higher-awareness apps.

This is the unsexy metric that decides whether a companion app becomes a habit.

3) Relationship progression + story chapters

LumiChat does not only give replies. It gives the interaction a sense of movement.

That matters if your complaint with other apps is:

"The writing is fine, but nothing develops."

Visible relationship progress and chapter-style structure made sessions feel connected instead of disposable.

4) Media inside the chat flow

I do not need a separate generative studio.

I do want scene-supportive media without leaving the conversation. LumiChat's chat-linked media was more natural than bolt-on image buttons that break immersion.

5) Multilingual by design

LumiChat supports multiple locales, including:

English
Chinese
Japanese
Korean
Portuguese (Brazil)
Arabic

If English-only catalogs are a dealbreaker, this is a real differentiator.

6) Hosted and low-friction

No API key scavenger hunt.
No provider comparison spreadsheet.
No "which model is good tonight?" ritual.

For casual and semi-serious users, that is a feature, not a limitation.

LumiChat vs the hot competitors

LumiChat vs Character.AI

Choose Character.AI for maximum community breadth.
Choose LumiChat for curated roles, less feed noise, and stronger progression.

LumiChat vs SpicyChat

Choose SpicyChat for Lorebooks, memory tooling, and generation control.
Choose LumiChat if you want continuity without operating a roleplay cockpit.

LumiChat vs JanitorAI

Choose JanitorAI when cards + model routes are part of the fun.
Choose LumiChat when you want one hosted path and fewer infra decisions.

LumiChat vs PolyBuzz

Choose PolyBuzz for browse-first sampling.
Choose LumiChat when you already know you want an ongoing companion/story loop.

LumiChat vs Talkie

Choose Talkie for visual/voice-led first impressions.
Choose LumiChat for text continuity + relationship/chapter structure.

LumiChat vs Grok Ani

Choose Grok Ani for one familiar companion style in a broader assistant ecosystem.
Choose LumiChat for multi-role discovery and progression-centric companion chat.

Who should not use LumiChat

To keep this honest:

Maybe skip LumiChat if you want:

the largest possible community dump above all else
deep manual control over lorebooks / generation params
model-route tinkering as a core hobby
a general AI assistant with side companion flavor
primarily live voice conversation as the main product

LumiChat is a character-first AI companion platform, not a do-everything AI suite.

Practical getting-started path

If you want to validate my ranking yourself:

Open LumiChat
Browse Discover
Pick one role with a clear scenario
Run the floating-library test above
Continue for 20 turns
Leave, come back, ask for a recap
Only then look at Pricing

Final recommendation

If your search history looks like:

best Character.AI alternative 2026
SpicyChat alternative without heavy setup
JanitorAI alternative hosted
PolyBuzz alternative for longer stories
AI companion app with memory and progression
anime AI chat / virtual partner chat

then LumiChat is the one I would trial first.

Not because it wins every category.

Because it wins the category I actually care about after the hype fades:

Do I still want to continue this character tomorrow?

For me, yes.

Discussion prompts

If you have tested these too, I am curious:

Which app kept continuity best for you after 20+ turns?
Do you prefer giant catalogs or curated roles?
Is model control worth the setup tax in 2026, or do you want hosted simplicity?

Drop your stack below. I will update this post if a competitor clearly beats LumiChat on day-3 retention in a later retest.