Context Engineering as Your Competitive Edge

, I’ve kept returning to the same question: if cutting-edge foundation models are widely accessible, where could durable competitive advantage with AI actually come from?

Today, I would like to zoom in on context engineering — the discipline of dynamically filling the context window of an AI model with information that maximizes its chances of success. Context engineering allows you to encode and pass on your existing expertise and domain knowledge to an AI system, and I believe it is an important component for strategic differentiation. If you have both unique domain expertise and know how to make it usable to your AI systems, you’ll be hard to beat.

In this article, I will summarize the components of context engineering as well as the best practices that have established themselves over the past year. One of the most critical factors for success is a tight handshake between domain experts and engineers. Domain experts are needed to encode domain knowledge and workflows, while engineers are responsible for knowledge representation, orchestration, and dynamic context construction. In the following, I attempt to explain context engineering in a way that is helpful to both domain experts and engineers. Thus, we will not dive into technical topics like context compacting and compression.

For now, let’s assume our AI system has an abstract component — the context builder — which assembles the most efficient context for every user interaction. The context builder sits between the user request and the language model executing the request. You can think of it as an intelligent function that takes the current user query, retrieves the most relevant information from external resources, and assembles the optimal context for it. After the model produces an output, the context builder may also store new information, like user edits and feedback. In this way, the system accumulates continuity and experience over time.

Conceptually, the context builder must manage three distinct resources:

• Knowledge about the domain and specific tasks turns a generic AI system into a domain expert.
• Tools allow the agent act in the real world.
• Memory allows the agent to personalize its actions and learn from user feedback.

As the system matures, you will also find more and more interesting interdependencies between these three components, which can be addressed with proper orchestration.

Let’s dive in and examine these components one by one. We will illustrate them using the example of an AI system that supports RevOps tasks such as weekly forecasts.

Knowledge

As you begin designing your system, you speak with the Head of RevOps to understand how forecasting is currently done. She explains: “When I prepare a forecast, I don’t just look at the pipeline. I also need to understand how similar deals performed in the past, which segments are trending up or down, whether discounting is increasing, and where we historically overestimated conversion. Sometimes, that information is already top-of-mind, but often, I need to search through our systems and talk to salespeople. In any case, the CRM snapshot alone is only a baseline.”

LLMs come with extensive general knowledge from pre-training. They understand what a sales pipeline is and know common forecasting methods. However, they are not aware of your company’s specifics, such as:

• Historical close rates by stage and segment
• Average time-in-stage benchmarks
• Seasonality patterns from comparable quarters
• Pricing and discount policies
• Current revenue targets
• Definitions of pipeline stages and probability logic

Without this information, users will have to manually adjust the system’s outputs. They will explain that enterprise deals slip more often in Q4, correct expansion assumptions, and remind the model that discount approvals are currently delayed. Soon, they might conclude that the AI system is interesting in itself, but not viable for their day-to-day.

Let’s look at patterns that allow you to integrate an AI model with company-specific knowledge. We will start with RAG (Retrieval-Augmented Generation) as the baseline and progress towards more structured representations of knowledge.

RAG

In Retrieval-Augmented Generation (RAG), company- and domain-specific knowledge is broken into manageable chunks (refer to this article for an overview of chunking methods). Each chunk is converted into a text embedding and stored in a database. Text embeddings represent the meaning of a text as a numerical vector. Semantically similar texts are neighbours in the embedding space, so the system can retrieve “relevant” information through similarity search.

Now, when a forecasting request arrives, the system retrieves the most similar text chunks and includes them in the prompt:

Conceptually, this is elegant, and every freshly baked B2B AI team that respects itself has a RAG initiative underway. However, most prototypes and MVPs struggle with adoption. The naive version of RAG makes several oversimplifying assumptions about the nature of enterprise knowledge. It uses isolated text fragments as a source of truth. It assumes that documents are internally consistent. It also strips the complex empirical concept of relevance down to similarity, which is much handier from the computational standpoint.

In reality, text data in its raw form provides a confusing context to AI models. Documents get outdated, policies evolve, metrics are tweaked, and business logic may be documented differently across teams. If you want forecasting outputs that leadership can trust, you need a more intentional knowledge representation.

Articulating knowledge through graphs

Many teams dump their available data into an embedding database without knowing what’s inside. This is a sure recipe for failure. You need to know the semantics of your data. Your knowledge representation should reflect the core objects, processes, and KPIs of the business in a way that is interpretable both by humans and by machines. For humans, this ensures maintainability and governance. For AI systems, it ensures retrievability and correct usage. The model must not only access information, but also understand which source is appropriate for which task.

Graphs are a promising approach because they allow you to structure knowledge while preserving flexibility. Instead of treating knowledge as an archive of loosely connected documents, you model the core objects of your business and the relationships between them.

Depending on what you need to encode, here are some graph types to consider:

• Taxonomies or ontologies that define core business objects — deals, segments, accounts, reps — along with their properties and relationships
• Canonical knowledge graphs that capture more complex, non-hierarchical dependencies
• Context graphs that record past decision traces and allow retrieval of precedents

Graphs are powerful as a representation layer, and RAG variants such as GraphRAG provide a blueprint for their integration. However, graphs don’t grow on trees. They require an intentional design effort — you need to decide what the graph encodes, how it is maintained, and which parts are exposed to the model in a given reasoning cycle. Ideally, you can view this not as a one-off investment, but turn it into a continuous effort where human users collaborate with the AI system in parallel to their daily work. This will allow you to build its knowledge while engaging users and supporting adoption.

Tools

Forecasting is not analytical, but operational and interactive. Your Head of RevOps explains: “I’m constantly jumping between systems and conversations — checking the CRM, reconciling with finance, recalculating rollups, and following up with reps when something looks off. The whole process interactive.”

To support this workflow, the AI system needs to move beyond reading and generating text. It must be able to interact with the digital systems where the business actually runs. Tools provide this capability.

Tools make your system agentic — i.e., able to act in the real world. In the RevOps setting, tools might include:

• CRM pipeline retrieval (pull open opportunities with stage, amount, close date, owner, and forecast category)
• Forecast rollup calculation (apply company-specific probability and override logic to compute commit, best case, and total pipeline)
• Variance and risk analysis (compare current forecast to prior periods and identify slippage, concentration risk, or deal dependencies)
• Executive summary generation (translate structured outputs into a leadership-ready forecast narrative)
• Operational follow-up trigger (create tasks or notifications for high-risk or stale deals)

By hard-coding these actions into tools, you encapsulate business logic that should not be left to probabilistic guessing. For example, the model no longer needs to approximate how “commit” is calculated or how variance is decomposed — it just calls the function that already reflects your internal rules. This increases the confidence and certainty of your system.

How tools are called

The following figure shows the basic loop once you integrate tools in your system:

Let’s walk through the process:

1. A user sends a request to the LLM, for example: “Why did our enterprise forecast drop week over week?” The context builder injects relevant knowledge (recent pipeline snapshot, forecast definitions, prior totals) and a subset of available tools.
2. The LLM decides whether a tool is needed. If the question requires structured computation — such as variance decomposition — it selects the appropriate function.
3. The selected tool is executed externally. For example, the variance analysis function queries the CRM, calculates deltas (new deals, slipped deals, closed-won, amount changes), and returns structured output.
4. The tool output is added back into the context.
5. The LLM generates the final answer. Grounded in an established computation, it produces a structured explanation of the forecast change.

Thus, the task for creating the business logic is offloaded to the experts who write the tools. The AI agent orchestrates predefined logic and reasons over the results.

Selecting the right tools

Over time, your inventory of tools will grow. Beyond CRM retrieval and forecast rollups, you may introduce renewal risk scoring, expansion modelling, territory mapping, quota tracking, and more. Injecting all of these into every prompt increases complexity and reduces the likelihood that the correct tool is selected.

The context builder is responsible for managing this complexity. Instead of exposing the entire tool ecosystem, it selects a subset based on the task at hand. A request such as “What is our likely end-of-quarter revenue?” may require CRM retrieval and rollup logic, while “Why did enterprise forecast drop week over week?” may require variance decomposition and stage movement analysis.

Thus, tools become part of the dynamic context. To make this work reliably, each tool needs clear, AI-friendly documentation:

• What it does
• When it should be used
• What its inputs represent
• How its outputs should be interpreted

This documentation forms the contract between the model and your operational logic.

Standardizing the interface between LLMs and tools

When you connect an AI model to predefined tools, you are bringing together two very different worlds: a probabilistic language model and deterministic business logic. One operates on likelihoods and patterns; the other executes precise, rule-based operations. If the interface between them is not clearly specified, the interaction becomes fragile.

Standards such as the Model Context Protocol (MCP) aim to formalize the interface. MCP provides a structured way to describe and invoke external capabilities, making tool integration more consistent across systems. WebMCP extends this idea by proposing ways for web applications to become callable tools within AI-driven workflows.

These standards matter not only for interoperability, but also for governance. They define which parts of your operational logic the model is allowed to execute and under which conditions.

Memory — the key to personalized, self-improving AI

Your Head of RevOps takes an individual approach to every forecasting cycle: “Before I finalize a forecast, I make sure I understand how leadership wants the numbers presented. I also keep track of the adjustments we’ve already discussed this week so we don’t revisit the same assumptions or repeat the same mistakes.”

So far, our prompts were stateless. However, many generative AI applications need state and memory. There are many different approaches to formalize agent memory. In the end, how you build up and reuse memories is a very individual design decision.

First, decide what type of knowledge from user interactions can be useful:

As shown in this table, the type of knowledge also informs your choice of a storage format. To further specify it, consider the following two questions:

• Persistence: For how long should the knowledge be stored? Think of the current session as the short-term memory, and of information that persists from one session to another as the long-term memory.
• Scope: Who should have access to the memory? In most cases, we think of memories at the user level. However, especially in B2B settings, it can make sense to store certain interactions, inputs, and sequences in the system’s knowledge base, allowing other users to benefit from it as well.

As your memory store grows, you can increasingly align outputs with how the team actually operates. If you also store procedural memories about execution and outputs (including those that required adjustments), your context builder can gradually improve how it uses memory over time.

Interactions between the three context components

To reduce complexity, so far, we made a clear split between the three components of an efficient context — knowledge, tools, and memory. In practice, they will interact with each other, especially as your system matures:

• Tools can be defined to retrieve knowledge from different sources and write different types of memories.
• Long-term memories can be written back to knowledge sources and be made persistent for future retrieval.
• If a user frequently repeats a certain task or workflow, the agent can help them package it as a tool.

The task of designing and managing these interactions is called orchestration. Agent frameworks like LangChain and DSPy support this task, but they don’t replace architectural thinking. For more complex agent systems, you might decide to go for your own implementation. Finally, as already said at the beginning, interaction with humans — especially domain experts — is crucial for making the agent smarter. This requires educated, engaged users, proper evaluation, and a UX that encourages feedback.

Summing up

If you’re starting a RevOps forecasting agent tomorrow, begin by mapping:

1. What information sources exist and are used for this task (knowledge)
2. Which operations and computations are repetitive and authoritative (tools)
3. Which workflows decisions require continuity (memory)

In the end, context engineering determines whether your AI system reflects how your business actually works or merely produces guesses that “sound good” to non-experts. The model is interchangeable, but your unique context is not. If you learn to represent and orchestrate it deliberately, you can turn generic AI capabilities into a durable competitive edge.