Implementing context management: work through a service handoff

The first scope ends with a usable case handoff. It includes identifying the device, describing the issue, recording what has been established and explaining where the case goes next. Repairs, binding appointment confirmations and spare-part orders are outside this initial scope.

You need someone from intake and someone who handles these cases afterwards. Include the person responsible for the relevant service instruction. Bring in the system owner when you need to establish which fields or access the application actually supports. A large project team is not a prerequisite.

Use an approved, anonymised case for the session, or create one that is clearly fictional. This example develops the distinction between business context, AI assistance and the application that carries out an action from my article “Wenn KI mitarbeitet”.

The next person has little to build on. Ask them to identify exactly what they would need to ask again. A list of possible data fields is less useful than a specific question: what information is missing that prevents you from choosing the next step?

In this example, the model identification is needed before an appropriate instruction can be selected. “Will not start” could also describe different observations. Service determines the appropriate follow-up questions from its approved instruction. We are deliberately not deriving repair advice here.

Separate three kinds of information during the session. The instruction describes the general procedure. The case note records what the customer reported and what has been established. The business application holds the current case status. These need different forms of maintenance.

A status such as “appointment confirmed” belongs to the current transaction. It should not be duplicated as a lasting knowledge rule. Conversely, the service instruction does not have to be copied into every case. A traceable reference to the version used may be more appropriate.

If two instructions both claim to govern the same model range, the relationship remains unresolved until the responsible expert has settled it. Additional text processing would simply carry that conflict forward.

The case note distinguishes the customer’s observation from a technical finding. “Display stays dark” does not become “faulty electronics”. A request for service does not become a confirmed appointment either.

Try the handoff without AI first: can the next person continue from it? What further question remains, and does it really belong within intake? If the structure merely moves work upstream without helping the next stage, revise it.

A limited contribution could be drafting the case note from the incoming report and highlighting missing information. The team reviews the draft before passing it on. Selecting a technical intervention or making a binding appointment would be a different scope with additional requirements.

Anthropic distinguishes predefined workflows from agents that choose their next steps more dynamically. The relevant implication for this starting point is straightforward: a bounded language task inside an established process does not automatically require an autonomous agent.

Try the proposed assistance with a complete case, a missing model identification and a conflicting description. Assess whether the draft invents details, preserves uncertainty and exposes the necessary follow-up question. Include review and correction time in the comparison with existing handling.

• A bounded handoff with an outcome described in business terms.
• A small set of source relationships supporting the intake decisions.
• A named person and a target date for resolving outstanding relationships.
• Example cases the team can use to assess the next version of the assistance.

Tie the first review to an actual change: a new model range, an updated instruction or a different service role. Record that specific trigger. An instruction to “keep context current” leaves unclear when someone needs to act.

Use the blank inventory table for this source work. Its separate example sheet shows a sales case; add your own service relationships to the inventory. Record the relationships in the inventory