Stop renting your chatbot’s memory: keep your business context

Stop renting your chatbot’s memory: keep your business context

You switch chatbots and find yourself giving the same tour again: your business, your customers, the exceptions you agreed and the language your team avoids. By explaining everything inside a conversation, you have furnished a rented office whose keys belong to somebody else. Renting a good tool is not the problem. Leaving your working knowledge in its cupboards is.

To stop renting your business context, separate what your company knows from the model using it. Your references, current records and working methods need to remain usable elsewhere. Claude, ChatGPT or a local model can then become engines you evaluate, rather than the only place your team can recover its accumulated knowledge.

Switch chatbots without giving the whole tour again

The moving-office metaphor has an important limit: your furniture is not necessarily locked inside. Services can offer conversation exports; Claude documents this option in its settings. But recovering an archive is not the same as recovering an assistant ready for work. Someone still needs to distinguish an approved decision from an abandoned suggestion, restore permissions and check connections.

A commercial rule buried in an old conversation is not yet a business reference. It becomes one when it has a clear statement, an owner, a validity date and a connection to the relevant files. That work makes your context reusable, even if you continue using hosted services.

The useful test is therefore not “can I download my messages?” but “can I give the same case to another engine without asking the team to explain everything again?” A migration will still need adaptation: tool formats, instructions, context limits and answer quality vary. The aim is to retain the underlying work, not promise an effortless switch.

Three pillars that keep your context useful beyond one model

An AI-ready case needs three different things: authoritative references, current information and a method for doing the work. Mixing them into one long conversation makes updates difficult to check. Separating them lets you correct a source without rebuilding the entire system.

1. Static context: your references, not a document attic

This first pillar brings together approved procedures, your offer, preferred terminology and decisions that need to last. “Static” does not mean unchanging. These references evolve, but they do not change with every sale or support ticket.

A few maintained notes are more useful than an unfiltered archive. Connect each rule to the right concepts: customer, contract, product, procedure and decision. This organisation of categories and relationships is an ontology. It helps distinguish a standard price from an exception agreed with a particular customer.

Your Company Brain, or business memory, provides a way to retrieve those references, their origins and their validity. The aim is not to make the model memorise the entire business. The system supplies the relevant, authorised passages for the request.

2. Dynamic context: what is true today

A refund policy cannot tell you whether this customer has already received a refund. For that, the assistant needs the current case records: the order, invoice, support conversation or CRM entry. This is the second pillar: information that changes.

You do not need to abandon your sales or support software to build it. Identify the authoritative source, then arrange authorised API access or a controlled synchronisation. A copy refreshed overnight does not describe sales from the past hour. Its update time needs to travel with the information.

The query must also respect the requesting person’s permissions. A support assistant should not see profit margins or every customer account simply because a shared database exists. Those restrictions belong in the tools and data access controls, not just in instructions written to the model.

3. Capabilities: procedures the assistant can carry out

The first two pillars let AI understand a case. Capabilities let it move the work forward: find missing records, calculate an amount with a tool, draft a reply or create a task. A skill describes a reusable method; an agent organises the steps; an automation triggers or passes on the work under defined rules.

Each capability needs explicit inputs, permitted actions and a stopping point. “Prepare a credit note” and “issue a credit note” confer different powers. Issuing one requires specific permission and, depending on your organisation, human approval before anything is written to the accounting system.

A customer case brings the three pillars together

Imagine a customer requesting a refund. Static context supplies the applicable terms. Dynamic context supplies the purchase date, payment and previous exchanges. The capability assembles the evidence, flags a missing item and drafts a response with its supporting references. The responsible person checks the amount and authorises the next step.

If you replace the model, the sales terms, connections and preparation procedure should not disappear with it. Test the new engine on that case: does it find the right sources, recognise the exception and stop at the same boundary? You are checking continuity of work, not holding a competition for the most polished answer.

Our guide to the seven layers of a company’s own AI explains the technical components around the engine. The decision here comes earlier: which parts of your context must survive a change of tool, and for what task? The three pillars let you make that inventory before compiling a software shopping list.

Prompts still matter; they cannot carry the whole business

A good prompt specifies the work, the required format and the questions to ask before reaching a conclusion. OpenAI and Anthropic still document how to write and test those instructions. But no sophisticated prompt can turn an old price into today’s price or provide reliable access to your CRM.

Work on instructions alongside sources and capabilities. When an answer is wrong, find where the chain failed: an outdated reference, stale data, an ambiguous instruction or a misused tool. Buying another subscription before diagnosing the problem may simply move it elsewhere.

Owning the system also means maintaining it

Keeping control of your context does not require hosting everything yourself. You can retain exportable references and documented access arrangements while choosing a hosted model. Conversely, a server in your office does not automatically protect data. Accounts, updates, backups, logging and recovery still need owners and procedures.

Open-source code can make inspection and a change of provider easier. It does not remove licence conditions or the cost of computing, integration and maintenance. Your choice needs to reflect the sensitivity of your cases, available skills and who will intervene when a connector stops working.

Before expanding, assign responsibility for approving references, checking data freshness and maintaining capabilities. Keep a small set of test cases to detect regressions after a model or procedure changes. Track completed tasks, requested corrections and review time: those observations should determine what happens next.

Turn accumulated context into a useful AI Worker with SAY

Your first project can begin with one question: which case does your team still have to explain again every week? Starting there, SAY can help organise the references, connect relevant data and define an AI Worker’s permitted actions. Scoping establishes sources, access rights, approval steps and acceptance tests before its remit expands.

You are no longer just looking for a more convincing chatbot. You are building a system whose knowledge your team can maintain and whose work it can check, with the option of choosing another engine when that makes sense.

Which business context should stay with you, whatever tool you choose next? Talk to SAY about scoping your first AI Worker around a real case. SAY Go Big Online.

Sources and further reading

• Anthropic — export your Claude data: export availability, distinct from a complete operational migration.
• OpenAI — prompt engineering and Anthropic — prompt engineering: instructions, context and evaluation.
• Ollama — FAQ: local operation, network configuration and cloud services as separate considerations.