From work order to fix, on one screen. Ranked tickets across every site, a verified asset registry behind each one, and a knowledge-graph diagnostic agent that walks a technician through the repair.
A working slice for a single soft-serve machine. Start on the morning briefing, tap the top revenue ticket, and follow the diagnostic agent through the fault. Tap to explore.
Won't freeze: product still soft after an hour in AUTO
ICE_CREAM tier is $500/day in lost revenue. No backup machine multiplies ×1.5. Three days open adds +30. Highest score in the fleet today.
search_nodes("product not freezing liquid auto mode")
search_nodes("product still liquid not thick soft serve not freezing")
sym:taylor-c602:product-too-soft — "The product is too soft."neighbors("sym:taylor-c602:product-too-soft")
caused_by fan-out (mapped below).get_node("cause:taylor-c602:dirty-condenser-or-air-filters")
diagnosed_by edge to a procedure.A demo can show an agent reaching the right answer once. The harder question is whether walking the knowledge graph beats handing the same agent the manual. So we built a probe suite and ran it three ways.
The whole margin is two probes, and both are the graph keeping the agent inside the right fault family instead of guessing across it. On T1 the graph reaches the refrigeration cause (dirty condenser and air filters) where pdf-only picks the wrong family, worn scraper blades. On T4 the graph reaches worn scraper blades where pdf-only invents a sanitizing-solution cause that is not in scope.
Seven lay phrasings (won't freeze, pouring out like milk, runny shake, soup consistency, and more) are indexed onto the one symptom node. A flat manual has no won't-freeze entry to look up. Lay queries that missed or landed on the wrong symptom before now rank the correct one first, a real fail-then-pass at the retrieval layer.
The honest caveat: a strong model rewords lay language into manual vocabulary on its own, so on this agent the alias probes tied the manual on the final answer. We count the bridge as a structural retrieval advantage the flat manual cannot have, not an outcome win against a strong agent.
The weakest result, stated plainly. The cascade edge is present in the data and the oracle condition passes, so the graph holds the answer. But the agent took the local cause instead of traversing the cascade to the root. That is an agent-side retrieval miss, queued for prompt hardening. It is a tuning problem, not a gap in the graph.
The graph helps. A qualified yes. It wins on family discrimination, it gives a retrieval advantage the flat manual structurally cannot, and it has one known weakness (cascade traversal) that is an agent-tuning problem rather than missing data. Six of seven with the graph, four of seven from the manual alone, seven of seven when the agent is handed the right nodes.
A nightly agent scores every open ticket by lost revenue, backup coverage, and age, then groups them by site. Revenue risk floats to the top.
Each ticket resolves to a real asset: make, model, serial, install date. A confidence score flags matches that need a human to confirm, with a one-tap fix.
Shipped and measured. The asset becomes a walkable knowledge graph for that exact machine. A ReAct agent searches it, follows typed cause and procedure edges, and returns a cited answer. We tested it against the manual: it wins on keeping the agent in the right fault family, with one traversal weakness we are still tuning.