What is context management?

Imagine a mid-sized business consolidating its applications. An old ticketing system appears on the list. A replacement has already been introduced. The licence cost is known, and the technical team could shut the old system down. Is that enough to make the decision?

The relationships explain the situation: a service process still uses the old system for warranty cases. A work instruction refers to its case numbers. The responsible department needs access to open cases. One person owns the business transition; another runs the system technically.

“System exists” is a piece of information. “This system is needed at this process step for these cases until the transition has been confirmed” describes the relevant context. It connects existing information into a basis for a decision that someone can check.

Strategy explains why applications are being consolidated in this example. The process shows the work affected. The organisation identifies the responsible roles. The system reference leads to the application. Knowledge provides the applicable work instruction. None of these views alone answers the shutdown question.

Such a map of the business is only as reliable as its maintained relationships. “Used by” should lead to a particular process or role. A note saying “important to service” can help with discovery, but leaves unclear who can assess the dependency. I developed this idea of a continuously maintained business map in my article about the next stage of AI.

Context also needs to account for time and applicability. “Required until migration” offers little help without a checkable condition. A more useful entry would say that service must confirm that open warranty cases have been transferred or remain accessible elsewhere; the system owner can then assess the shutdown.

Knowledge management includes making knowledge available, usable and current. Context management, as we use the term, emphasises its relationships with the rest of the business. The responsibilities overlap. An organisation with well-maintained relationships has already done a substantial part of this work.

Context engineering addresses the technical assembly of information for a language model: which material is selected, in what form and within what space constraints? Anthropic describes context as a limited resource whose selection and management affect an agent’s work.

MCP is a protocol through which applications can provide context and tools. Its specification does not determine how an AI application uses the context it receives.

For our ticketing example, the business work establishes why service still needs the application. The technical implementation determines how an AI system receives that information. An additional connection can make the note accessible; someone in the business still needs to assess whether it remains true.

The shutdown decision does not require every relationship in the organisation. It needs the affected work, the outstanding transition condition and the people who can assess it. The entire history of every ticket does not need to be copied into another platform for that purpose.

Existing systems can remain the authoritative locations for transactions and documents. The additional work is to identify those locations clearly and track changes to their relationships. For sensitive content, this also includes who may access it; making a relationship visible must not bypass permissions.

A useful starting point is a recurring question whose answer currently requires several people or repositories. The shutdown question is one possible case. If a proposed relationship cannot be tied to a decision or a review trigger, it can probably wait outside the first scope.

PULSE by NEXTHORIZN brings strategy, processes, organisation, systems and versioned knowledge into a shared environment. Its relationships help people move from a process to the responsible role, application or knowledge page. The connection itself becomes part of the maintained working foundation.

This provides a basis for people and for AI assistance. It also remains organisational work: a published knowledge page needs business ownership, and a process relationship needs a clear purpose. PULSE can represent that work; the responsible business still decides whether the old ticketing system can be switched off.

The implementation guide uses a service handoff to show what belongs in a first working session. Work through your first use case