Customer support AI

Stop asking users the same questions twice.

The agent knows what plan the user is on. It was in the last ticket. MemexAI persists stable facts across sessions so the next conversation picks up where the last one ended — and gives your team a direct line to fix what gets wrong.

The problem

Context that resets per ticket is not a support experience — it's a form.

A user opens a ticket. The support agent asks about their plan tier, their integration setup, whether they're on the legacy API. The user answers. The ticket closes. Next week, different issue. The agent asks again.

Every session without persistent memory is equivalent to a fresh onboarding. The user builds no relationship with the product. The agent derives no compound value from previous interactions. You're paying model costs to re-establish context that already existed.

The deeper problem is distinguishing stable facts from ephemeral context. The user's plan tier is durable — worth storing and carrying forward. The specific error they saw last Tuesday is not. An agent that doesn't make this distinction either overwrites useful facts or pollutes memory with session noise.

When something does go wrong — the agent gives advice based on an outdated plan tier, or misremembers a setting — your support team has no way to see or correct what's stored. They can tell the user to re-explain themselves, but they can't actually fix the underlying memory.

For a support product, that's the worst failure mode: the AI gives wrong advice confidently, the support team can't explain why, and the fix is "start a new conversation."

How MemexAI fits

Stable facts that persist. Session noise that doesn't.

What the agent writes

The agent uses memory_remember to write facts that should outlive the session: plan tier, integration version, known issues, preferences. These go to user/profile.md or structured files like user/integrations.md.

Shared files under shared/ hold escalation policies, known product issues, support playbooks. Every agent session gets these injected — no redeploy needed when the playbook changes.

// Agent writes stable fact after first mention
await memory_remember({
  content: "User is on the Growth plan, using v2 API.",
  path: "user/profile.md"
})

// Next session: context is already loaded via getPromptBlock
// Agent knows plan tier before user says a word

What your team can do

The admin console shows every user's memory files. When a user's plan changes and the agent still thinks they're on the old tier — open the file, update the line, done. The next session gets the corrected context.

Access logs show every read and write with timestamps and tool call IDs. When you need to understand why the agent gave a specific response, you can trace the exact memory state it had at that moment.

Revision history means corrections are always reversible. If a staff edit introduces a new error, roll back to any previous version.

What you actually get

Context continuity across every interaction.

Stable facts persist across sessions — users never re-explain their setup.
Support staff can update stale facts directly, without a deployment.
Shared policies (escalation rules, product guidance) update once and propagate to all sessions.
Access logs let you trace any response back to the exact memory state that produced it.
Docs

Go deeper.