01 / Situation
The situation
Support for a connected product rarely begins with a clean problem statement. A customer describes a symptom; the underlying issue may sit in installation, hardware, firmware, connectivity, cloud state, configuration or expected product behavior.
That makes the work only partly a knowledge-retrieval problem. The system has to decide what evidence matters, what remains uncertain and which next question or tool call can reduce that uncertainty safely.
02 / Responsibility
My responsibility
Shape the operating model for AI-supported investigation across documentation, product evidence, tool access, evaluation and human escalation.
Keep the system grounded in the limits of available evidence instead of presenting plausible language as a diagnosis.
03 / Complexity
The operating complexity
- Customer descriptions are incomplete and product state changes over time.
- Evidence can be distributed across devices, cloud services, installation history and support records.
- Some tool actions are observational; others can change product state and require tighter permissions.
- A useful escalation needs to preserve hypotheses, evidence and uncertainty—not merely hand over a transcript.
04 / Principles
Principles I carry forward
Investigate, do not perform certainty
Maintain explicit hypotheses and identify which observation would strengthen or weaken each one.
Ask targeted questions
Every question should have diagnostic value. Collecting more text is not the same as collecting better evidence.
Evaluate against historical work
Test on representative support cases and compare with a measured human baseline, including escalation quality and recoverability.
Design the human boundary
Escalation is part of the system, not a failure mode to hide. High-risk, ambiguous and permission-sensitive cases need an intentional handoff.