Imagine a product team trying to improve customer onboarding.
They give an AI tool one customer complaint and ask: “What should we build next?”
The answer sounds reasonable. Shorten the form. Add clearer instructions. Reduce the number of steps. Send reminders to customers who abandon the process.
None of these suggestions is absurd. None is strong enough to guide a product decision either.
The AI does not know which customers are struggling, where they leave the journey, what the team is trying to improve, which identity checks are mandatory, what has already been tested or what the engineers can change this quarter. It fills the gaps with patterns learned elsewhere.
The problem is bigger than the prompt
This is the problem context engineering addresses.
Prompt engineering improves the instruction. Context engineering prepares the working environment around that instruction. It decides what the system should know, which sources it may access, what has already happened, which limits apply and what a useful result should contain.
That distinction matters more as AI moves from answering questions to completing work. A weak answer is inconvenient. A weak action can update the wrong record, send the wrong message or recommend a decision based on information that stopped being true three months ago.
What this article covers
What context engineering means in practice
Why more information can make an AI system worse
A simple method product teams can use
How mobile money, local language, privacy and fragmented records change the work in Kenya and other specific African markets
Why a good prompt can still produce weak work
Current AI systems can follow detailed instructions and still produce weak work because the necessary evidence is missing.
Anthropic describes context engineering as the work of curating and maintaining the information available to a model during inference. That includes the prompt, but also system instructions, tools, external data, conversation history and the current state of the task. Its practical advice is blunt: aim for the smallest set of high-signal information that can support the required result. (Anthropic, 2025)
The word smallest matters. Teams often respond to a weak AI answer by uploading more documents. The context window becomes a dumping ground for old policies, duplicate reports, half-finished plans and meeting notes that disagree with one another.
Research on long-context models has found that they do not use every part of a large input equally well. Relevant information can become harder to retrieve when it sits in the middle of a long context. OpenAI reported a similar operational lesson while building with coding agents: one giant instruction manual crowded out the task and became stale, so the team replaced it with a shorter map that directs the agent to detailed sources when needed. (Liu et al., 2023; OpenAI, 2026)
Four ways context fails
Missing information: The model must guess or leave gaps.
Outdated information: The model solves an earlier version of the problem.
Conflicting information: The model chooses between sources without knowing which one has authority.
Irrelevant information: The useful evidence becomes harder to find.
The output may still be polished. That is what makes the failure dangerous.
Example: improving customer onboarding
Return to the product team working on onboarding.
Instead of sending one complaint, the team gives the AI a focused context pack:
Customer feedback from the last 90 days, grouped by customer type
Funnel data showing where customers abandon the process
The product goal: improve successful account activation, not registrations
Current KYC and data-protection requirements
Known failures in identity verification and OTP delivery
Features already committed to the roadmap
Device, channel and connectivity information
The criteria the team uses to compare product options
The instruction has barely changed. The quality of the question has.
The AI can now connect complaints to an observed drop-off point, rule out work that is already planned and explain which recommendation fits the team’s limits. It may find that customers are not leaving because the form is long. They may be abandoning the journey after an OTP expires, when an identity check fails without explanation or when the process asks them to switch channels.
That answer is still a hypothesis. The team must check the underlying data, speak to customers and test the change. Context engineering makes the recommendation more grounded; it does not make the model infallible.
How to build a useful context pack
A useful context pack answers seven questions.
1. Define the task
Name the decision or output. “Analyse feedback” is vague. “Identify the two most common causes of failed activation among first-time mobile customers and recommend what the team should investigate next” gives the work a boundary.
2. Select current evidence
Select the customer, usage and operational evidence needed for this decision. Include the period, customer segment and market. A complaint from 2024 may not explain a journey changed in July 2026.
3. Record what has already happened
Give the system the current roadmap, previous decisions, experiments and known failures. Otherwise, it may recommend work the team rejected or completed months ago.
4. Name the constraints
Include technical dependencies, regulation, commercial limits, channel conditions and delivery capacity. A recommendation that ignores KYC requirements or a core-system dependency is not useful because it sounds clean.
5. Set the AI’s boundaries
Separate analysis from action. The system may summarise evidence and propose options. Updating customer data, contacting users or changing a financial account may require explicit human approval.
6. Define the expected output
Specify the evidence the AI must cite, the uncertainties it must flag and the decision criteria it must use. “Give me a good answer” is not a test.
7. Establish which source has authority
Name the source of truth and its owner. Retrieval can find two documents. It cannot reliably decide that the policy approved last week overrides the slide deck from January unless the system receives that rule.
This context pack can be one page. The AI can then retrieve the supporting material when the task calls for it. A map is more useful than copying the entire company drive into one chat.
What context engineering means under African operating conditions
There is no single African context. A bank in Kenya, a logistics company in Nigeria and a public service in Rwanda operate with different customers, systems and rules. Context engineering becomes useful when teams name those conditions instead of adding “consider Africa” to the end of a prompt.
1. Mobile money belongs inside the product journey
Kenya’s 2024 FinAccess survey found that 82.3% of adults used mobile money, and daily usage rose from 23.6% in 2021 to 52.6% in 2024. (Central Bank of Kenya, 2024)
An AI reviewing a Kenyan financial product may therefore need more than app analytics. It may need the mobile-money transaction status, source of funds, callback result, reversal history, agent-assisted step and the point where the customer moved between channels. If the context contains only web and app screens, the system may analyse a journey the customer never experienced.
2. Customer language is part of the evidence
Feedback rarely arrives in the clean language used in a product specification. Customers mix languages, shorten words and explain financial problems in local terms.
A 2025 ACL study created human-validated code-switched data for Afrikaans, Sesotho, Yoruba and isiZulu. Models improved when trained on the smaller, higher-quality dataset, including on a Yoruba personal-finance test set. The study did not test Kiswahili or Sheng, so it cannot prove the same result for Kenyan customer support. It does show why teams should test AI systems using the language customers use, with examples checked by people who understand the market. (Olaleye et al., 2025)
An English summary can erase the difference between “I do not understand this step,” “I do not trust this step” and “this step failed.” Those are different product problems.
3. Organisational knowledge may be scattered
The evidence needed for one decision can sit in several places: a complaint in a messaging thread, funnel data in a dashboard, an earlier decision in meeting notes and a technical limit known by one engineer.
This is a scenario teams should test inside their own organisations, not a measured claim about every African company. Where it is true, buying a stronger model will not fix it. The work starts with deciding which information matters, where it lives, who owns it and how the AI can access it without exposing everything else.
4. More context can create a privacy problem
“Give the AI more customer data” is poor guidance.
Kenya’s Data Protection Act gives people the right not to be subject to decisions based solely on automated processing when those decisions produce legal or similarly significant effects, subject to defined exceptions and safeguards. (Kenya Law)
Product teams need data minimisation, access controls, retention rules and a lawful reason for processing personal data. The context pack should contain what the task requires and what the system is authorised to use. Better performance does not cancel customer rights.
Agents raise the cost of getting context wrong
An assistant with weak context can write a poor summary. An agent may take that summary into the next step of a workflow.
An agent may:
Classify a complaint
Update a CRM record
Send a customer message
Prepare a recommendation for approval
Each action creates new information that becomes context for the next action. A mistake can travel through the workflow unless the system keeps the task state, permissions and human approval points clear.
This is why context engineering includes boundaries and memory, not only documents. The agent must know what happened, what it may do next and when to stop.
The practical starting point is a repeated, low-risk task where the team can compare results. Choose one task such as analysing onboarding feedback, investigating failed payments or preparing a weekly product report. Build a one-page context pack, run the task and review where the AI still guessed, ignored evidence or used an outdated source.
Then fix the context before reaching for a longer prompt.
Further reading, sources and inspiration
Understanding context engineering
Effective context engineering for AI agents — Anthropic: A practical explanation of how instructions, tools, external data, message history and task state form an agent’s context. It also explains why teams should aim for the smallest useful set of high-signal information.
Harness engineering: leveraging Codex in an agent-first world — OpenAI: An operational example of replacing one large, quickly outdated instruction manual with a shorter map that helps agents find the right source when needed.
Lost in the Middle — Liu et al.: Research showing that long-context models do not use all parts of a large input equally well, especially when important evidence sits in the middle.
African product and market context
2024 FinAccess Household Survey — Central Bank of Kenya: The source for the mobile-money usage figures and a useful reference for understanding how Kenyans use different financial channels.
AfroCS-xs — Olaleye et al.: Research on human-validated code-switched data for Afrikaans, Sesotho, Yoruba and isiZulu, including a Yoruba personal-finance test set.
Kenya Data Protection Act: The legal basis for the article’s discussion of automated decisions, customer rights and limits on how personal data may be processed.
This article was also shaped by the practical examples developed during Product Pulse Africa’s three-part Context Engineering series: defining context, examining why weak context damages AI output and showing how teams can assemble a focused context pack.