Use case · Support agent

A returning customer is not a stranger

Q: Why does my AI support agent ask the same intake questions every time?

Each chat session starts from a clean LLM context. Without an external memory layer, there is no way for the agent to recognise that a customer has interacted before, or that a previous ticket already answered the intake questions.

Q: How does Korely scope memory per brand or per workspace?

Use agent_id="brand-acme" or agent_id="workspace-1234". Every korely.add() and every search filters by that identifier. Different brands cannot see each other memory scopes.

Q: Does it handle PII safely?

PII handling is your choice. Korely stores whatever you save, in our EU cloud with encryption at rest. We recommend hashing or tokenising email addresses and any identifier you do not want stored in plain text. The audit log records every write, and you can delete every memory for a user with one call.

Q: Can the agent see returns or refunds from a year ago?

Yes, unlimited history on paid tiers. Use the limit parameter on search, or store a date in metadata, to focus retrieval on recent interactions when older context would clutter the prompt.

Q: Does it replace my ticketing system?

No. Zendesk, Intercom, and Front stay the system of record. Korely is the cross-ticket memory the agent reads at the start of every conversation.

Past tickets, resolution outcomes, preferred channel. Saved at ticket close, read at ticket open. The agent picks up where the last conversation ended.

The pain

"Hi, what's your order number?" — for the fifth time

A customer opened three tickets last quarter. Each time, the AI support agent asked the same intake questions: name, order number, what's going wrong. Each time, the resolution was logged in the ticketing system and the chat closed. The ticketing system has the answer. The AI in the next ticket does not.

The customer comes back today. New issue, vaguely related to the second ticket. The agent has no memory of them. The customer types the order number again. The agent makes them re-explain a problem half-explained six weeks ago. The interaction feels cold and the customer wonders why they pay for the platform.

The ticketing tool is doing its job: recording. What is missing is the layer that reads back into the conversation before it starts.

The shape of the fix

Close the ticket, save the summary, recognise the customer next time

Ticket 1 — March

Refund resolved

Size exchange shipped
Prefers email over chat

Korely

Indexed by email

agent_id per brand
PII hashed in metadata

Ticket 2 — September

Recognised, fast-path

No intake repeat
Picks up from March outcome

Zendesk, Intercom, or Front stay the system of record. Korely is the layer the agent reads before opening the conversation.

How Korely fits

One `agent_id` per brand, search by customer at ticket open

On ticket close, your support flow calls korely.add() with a short summary: what the customer reported, what the agent did, what the outcome was, and any preference they expressed (channel, language, time zone). The note carries the customer's email or hashed identifier in metadata.

On ticket open, before the agent says hello, it searches Korely for that identifier. If the customer is new, the search returns nothing and the flow proceeds as usual. If the customer has history, the agent reads it and adapts the opening: "hello again, I see your refund cleared in March — is this about the same order?"

Memory lives in our EU cloud, encrypted at rest. Audit-curious customers can request an export of everything stored about them, and you can erase it with one call.

Show me the code

Save on close, read on open

support_agent.py python

# ── On ticket close ────────────────────────────────────────────
from korely_memory import Korely

korely = Korely(api_key="kor_live_...")

korely.add(
    f"Ticket #{ticket.id}: customer reported size issue on order "
    f"{ticket.order_id}. Resolution: free exchange shipped 2026-03-04. "
    f"Prefers email over chat.",
    agent_id=f"brand-{brand_id}",
    metadata={"customer_id": hash(customer.email)},
)

# ── On ticket open: search before the agent greets ─────────────
history = korely.search(
    f"history customer {customer.email}",
    agent_id=f"brand-{brand_id}",
)

if history:
    greeting = build_warm_greeting(history)
else:
    greeting = build_first_time_greeting()

   
Frequently asked
 
Support memory, common questions
    Why does my AI support agent ask the same intake questions every time? +− 
 Each chat session starts from a clean LLM context. Without an external memory layer, there is no way for the agent to recognise that a customer has interacted before, or that a previous ticket already answered the intake questions.
 
  How does Korely scope memory per brand or per workspace? +− 
 Use agent_id="brand-acme" or agent_id="workspace-1234". Every korely.add() and every search filters by that identifier. Different brands cannot see each other memory scopes.
 
  Does it handle PII safely? +− 
 PII handling is your choice. Korely stores whatever you save, in our EU cloud with encryption at rest. We recommend hashing or tokenising email addresses and any identifier you do not want stored in plain text. The audit log records every write, and you can delete every memory for a user with one call.
 
  Can the agent see returns or refunds from a year ago? +− 
 Yes, unlimited history on paid tiers. Use the limit parameter on search, or store a date in metadata, to focus retrieval on recent interactions when older context would clutter the prompt.
 
  Does it replace my ticketing system? +− 
 No. Zendesk, Intercom, and Front stay the system of record. Korely is the cross-ticket memory the agent reads at the start of every conversation.
 
 
 
 
   
Let the agent open the next ticket already informed
 
Memory lives in our EU cloud. Start free on the Hobby tier.
          The korely-memory Python and Node SDKs and REST API are live.
  Get started free 
 
Looking for a different shape?
See the other five use cases →