An AI agent on bad asset data is confidently wrong at scale.

In its current form it covers three areas: assisting with scheduling including filling gaps in the schedule, helping technicians troubleshoot on the job, and summarising job reports. On mobile it supports voice interaction and audio playback, so a technician can use it without stopping work. Its responses are grounded in your own CRM records, knowledge articles and asset data rather than the open web. This part of the platform is moving quickly, so it is worth confirming the current capability set at the time you evaluate rather than relying on any write-up, including this one.

Grounding means the agent's answers are constrained to your own records — asset data, knowledge articles, service history — rather than generated from general knowledge. It is a genuine safety property, because it stops the agent inventing plausible answers about equipment it knows nothing about. The commercial consequence is direct: the agent inherits the quality of whatever it is grounded in. An organization with a thin installed base and knowledge articles nobody has reviewed for years will get an agent that is wrong and well-cited, which is worse than no agent at all.

Check five things honestly. Do asset records exist for the equipment you service, with real service history. Are knowledge articles maintained and accurate. Is debrief capture consistent enough that failure causes are structured rather than free text. Does your scheduling policy already produce assignments dispatchers accept. Are entitlements modelled so the system knows what each customer is owed. If several of those are no, the useful next step is fixing them rather than running a pilot — and all of that work pays back on its own terms whether or not you ever deploy an agent.

If you can write the decision down as a rule, build a Flow. Rules are cheaper, faster, consistent and auditable, and the overwhelming majority of field service process work is deterministic — creating records, applying entitlements, sending notifications, escalating at a threshold. Agents earn their place where the input is unstructured or the judgement genuinely varies: interpreting a customer's description of a fault, summarising a long job report, or suggesting what has fixed a similar failure before. Using an agent for work a rule could do costs more, runs slower and is considerably harder to explain to an auditor.

Start narrower than feels necessary. Suggesting a fix to a technician, summarising a report and drafting a customer message are low-risk because a human reviews the output before it matters. Rescheduling a customer's appointment, committing to an SLA or making a chargeability decision are materially different levels of authority and should require approval initially. The practical approach is to log every action the agent proposes, measure how often a human changes it, and widen autonomy only where that number is consistently near zero. An undefined guardrail is how a promising pilot ends at the first surprise.

Decide the metric and measure it before deployment, because retrofitting a baseline is impossible. For troubleshooting assistance the honest measures are first-time fix rate and repeat visits. For report summarisation it is administrative time per job. For scheduling assistance it is dispatcher override rate and unscheduled appointment count. Alongside the outcome metric, track how often humans override the agent — that number tells you where it is weak and whether it is improving, and it is usually more actionable in the first few months than the headline metric is.