What should a support system remember, and what should it forget?

There is an easy argument for giving a support system memory. Anyone who has ever repeated the same account number, explained the same problem to three different agents or watched a chatbot forget something they wrote thirty seconds earlier already understands it. Memory makes conversations coherent. It allows the next answer to depend on the previous one. It helps a human taking over understand what already happened. It can turn a disconnected sequence of messages into something that feels like one continuous attempt to solve a problem.

The more interesting question appears a little later: how much of that should still exist tomorrow? Next month? A year from now?

I think software has a natural bias toward keeping things. Storage is cheap, databases are good at accumulating records, and deleting information feels irreversible in a way that storing another row does not. When nobody has made an explicit decision about retention, “keep it” can quietly become the default. A conversation happens, the system stores it, and unless something deliberately removes it, it remains part of the product indefinitely.

That is convenient technically. I am less convinced it is always a good way to design memory.

Remembering something should have a reason.

If a customer comes back tomorrow and asks about the same unresolved order, remembering yesterday’s conversation is obviously useful. The system can see that the package was already discussed, that the customer confirmed their address and that somebody promised to investigate with the carrier. Starting again from “How can I help you?” would be ridiculous.

Now imagine the same conversation five years later. The order was delivered, the account has changed, the employee who handled it no longer works there and nobody is ever going to reopen the case. What useful job is that transcript still doing?

Sometimes there is a good answer. The business may need records for a particular operational reason. Historical conversations might help investigate recurring disputes. They may be useful for understanding how a long-running customer relationship developed.

Sometimes the answer is simply that nobody deleted it.

“We still have it” and “we still need it” are two very different statements.

I like thinking about support data by purpose rather than by category.

The phrase “conversation history” makes thousands of different interactions sound like one kind of data. They are not.

A question about opening hours has almost no long-term relationship with the customer. A billing dispute might. A technical investigation could contain information that remains relevant until a bug is fixed. A one-time sales question may become useless the moment the customer gets the answer.

Even inside one conversation, different pieces can have different lifetimes.

The fact that a customer uses the Business plan may remain useful as long as they use that plan. The temporary error message they pasted during a failed setup may stop mattering once the issue is resolved. The name of the browser version they used that afternoon can become stale almost immediately.

Treating all of this as one giant thing called “customer data” hides those differences.

Some memory exists to continue a conversation.

This is probably the easiest category to justify.

A conversation has state. Someone asked something. The system answered. Maybe a clarifying question followed. Maybe the conversation was handed to a human. The next message depends on understanding those previous turns.

Without that memory, normal language stops working.

Customer: “Does Business support five websites?”

Support: “Yes, Business supports up to five.”

Customer: “What happens if I need six?”

The third message only makes sense because the previous exchange exists.

This kind of short-term memory should feel almost invisible. The customer expects the conversation to remember itself. When it does not, the software feels broken rather than privacy-conscious.

Some memory exists so the customer does not have to repeat the story.

Longer-running support needs a different kind of continuity.

Imagine a customer reports an intermittent issue on Tuesday. Support asks for some details, engineering investigates and the conversation continues on Thursday. Nobody wants the customer to reproduce the entire history from memory.

Keeping the relevant conversation while the issue remains active makes obvious sense.

The same applies to escalation. If automated support hands a conversation to a person, the transcript needs to travel with it. Otherwise “human handoff” becomes another way of saying “please start again.”

Memory here has a clear job: preserve continuity while the problem still exists.

The harder question begins after the problem stops existing.

Resolution changes the value of old information.

There is something important about the moment a support issue becomes finished.

Before resolution, almost every detail can matter. Which error appeared, what troubleshooting has already been attempted, which person approved an exception, what the customer said happened first.

After resolution, much of that detail loses immediate operational value.

That does not always mean delete the conversation immediately. It does mean the reason for keeping it has changed.

Perhaps the business wants a period during which the case can be reopened. Maybe support managers review recently completed conversations. Maybe the transcript is kept temporarily for quality analysis. Those are understandable purposes.

I think the important thing is noticing that “active case” and “historical archive” are different states, even if the database stores them in the same table.

Old context can become wrong context.

Retention has another problem people talk about less: information becomes stale.

Suppose a customer was on Core when they contacted support six months ago. They are now on Scale.

The old conversation says they are a Core customer.

That statement was true.

Using it as current context would be wrong.

The same happens with job titles, team roles, addresses, browser versions, subscription states, product configurations and almost anything else that can change over time.

A support system that remembers everything without understanding time can become strangely confident about outdated reality.

Memory needs some sense of when information was true and whether a fresher source exists.

Account state should usually come from the account.

This sounds obvious, but it is an important design distinction.

If the support system wants to know the customer’s current plan, I would rather it receive the current plan from the account than “remember” that six months ago the customer mentioned being on Business.

The same applies to active usage, order status, permissions and anything else the product itself can provide as current state.

Conversation history is useful for understanding what happened.

Current systems are better sources for understanding what is true now.

Mixing those two roles creates avoidable mistakes.

This is why I would separate memory from context.

The distinction has become increasingly useful to me while thinking about support systems.

Memory is what happened before.

Context is what matters now.

They can overlap, but they are not identical.

A previous conversation may explain that a customer had trouble installing something. Their current account state tells you whether installation is now complete.

Both can help.

One is historical evidence.

One is current state.

Support becomes much easier to reason about when those are not silently treated as the same thing.

There is also memory that belongs to the business rather than the customer.

Suppose ten different customers ask the same obscure question.

The individual transcripts may eventually become unnecessary, but the business has learned something valuable: this question exists and the answer should be documented.

Once the useful lesson has been turned into clean knowledge, retaining every original conversation forever may no longer be necessary for that purpose.

I like this transformation.

Messy conversations reveal a pattern.

The business reviews the pattern.

A stable piece of knowledge is created.

Future customers benefit without requiring the support system to treat every historical transcript as permanent knowledge.

Raw history and learned knowledge should not be confused.

Imagine one customer asks about an unusual exception and a human agent gives them a special accommodation.

If a future support system treats that transcript as a general policy, trouble follows immediately.

The conversation describes what happened to one customer.

It does not necessarily describe what should happen to every customer.

This is one reason I would be careful about automatically turning old support transcripts into authoritative knowledge without review.

Conversations are evidence.

Policies require intent.

A useful system needs to know the difference.

“Keep everything because AI might use it later” is not a very satisfying policy.

I understand why the argument is tempting.

Historical data might improve future answers. Maybe the business will want to analyse a trend later. Maybe a new feature will extract useful patterns from old conversations. Storage is inexpensive, so why throw potentially valuable information away?

The problem is that “might be useful” has no natural ending.

Almost any information might become useful under some hypothetical future analysis.

If that is enough justification, retention becomes permanent by default.

I prefer stronger questions.

What are we using this information for?

Is that purpose still active?

Does the full raw record need to remain, or would a smaller piece of derived knowledge accomplish the same thing?

At what point does the usefulness become too weak to justify keeping the data?

Cheap storage is an engineering fact. It does not automatically answer a product question about what deserves to remain in memory.

More memory can actually make support worse.

There is a funny assumption that adding information always improves an intelligent system.

Imagine a support agent that can search six years of customer history every time somebody asks a question.

That history contains old plans, old employees, resolved incidents, expired orders, previous products, outdated explanations and conversations about things that no longer exist.

Somewhere inside it may be useful context.

There is also an enormous amount of noise.

A smaller, fresher and more intentionally selected memory can be much easier to use correctly than an endless archive.

Human memory works a little like this too. Forgetting is annoying when you lose something important. It is incredibly useful that your brain does not present every irrelevant Tuesday afternoon from 2013 whenever you make a decision.

Forgetting can be a feature.

Software language makes deletion sound destructive.

Delete record.

Purge history.

Remove data.

All of those words feel like losing something.

In a support system, forgetting can improve clarity.

An old temporary state disappears instead of competing with the current one. A resolved issue stops following the customer around forever. A conversation that no longer serves an operational purpose leaves the system. The amount of information requiring protection becomes smaller.

There is something healthy about a system that knows some information has completed its job.

Memory is useful because it preserves continuity. Forgetting is useful because continuity does not require carrying every detail forever.

Customers probably imagine memory differently depending on the situation.

If I contact a company on Monday and continue the same problem on Tuesday, I expect them to remember Monday.

If I return three years later with a completely unrelated question, I would be surprised if the support agent casually referenced some irrelevant personal detail from that old exchange.

There is an intuitive boundary somewhere between helpful continuity and unnecessary persistence.

Different businesses will draw that boundary differently. A long-term B2B relationship can reasonably benefit from more historical context than a one-off retail purchase.

The point is that “remember as much as possible” is not automatically aligned with what feels helpful.

The most uncomfortable memory is often the memory nobody expects.

Imagine opening support and asking about a billing issue.

The system replies: “I can see you also had difficulty with a different product eleven months ago.”

Why is that relevant?

Even if the system had legitimate access to the old conversation, bringing it into the current interaction without a clear reason feels strange.

The customer is suddenly thinking about the support system’s memory rather than the support question.

Good context tends to disappear into the usefulness of the answer.

Unnecessary memory announces itself.

Names are a good example of memory that sounds more impressive than it is.

“Welcome back, Daniel.”

Fine.

It can feel pleasant.

I would still rather have support remember that I already explained the issue than remember my first name while asking me to explain everything again.

Products sometimes treat personalisation as remembering surface details.

For support, continuity is more valuable.

What was the problem?

What has already been tried?

What was promised?

What still needs to happen?

Those memories save the customer effort.

That is a good reason to remember them while they matter.

Sensitive information creates a different problem entirely.

Customers sometimes type things into support that nobody expected them to type.

They paste documents.

They paste transaction details.

They paste logs containing identifiers.

They describe private situations in much more detail than the support question actually requires.

A text box is an invitation, and people will put surprising things into it.

This makes blanket retention especially uncomfortable. The business may not have intentionally asked for a particular detail, yet once it appears in the transcript, the support system has it.

I think products should assume this will happen rather than designing around an imaginary world where customers always provide the minimum necessary information.

Reducing what enters memory can be as important as deleting it later.

Retention discussions often begin after data has already been collected.

There is an earlier question: did the support system need this information in the first place?

If a business can answer a shipping-policy question without receiving the customer’s entire profile, there is no reason to attach the profile to the conversation.

If support needs the current plan but not the full billing history, pass the plan.

If an order question needs delivery status but not every previous purchase, provide the relevant order.

The cleanest retention problem is the one you never create.

I like context that is deliberately small.

This has become one of the principles I keep returning to when thinking about Reesponder.

A business should be able to give the support agent useful customer context. That context can make answers dramatically better. It can tell the system which plan applies, what role the customer has, what page they are viewing or which order they mean.

The temptation would be to expose a giant customer object and let the system decide what to use.

I prefer the business to make deliberate choices.

If a value has a support purpose, provide it.

If it does not, keep it outside the support layer.

Small context is easier to understand, easier to control and easier to explain.

Temporary context deserves to be temporary.

Suppose a visitor is currently looking at a pricing page.

That fact can help interpret: “Does this include setup?”

Once the conversation ends, the fact that they were on that page at 15:42 last Thursday may have no future support value at all.

Context can be useful during a conversation without becoming permanent customer history.

I think this distinction is important because modern applications can generate an enormous amount of situational data.

Page.

selected product.

current UI state.

recently attempted action.

current error.

These can make support better in the moment.

That does not mean they all deserve a permanent home in the customer record.

There is a big difference between remembering an outcome and remembering every step.

Imagine a support conversation takes twenty messages to determine that an account has been moved to a new workspace.

Six months later, perhaps the useful historical fact is simply: the migration was completed on this date.

The entire debugging discussion that led there may be unnecessary.

This is similar to how businesses already work in many areas. A final account state or resolved ticket status can remain while temporary operational chatter becomes less important.

Compressing useful outcomes into cleaner records can reduce the need to treat full transcripts as permanent memory.

Summaries are useful, but they need humility.

One obvious idea is to keep a short summary after a conversation rather than the full transcript forever.

That can work well.

“Customer had trouble connecting domain example.com. DNS configuration was corrected and connection succeeded.”

Much cleaner than thirty messages of troubleshooting.

The risk is that summaries are interpretations.

Somebody, or some system, decides what mattered.

A detail left out today may become relevant later.

This does not make summaries bad. It means they should be used for appropriate purposes rather than pretending compression preserves every possible future meaning.

Different memory layers can have different lifetimes.

I think support systems become easier to reason about when memory is divided into layers.

The active conversation needs rich recent context.

An unresolved case may need the full transcript for longer.

A completed case might move into a shorter retention period.

A useful operational outcome might remain in a compact form.

General knowledge learned from repeated questions can live separately from individual customer conversations.

Current customer state continues to come from the systems that actually own it.

Suddenly “memory” becomes a set of deliberate tools instead of one endless archive.

This also makes deletion more meaningful.

If everything is copied everywhere, deletion becomes incredibly hard to reason about.

A conversation exists in the support database.

A summary exists somewhere else.

Extracted facts were written into another profile.

An export contains the original.

An analytics system contains parts of it.

Now “delete this conversation” is no longer one operation.

Good architecture helps privacy simply by making data movement understandable.

The fewer mysterious copies exist, the easier it is to know what deletion actually means.

Retention should be visible to the business using the support product.

I would be uncomfortable with a support platform silently making every retention decision for every company.

Businesses have different requirements.

A small product answering pre-sale questions may want relatively little history.

A B2B company handling long-running technical cases may need more continuity.

Another business may have internal policies requiring a specific retention period for certain support records.

The support product should make these choices understandable rather than hiding them in architecture the customer cannot see.

People should know whether conversations are being retained and have meaningful control over the behaviour that applies to their business.

“Forever” is a suspicious default.

There are situations where long retention is intentional.

What bothers me is when forever happens because nobody selected anything else.

A database table is created.

Records accumulate.

Years pass.

Eventually somebody asks how long data is retained and everyone discovers the answer is essentially “since launch.”

That is not really a retention policy.

It is gravity.

Intentional systems should know why information remains.

“Delete after 30 days” can also be too simple.

The opposite extreme is choosing one arbitrary number and applying it to everything.

Thirty days sounds privacy-conscious.

It may be terrible for a technical support case that remains open for six weeks.

A conversation about a refund dispute might need to remain available while the dispute is active.

A trivial pre-sale question probably does not need the same treatment.

Retention becomes much more sensible when it is connected to purpose and state, not just one global countdown.

Support teams should not lose useful history by surprise.

Forgetting needs to be predictable.

Imagine a human agent opens a returning case expecting to see the conversation from last month and discovers it has disappeared because an automatic retention rule ran overnight.

Technically the system followed policy.

Operationally, the support team may now be blind.

Good retention design needs clear states, clear timing and enough visibility that people understand what will disappear and when.

Privacy and usability do not need to surprise each other.

Some memories should belong to the case rather than the person.

This is another distinction I find useful.

Suppose a customer has one difficult technical incident.

The details belong to that incident.

If the issue is resolved and never returns, there may be no reason to turn every detail into a permanent characteristic of the customer.

A customer profile that slowly accumulates every historical difficulty can become a weird representation of a person.

“Had payment problem in 2024.”

“Asked for refund once.”

“Could not configure integration.”

These were events.

They do not necessarily describe who the customer is today.

Customer memory should probably be selective enough to remain useful.

If there are genuinely durable preferences or facts that improve future support, those can be valuable.

Perhaps a company account has a specific implementation architecture that will matter repeatedly.

Perhaps a customer always manages several sites through one organisation.

Perhaps there is an approved contractual arrangement relevant to future support.

These are stable enough to justify a different treatment from transient troubleshooting details.

The point is curation.

A useful memory should become more accurate over time rather than merely larger.

There is something uncomfortable about building an eternal personality from support conversations.

A person usually contacts support when something is confusing, broken or uncertain.

That is not a representative sample of their life.

If a system kept every frustrated message forever and used it to infer what kind of customer somebody is, the result could become deeply misleading.

People are impatient when their card is charged twice.

They are repetitive when a website keeps giving them the wrong answer.

They can be blunt when something important is broken.

Those moments should not necessarily become permanent traits attached to the person.

Support exists around problems. Memory needs to remember that context too.

Conversation history is valuable for quality review, but quality review does not require immortality.

We have already talked about how useful transcripts can be for understanding support quality.

Businesses can read conversations, identify repeated confusion, find missing knowledge and see where automated answers went wrong.

That is a good reason to retain history for a useful review period.

Once the conversation has been reviewed, the knowledge corrected and the relevant patterns understood, the marginal value of keeping that exact raw exchange forever may become much smaller.

Analytics and learning can have retention windows too.

Aggregates can sometimes outlive the raw conversation.

Suppose the business wants to know how many customers asked about installation this quarter.

That metric may remain useful after individual transcripts are gone.

The business can retain a count, topic trend or other aggregate without necessarily preserving every original sentence indefinitely.

This is another reason to separate operational history from reporting.

The thing needed to answer “how many?” may be much smaller than the thing needed to reconstruct every conversation.

Privacy becomes easier when the product architecture expects deletion.

Systems designed only around accumulation tend to make deletion an awkward exception.

Tables reference other tables.

Search indexes contain copies.

Cached representations survive.

Derived records lose track of their source.

Then somebody eventually needs information removed and the product discovers that its entire architecture assumed every record would remain forever.

Designing with deletion in mind from the beginning forces cleaner boundaries.

Where does this information live?

What depends on it?

What should happen when it disappears?

Those are healthy engineering questions even before privacy enters the conversation.

Reesponder should not need to know everything about the customer to answer well.

This is important to how I think about the product.

Reesponder needs enough knowledge to understand the business and enough context to understand the current support situation.

Those are already large jobs.

I do not think the product becomes automatically better by accumulating every available detail about every person who ever opens the widget.

If the customer asks whether Business includes a Zoom setup session, the answer comes from business knowledge.

If they ask whether their session has already been booked, relevant account context might help.

Their unrelated browsing history does not.

That distinction keeps the system focused on support rather than turning support into an excuse for indiscriminate collection.

Less retained data also reduces the blast radius when something goes wrong.

No system should be designed on the assumption that security failures are impossible.

Good security aims to prevent them, detect them and limit their consequences.

Retention is part of that last category.

Information that no longer exists cannot be exposed by a future compromise.

A system that keeps ten years of unnecessary conversations has created ten years of information it now needs to protect continuously.

Deletion reduces responsibility as well as storage.

I think that is a useful way to look at it. Every retained record is something the business is volunteering to keep safe.

Businesses should be able to explain why data exists without needing an engineer in the room.

A healthy retention model should be comprehensible in plain language.

We keep active conversations so support can continue them.

We keep recently resolved conversations for a defined period so cases can be reopened and support quality can be reviewed.

We keep current account context while it is relevant to answering questions.

We do not keep temporary page context indefinitely.

We remove information once its configured retention period ends.

The exact rules may vary, but the logic should be explainable.

If the answer to “why is this still stored?” requires tracing historical implementation accidents, the product probably needs attention.

There is a human benefit to knowing conversations can disappear.

I think people communicate differently when they believe every sentence becomes a permanent corporate record.

Support conversations are often casual by design.

Customers describe problems imperfectly.

They change their mind halfway through a message.

They make mistakes.

They occasionally say something slightly embarrassing while trying to explain what happened.

Treating every one of those moments as permanent identity feels unnecessary.

There is value in allowing ordinary support interactions to become historical and eventually disappear.

Support memory should behave more like a working memory than an archive of a life.

The job is to help resolve customer problems.

For that job, the system needs continuity.

It needs to know what happened earlier in the conversation.

It may need recent history for an unresolved case.

It may need durable business facts and current customer context.

None of this requires constructing an eternal record of every interaction the customer has ever had.

A good working memory keeps the material needed for the task close.

When the task changes, the useful material changes too.

Forgetting also forces the business to keep its real knowledge somewhere sensible.

There is a bad habit where important business knowledge lives only inside old support conversations.

Somebody asks a difficult question in 2025.

An employee finds the answer, sends it and closes the ticket.

Six months later another customer asks the same thing.

The team searches the old ticket because nobody ever documented the answer properly.

This works until the old ticket is unavailable, the employee leaves or the conversation becomes impossible to find.

Important knowledge deserves a proper home.

A retention policy can actually encourage this discipline. If transcripts are not assumed to exist forever, useful decisions need to be promoted into real knowledge rather than left buried inside conversation history.

The support system should remember decisions differently from discussion.

Imagine a long internal conversation eventually establishes: “Customers on Business can schedule one included setup session during their first thirty days.”

That decision is useful.

The twenty messages people exchanged while deciding it are much less useful to future customer support.

Systems become cleaner when stable outcomes are separated from the messy process that created them.

Humans work like this constantly.

We remember that the meeting decided Tuesday.

We do not need a permanent replay of every sentence spoken before Tuesday was chosen.

Some customers will want more history. Others will want less.

There is no single perfect retention period for every company.

An enterprise software provider handling complex implementation projects may value long case histories.

A simple public support widget answering product questions may need much less.

A business may also want different rules for authenticated and anonymous conversations.

That flexibility makes sense as long as the choices remain understandable.

The product should help businesses make a deliberate decision rather than quietly choosing maximum retention because that is easiest to implement.

Anonymous conversations are especially interesting.

Somebody visits a website, asks whether a product supports a feature, receives an answer and leaves.

There may be very little reason to turn that interaction into a long-lived customer record.

The conversation might be useful for short-term quality review or identifying repeated questions.

After that purpose expires, keeping the raw transcript indefinitely can become difficult to justify.

This is a good example of why identity should not be added unless it contributes something useful to support.

A visitor can receive a good answer without the system needing to know their biography.

Authenticated support changes the equation.

Once the customer is logged in, continuity can become much more valuable.

There is an established business relationship.

The customer may return with an ongoing issue.

Previous actions can affect current state.

Human agents may benefit from seeing recent conversations.

Even here, though, the value of history is uneven.

Last week’s unresolved billing conversation matters more than a one-sentence question from four years ago about where a button was located in a version of the product that no longer exists.

The existence of an account does not magically make every historical detail useful forever.

Searchability changes the privacy weight of stored information.

There is a practical difference between data sitting in an inaccessible archive and the same data being instantly searchable by every support employee.

The more accessible information becomes, the more useful it can be.

It also becomes easier to misuse accidentally.

Team access therefore matters alongside retention.

Who can read old conversations?

Does every employee need every conversation?

Can access be limited by role?

Does the system record who changed or viewed sensitive support information?

Retention answers how long something exists.

Access control answers who can do anything with it while it exists.

A private archive is still an archive.

Restricting access is valuable.

It does not answer the question of whether old information should still be retained.

This distinction matters because businesses can feel safe simply because data is behind a login.

Security and retention solve different problems.

A perfectly secured record can still be unnecessary.

An unnecessary record still requires protection.

I think the nicest privacy design is usually boring.

Customers should not need to understand a complicated theory of memory to feel comfortable with support.

The system remembers the conversation while that helps.

It uses current customer context where appropriate.

The business knows how long conversations are retained.

Old information eventually disappears according to understandable rules.

Sensitive information is not collected simply because it might be interesting.

Team access is limited to people who need it.

There is no surprise five years later when some irrelevant support detail suddenly reappears.

None of that sounds revolutionary.

That is probably good.

Privacy controls become much more useful when they correspond to real product behaviour.

A settings page can contain twenty toggles and still tell the customer very little if nobody understands what the toggles actually affect.

“Data retention: 90 days” is useful because the effect is concrete.

“Enhanced privacy mode” is much less useful unless the product explains what changes.

I like controls that map directly to behaviour.

Keep conversations for this long.

Remove them after that.

Allow these team roles to access them.

Pass these context fields to support.

Do not pass these.

Concrete controls are easier to trust because the business can reason about the consequences.

Memory should help the customer before it helps the dataset.

I think this is the test I come back to most often.

Why are we remembering this?

If the answer is that the customer will receive a better continuation of their support case, that makes sense.

If the answer is that a human agent needs the history to resolve an ongoing problem, that makes sense.

If the business needs a reasonable review period to understand support quality, also understandable.

If the answer is a vague idea that more data might be useful to something at some point, I become much less enthusiastic.

Support data originates from people trying to solve problems.

The product should respect that origin.

This is also why I do not want Reesponder to behave like a customer surveillance system.

The product has a fairly specific job.

Understand the business well enough to answer.

Understand the immediate customer situation when context genuinely changes the answer.

Preserve conversations enough for support to remain coherent and reviewable.

Involve humans when necessary.

That job does not require turning every visitor into a behavioural profile.

I would rather know less and use it well.

A customer asking a product question does not need to become an analytics project before they can receive a useful response.

There is a strange confidence in software that is willing to forget.

Keeping everything can feel safe because nothing is lost.

Choosing to delete requires knowing what the product actually depends on.

You have to understand which information is operationally necessary, which is temporary, which belongs in durable knowledge and which has completed its job.

That forces clarity.

I think clarity is healthier than a giant archive nobody wants to touch because nobody remembers what might depend on it.

The best memory may become smaller as the support system gets better.

This sounds backwards.

A young support system may rely heavily on raw history because the business is still discovering what customers ask.

Over time, repeated questions become documented knowledge. Product confusion gets fixed. Useful customer context becomes better defined. Escalation rules improve. Operational systems provide cleaner current state.

The support system becomes less dependent on searching ancient conversations for answers.

The business has learned.

That is a nice outcome.

Historical transcripts helped create better structure, and eventually some of those transcripts can leave.

A good support system should know the difference between history and baggage.

History explains what happened.

Baggage is information still being carried after it stopped helping.

The line between them moves over time.

Yesterday’s conversation may be critical today.

In six months it may be irrelevant.

A temporary troubleshooting field may matter for ten minutes.

A durable business decision may matter for years.

Designing memory means accepting these different lifetimes instead of pretending every fact deserves the same one.

The goal is not to build a support system that remembers the most. It is to build one that remembers the right things for as long as they remain useful.

I think that makes support feel more human, strangely enough.

Humans remember context selectively.

A good support employee may remember that a customer has been struggling with an unresolved migration all week.

They probably do not need to remember that the same customer asked where the export button was three years earlier.

We preserve stories while they matter, decisions that remain relevant and relationships that continue.

Other details fade.

Software memory can be more precise than human memory, which is useful.

Precision should not automatically become permanence.

The nicest support experience is remembered by the customer, not necessarily by the database.

The customer had a problem.

They explained it once.

The system understood enough context to help.

If a person needed to take over, the history followed the conversation.

The problem was resolved.

For an appropriate period, the business retained what it needed.

Eventually the information stopped serving that purpose and disappeared.

Nothing magical happened.

The support worked.

I think that is a much healthier ambition than building the largest possible memory and hoping usefulness eventually emerges from it.