What is context management?

By business reality, we mean how work is actually organised. This includes formally described procedures as well as experience, working handoffs and justified exceptions. An organisation chart may show a formal responsibility, while the people doing the work know who can help with an unusual case. Both can be relevant, but each needs to be recorded with its own meaning.

Context management makes this knowledge explicit and connects it. A knowledge page is associated with the activity that needs it. A role is linked to its responsibility within a process. A system’s entry explains what it is used for in that procedure. Together, these descriptions form a representation of the business that remains useful beyond individual documents and individual people’s memories.

This representation is always a selected part of the business. A question about sales planning needs different relationships from a task involving machine maintenance. Capturing context therefore starts with a business purpose. That purpose determines which information and relationships need a detailed description and where an overview is sufficient. Recording every detail would be neither a sensible starting point nor something a team could maintain indefinitely.

Here, we use context management to mean this ongoing business and technical work of maintaining business context. It builds on process management, knowledge management and other existing information. The emphasis is on making their statements usable together and preserving that meaning when people and AI use them.

Consider a fictional sales department whose employees record opportunities in Salesforce. One process description explains qualification; another describes the monthly forecast. The statement “We use Salesforce in sales” does not yet explain how these activities connect. That requires establishing which information is created at each stage and who uses it afterwards.

In this example, the expected close date is recorded during qualification. The monthly forecast uses it to assign opportunities to a month, including opportunities that have not yet received a first quote. This use can be drawn from the two descriptions and checked with the people involved. The resulting record explains both that the processes use the same system and which information connects them.

Documentation and practice may disagree. Suppose an old description calls for recording the date later, while the forecasting team already needs it earlier. Capturing context should preserve that discrepancy. The people responsible can then establish whether the description is outdated, an exception is being practised or the procedure needs to change. Recording an observed habit does not itself make it an authoritative rule.

The outcome of curation is a supported statement with an identifiable status: where the date is recorded, what it is used for and which checked sources support that interpretation. An unresolved conflict belongs in the representation too. This lets subsequent users distinguish an established relationship from an assumption that still needs to be checked.

At NEXTHORIZN, we consider strategy, processes, organisation, systems and knowledge together. In the sales example, the process describes the work on an opportunity. Salesforce is the system involved. The organisation adds the responsible roles, while knowledge pages explain the business rules. Strategy can clarify the purpose of planning, including which decisions the monthly forecast is intended to support.

A relationship needs a recognisable meaning. “Has something to do with Salesforce” is too vague for further use. “The process uses Salesforce to maintain opportunities” describes a specific use. Similarly, “performs the activity” and “is responsible for the business rule” are different relationships. Naming them explicitly allows people to check them and technical applications to examine them selectively.

The level of detail also follows the task. An overview may initially show which processes use Salesforce. Assessing a change to data entry requires the relevant activities and their information needs. The business model can become more detailed gradually without representing every technical step. What matters is whether the question under consideration can be followed through the relationships captured.

I use the image of a business map for this connected representation. It records how goals, work, responsibility and information relate to each other. It already helps people find their way or coordinate a change. The same maintained relationships can then provide a foundation for AI applications.

Information can be taken from documents, gathered in conversations or obtained from existing systems. Business review connects these starting points to the actual work. In the sales example, this should involve both the people maintaining the date and those using it to produce the forecast. Both perspectives are needed to understand the relationship.

The people involved need an understandable interface for this work. They must be able to read a statement in its process context, open its supporting source and correct an unclear relationship. A usable entry identifies a responsible role, the origin of the information and its business status. This makes it possible to tell whether something is still a draft or an agreed basis for work.

Maintenance continues after the initial capture. If forecasting changes, the recorded uses of data need to be reviewed as well. A new document version alone does not establish whether the relationship to entering the close date still holds. Business ownership therefore covers both the source and its use. Previous versions should remain traceable so that older statements and decisions can be understood.

AI can assist this work, for example by suggesting relationships from text or comparing different statements. Those suggestions need to remain identifiable as suggestions until reviewed. The human interface is therefore where the business confirms and develops its representation. Questions from subsequent use can, in turn, reveal which parts of the shared foundation need more detail.

Digital text can already be read by a machine. For reusable business context, an additional concern is whether the things described and their relationships can be identified consistently. If one document says “CRM” and another says “Salesforce”, it should be possible to establish whether both refer to the same application. Unique identifiers help preserve these references even when names change.

The representation therefore combines readable explanations with structured information. An application might have an identifier and a description. A relationship records which process uses it and for what purpose. Source, business scope and version add the information needed to interpret the statement. The following example illustrates this principle with invented identifiers; it does not describe a particular data format or an existing PULSE interface.

Using these relationships, an application can retrieve the documented uses of a system alongside their explanations. AI receives the content together with information about its meaning and origin. A list of identifiers alone would be as inadequate for a business answer as a text excerpt with no indication of the process to which it applies.

Machine readability does not establish that a statement is correct. A well-structured but outdated relationship would still pass on the same error. Curation and technical representation therefore belong together. Preparation also needs to preserve uncertainty, limited applicability or a pending review wherever these matter to the intended use.

Different applications need access to the maintained content and relationships if they are to use this context. A targeted retrieval for the Salesforce question could return the process relationships with relevant descriptions and source versions. The information that may be returned depends on the configured access rights. The human interface and the technical access should lead back to the same business foundation.

MCP, the Model Context Protocol, is one way to make information and tools available to AI applications. It governs the technical exchange; it does not establish the business meaning of relationships or how the received content is used. Whether the required process and knowledge relationships are available needs to be checked for the particular connection.

Depending on the application, a direct API—a programming interface—or a suitable export can also provide access. The delivery mechanism is part of implementing context management. It does not replace the preceding work on meaning, origin and applicability. Where information is copied or cached, its version and the way changes reach the consuming application also need to be traceable.

Context engineering follows: selecting and assembling the information a model receives for a particular question or step. Anthropic describes this as ongoing curation of the model’s limited context. Our distinction concerns what is maintained: context management keeps business context usable; context engineering combines the relevant part with other information to prepare the context for the particular AI task.

One use is a traceable answer. A head of sales can ask which processes use Salesforce and what a change to the close date would affect. The shared foundation supplies the recorded uses, dependencies and responsible roles. Current opportunities or an assessment of the technical Salesforce configuration require additional data or investigation.

The Salesforce guide develops a question and a possible change assessment using fictional process documents. From the business map to a specific answer

Another use is supporting AI that carries out work. If an agent takes on an activity in a service process, it can retrieve the knowledge sources needed there. Its instructions, such as an external skill, describe the procedure. Maintained business context supplies the business foundation; current customer details come from the particular case. Implementing this activity is one application of context management.

The service guide explores the relationship between an agent activity, a skill and activity-specific knowledge in PULSE. Connect the process, external implementation and knowledge

The starting point can be one defined area and a specific question. In sales, that might be the two processes, their roles, the use of data and the authoritative descriptions. The team checks whether the actual work can be understood from these records and agrees who maintains them when things change. An initial retrieval then shows whether the business meaning survives the technical delivery.

This does not automatically require an additional system. Existing solutions may already provide suitable content, relationships, versions and access. The need for a shared environment grows when teams document the same relationships differently or AI applications each receive their own copies. What matters is how well the foundation can be maintained and reused over time.

PULSE by NEXTHORIZN connects strategy, processes, organisation, systems and versioned knowledge in one environment. These areas give the captured information a business context: knowledge pages can be viewed alongside their processes, while roles and systems add to the picture of how work is organised. People can understand, maintain and use the content in their work.

The aim is to build a maintained representation of the business that AI can use. The content and relationships an external application can actually retrieve through MCP depend on the available interface capabilities. Capturing information, reviewing relationships and maintaining them over time remain the foundation. Both a single answer and more extensive AI applications build on it.