From Prompt Engineering to Context Engineering
1. Why “better prompts” are not enough
Over the last two years, many organisations have invested in “prompt engineering” workshops. Staff learn to instruct ChatGPT or other models more clearly, they discover templates for emails, reports, or summaries, and productivity improves at the margins.
Yet several patterns are now visible.
- AI pilots look promising, but very few reach stable, organisation wide adoption.
- Different teams use different prompts, so outputs are inconsistent.
- Critical tasks, such as policy drafting, market analysis, or monitoring and evaluation, still fall back to manual work because the AI “does not really understand our context”.
The core issue is not that staff are failing to prompt correctly. It is that the model is operating in a thin information environment. The AI is being asked complex, organisation specific questions while seeing little of the underlying policies, data, and constraints that human experts rely on every day.
This is the gap that context engineering is designed to close.
2. Prompt engineering. How you ask the question
In line with OpenAI’s own guidance, prompt engineering can be understood as the deliberate design of inputs that guide a model’s responses. A good prompt will:
- State the role, task, audience, and format clearly.
- Place instructions at the beginning and keep them distinct from the data to be analysed.
- Use examples or checklists to show the model what a good answer looks like.
For example.
“You are a trade promotion advisor. Summarise this market report in 5 bullet points for a busy trade officer in Nairobi, highlight risks and opportunities for Kenyan exporters, and close with one recommended next step.”
Prompt engineering is therefore essential. It is the skill every professional should have, regardless of sector. However, it remains focused on how we ask.
Prompt engineering alone cannot give the model access to:
- Internal policies, templates, or standard operating procedures.
- Historical reports and datasets.
- Organisation specific terminology and risk thresholds.
- Current regulatory constraints or strategic priorities.
If those elements are not surfaced and structured, even the best prompt will produce confident but shallow answers.
3. Context engineering. Designing the information environment your AI works in
Context engineering extends this conversation. Drawing on recent thinking in InfoWorld and University of London’s work on “from prompt engineering to context engineering”, we can define it for African organisations as follows.
Context engineering is the practice of designing, integrating, and governing the information environment in which AI systems operate, so that they can act on the same contextual signals that human experts use.
In practical terms, context engineering curates and organises:
- System instructions and guardrails. How the organisation expects the AI to behave, including ethical rules and data protection constraints.
- Reference documents. Policies, strategy documents, reports, guidelines, and FAQs.
- Structured data. Tables, registers, and key indicators that are regularly used in decisions.
- Tools and connectors. The systems that AI is allowed to query, such as SharePoint, CRMs, or research tools.
- Conversation history and workflows. How outputs are reviewed, corrected, and fed back into future use.
Where prompt engineering is about the sentence at the top of the chat window, context engineering is about everything the model can see behind that sentence.
4. What recent thought leaders are saying
If we bring together the most relevant insights from InfoWorld, University of London, and OpenAI’s official guidance, a clear pattern emerges.
4.1 InfoWorld. The strategic case for context engineering
The InfoWorld article “Why context engineering will define the next era of enterprise AI” argues that as foundation models become more accessible, the real differentiator will be the context layer that sits around those models. In that view:
- Prompt engineering was a necessary first step, but it is shallow if used alone.
- Enterprise value comes from integrating AI with proprietary data, governed workflows, and clear decision boundaries.
- Context engineering is an evolution of data engineering, focused on making organisational knowledge “AI ready”.
For African organisations, this resonates strongly. Many already sit on large volumes of underused reports, policies, and datasets. The gap is not the absence of information, it is the absence of a context layer that allows AI tools to use that information effectively.
4.2 University of London. A non technical case study
The University of London’s case “Making AI work for you: From prompt engineering to context engineering” shows how a Student Life team moves from playing with prompts to building an end to end workflow for analysing student feedback. Three points from this narrative are particularly useful for Kenyan and regional contexts.
- The team is not highly technical, they use a combination of ChatGPT, Gemini, and simple scripts.
- The breakthrough comes when they treat AI as part of a wider pipeline, including data collection, cleaning, pattern detection, and presentation.
- The authors explicitly describe context engineering as designing this whole information environment, not only the wording of prompts.
This is exactly the kind of shift that many African organisations need. From “we have a chatbot” to “we have a repeatable workflow where AI, staff, and data work together”.
4.3 OpenAI. Best practices that support context thinking
OpenAI’s prompt engineering guides do not use the term context engineering, but they embed context thinking in their rules.
- Separate instructions from context and mark the boundaries clearly.
- Provide enough relevant background, including audience, purpose, and any constraints.
- Keep prompts structured and organised, especially for complex tasks.
This reinforces a simple but powerful habit. Whenever staff design a prompt, they should be trained to ask.
- What is the instruction.
- What context does the model need to see.
- In what format should the output appear.
Context engineering then takes this a step further. Instead of pasting context manually each time, the organisation deliberately structures and automates how that context is delivered.
5. Should organisations prioritise context engineering now
Because training budgets and technical capacity are limited, many leaders are asking where to invest first. A useful way to consider this trade off is shown below.
Trade offs. Focusing on context engineering in African organisations
| Perspective | Type | Observation |
| Building context engineering capability early creates more durable value than isolated prompt workshops. | Pro | Once core policies, templates, and data sources are structured for AI, multiple teams can reuse them. Prompt skills then scale on top of this layer. |
| Emphasising context engineering improves trust and reduces hallucinations in sensitive domains such as health, trade, and regulation. | Pro | When AI is grounded in curated, organisation approved sources, staff can trace outputs back to evidence more easily. |
| Context engineering requires more cross functional coordination than simple prompt training. | Con | IT, knowledge management, legal, and business units need to work together, which can slow initial progress. |
| In highly paper based or fragmented environments, context engineering may expose digitalisation gaps that are politically sensitive. | Con | Some units may resist efforts to centralise or standardise documentation and data, especially where informality is entrenched. |
For most mid to large organisations in Kenya, a balanced approach is advisable. Start with practical prompt training, but design it in such a way that it naturally leads into context engineering conversations and pilots.
6. A practical roadmap. Moving from prompts to pipelines
To turn these ideas into an actionable path, organisations can follow four stages.
Stage 1. Map high value decisions and knowledge sources
Identify 3 to 5 recurring, knowledge intensive tasks, for example:
- Drafting funding proposals.
- Preparing briefings for trade missions.
- Reviewing programme reports.
For each task, list the policies, templates, datasets, and informal knowledge currently used. This map becomes the raw material for context engineering.
Stage 2. Standardise strong prompts around real workflows
Using OpenAI style best practices, create shared prompt templates for these tasks. For example:
- A proposal design prompt that always asks for alignment with specific strategic pillars.
- A reporting prompt that forces explicit identification of risks, assumptions, and next steps.
At this stage, focus on clarity and consistency across teams.
Stage 3. Build lightweight context packs
Instead of pasting content ad hoc, curate small, focused collections of documents and data that support each workflow. These can be as simple as:
- A folder with the current strategy, policy documents, and standard templates.
- A basic spreadsheet with key indicators or classifications.
In more advanced settings, these context packs can become:
- SharePoint libraries connected to Copilot.
- Knowledge bases indexed for retrieval augmented generation.
The aim is to ensure that when staff use a standard prompt, the AI is also seeing a standard, up to date context pack.
Stage 4. Introduce governance and feedback
Finally, treat AI and context engineering as part of organisational governance, not just as a technical experiment.
- Define who owns which context packs and how often they must be updated.
- Establish simple review mechanisms so that AI outputs in critical tasks are checked and improved.
- Use feedback to refine both prompts and context over time.
This staged approach respects resource constraints while still moving towards a genuine context first AI adoption model.
7. How Palme supports context first AI adoption
Palme Research and Training Consultants positions itself deliberately in this emerging space.
- Training that moves beyond tricks. We do not stop at “ten clever prompts”. We train staff to distinguish between instructions and context, to structure their knowledge, and to think in terms of workflows and pipelines.
- Context engineering labs. We facilitate practical sessions where teams bring real documents, policies, and data. Together we design context packs, prompt templates, and review loops that fit their environment.
- African organisational realities. Our designs assume intermittent connectivity, legacy systems, and diverse stakeholder requirements. We focus on what is feasible in Kenyan ministries, agencies, NGOs, and businesses, not only in highly digitised global firms.
- Governance and ethics. We integrate data protection, confidentiality, and fairness considerations into every context engineering exercise, so AI adoption remains safe and compliant.
For organisations in Kenya and across Africa, the question is no longer “should we teach our staff prompt engineering”. That is a baseline. The more strategic question is.
Who will help us design the context in which our AI systems operate, so that they truly reflect our mission, knowledge, and constraints.
Context engineering is the missing bridge between powerful models and meaningful, trustworthy AI at work. Palme’s role is to help build that bridge, one workflow and one organisation at a time.