A customer phones their bank because a debit order bounced. The agent answers, and before the customer has finished explaining, a summary appears on the agent's screen: the failed debit, the insufficient balance at the time, the salary that landed two hours later, and a suggested script for re-presenting the debit. The call takes four minutes instead of twelve. The customer leaves thinking the bank understood them.
Now change one detail. The summary also mentions that the customer has recently started paying a new payee that looks like a private school, and suggests offering an education loan. The data is the bank's own, the inference is plausible, and the offer might even be useful. Most customers would still find it unsettling.
The difference between those two experiences is not the model. It is the boundary around what context the AI is allowed to assemble, for what purpose, and for how long. This part of the series looks at that boundary, using the idea of temporary customer context.
Strelitzia Bank is fictional, a composite drawn from patterns that recur across the industry, and its systems and figures are illustrative. This article is general information, not legal advice.
What temporary context means
Temporary context is information assembled for a single interaction, used to help in that interaction, and discarded when it ends. In Strelitzia's service assistant, a conversation starts with a lookup of a small, defined set of recent events: failed transactions, open cases, recent card declines and any active fraud flags. The assistant uses that set to explain what happened and propose the next step. When the conversation closes, the assembled context is deleted. What remains is the ordinary service record the bank already keeps: the case notes, the outcome and the transcript retained under the bank's normal policy.
The alternative is a retained profile. Every interaction adds signals to a growing store about the customer: interests inferred from spending, life events guessed from payees, sentiment from previous calls. The profile is reused across conversations and, over time, across purposes nobody had in mind when the data was collected.
Retained profiles are not automatically wrong. Some are expected and useful, such as a preferred language or a record that the customer is hard of hearing. The problem is that a profile grows by default, and each new use of it needs its own justification that is rarely written down.
Why the boundary is a design decision
It is tempting to treat this as a legal question and hand it to the privacy office. The legal analysis matters, and in South Africa the Protection of Personal Information Act frames it: personal information should be processed for a specific, explicitly defined purpose, and further processing should be compatible with that purpose. We have written about how POPIA applies to AI in What POPIA means for your data and AI strategy and in the AI and POPIA, in Plain Language series.
But the boundary is also an architecture decision, and it is cheaper to get right in design than in remediation. Three choices decide whether a service assistant stays helpful:
What the context builder may read. Strelitzia's context builder calls four owned interfaces with a fixed query shape: recent failed transactions, open cases, recent declines and fraud flags, each limited to the last thirty days. It cannot browse the full transaction history. That limitation is enforced in the interface, not in the prompt.
Where the context lives. The assembled context is held in the conversation session, not written to a customer profile store. When the session closes, it goes. There is no background job that mines old sessions for signals.
What the assistant may suggest. Suggestions are limited to resolving the reason for the contact. Product offers are out of scope for the service assistant entirely. If the bank wants to make offers, that is a separate feature with its own purpose, consent and review.
These are not exotic controls. They are the same discipline we describe in Separate public knowledge from private account data, applied to the question of time as well as access.
A simple test for any personalisation idea
When a product team proposes a new use of customer context, two questions sort most ideas quickly.
The first: would the customer expect this? A customer who calls about a failed debit expects the agent to know about the failed debit. They do not expect the agent to know what their spending suggests about their family.
The second: is it used in this conversation, or kept and reused later? Using context in the moment to resolve the reason for contact is the lowest-risk pattern. Keeping it and reusing it later needs a clearer purpose and, often, explicit consent.
The upper-left cell, expected and temporary, is where Strelitzia started, and where most organisations should start. It delivers most of the measurable value: shorter calls, fewer transfers, fewer repeat contacts. The lower-right cell, surprising and retained, is where trust is lost even when every individual step could be defended on paper.
What "delightful" actually depends on
Conference presentations sometimes describe service AI as delightful. When customers do find it delightful, the reason is usually narrow: the assistant knew the one thing that mattered to the current problem and did not make them repeat it. That experience depends on three operational qualities more than on model capability.
Freshness. The context must reflect what happened minutes ago, not last night. This is why the reliability and event work described in Part 1 comes first.
Precision. A short, accurate summary of the relevant events beats a long one that includes everything. More context increases the chance of the model mentioning something the customer did not raise.
Restraint. The assistant says less than it could. The agent, not the AI, decides what to say to the customer, and the summary is written for the agent's eyes.
The failure modes to design out
Even a well-bounded design can drift. These are the patterns Strelitzia's review board watches for:
- Scope creep in the context builder. A new query is added "temporarily" for a campaign and never removed. Every change to the builder's query set should pass the same review as the original design.
- Session data leaking into analytics. Conversation logs are copied into a data lake for quality analysis, and the temporary context comes with them. Logging should capture what is needed to evaluate quality, with the assembled context either excluded or masked.
- Prompt instructions as the only control. "Do not mention unrelated payees" in a system prompt is a request, not a control. The reliable control is not giving the model that data in the first place.
- The agent screen as a broadcast. If the summary is visible on a screen the customer can see, or read aloud by a voice channel, the audience changes. Design the summary for the channel it actually appears in.
Where to start
For an organisation planning its first service assistant, the practical sequence is short. Define the contact reasons the assistant will help with. For each one, list the minimum events needed to resolve it. Build a context builder that can fetch only those, for a bounded window, through owned interfaces. Keep the context in the session and delete it at close. Leave offers, profiling and cross-purpose reuse out of the first release entirely, and decide on them later as separate features with their own purpose and review.
That design is less ambitious than a full customer-intelligence platform. It is also far more likely to be trusted, approved and used.
The point of view
Helpful service AI is mostly a matter of restraint. The value comes from knowing the one relevant thing at the right moment, and the risk comes from knowing more than the customer expects or keeping it longer than the conversation needs. Temporary context, enforced in the architecture rather than the prompt, is the pattern that delivers the first without drifting into the second.
Next: Part 3, What public-sector procurement reform teaches technology programmes. All parts are on the series page.
How CloudNala can help
We help service and digital teams design customer-facing AI with clear context boundaries: which contact reasons it serves, which events it may read, how long context lives, what is logged and what is excluded. The output is an architecture and a short decision record that product, privacy and engineering teams can all sign, so the assistant ships with its boundaries already built in.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za