Superintelligent Agents for Field Service: Jobs, Parts, Customers

Superintelligent agents for field service are AI agents that hold a durable record of every job, know the parts catalog and what each van carries, and use both to prepare dispatch decisions and customer updates. They improve over time because each finished job adds a verified fact that the next decision can draw on. Dispatchers and technicians keep the decisions; the agent prepares, checks and drafts.

Key takeaways

• Job history helps only when it is organized by site and equipment, with a source on every fact, instead of staying scattered across ticket notes.
• Parts knowledge (compatibility, substitutions, van stock, lead times) prevents more wasted visits than better routing alone.
• Customer updates improve when they are drafted from the live job state and corrected by dispatchers, so every edit becomes guidance.
• Start with one role, clear approval boundaries and a success criterion you can observe in your own records.
• Retrieval from current records suits this work better than retraining a model, because jobs and stock change daily.

What should a field service agent remember about a job?

Most service companies already have the raw material: tickets, technician notes, photos, invoices, warranty records and call logs. The trouble is that it sits in different places and is written for whoever wrote it. A dispatcher booking a repeat visit rarely has time to read six old tickets, so the history goes unused exactly when it matters.

An agent changes that by keeping one structured record per site and per piece of equipment, built from those sources. A useful record holds:

• The asset: make, model, identifier, install date if known, and where it sits on the site.
• The fault history: what was reported, what was found, what was tried and what finally worked.
• Parts used, parts that turned out wrong, and substitutions a supplier made.
• Site and access notes: gate procedure, on-site contact, opening hours, hazards, parking.
• Customer preferences: how they like to be contacted, who approves work, what they were promised before.
• Provenance: which record each fact came from, who wrote it and when.

Provenance is what makes the memory trustworthy. A technician's note saying the replacement board was a different revision than the catalog lists is worth more than the catalog entry, but only if the agent can show where it came from and a person can correct it. When a fact is corrected, the old version should be marked superseded, not silently overwritten.

This is a retrieval problem more than a training problem. Because records and stock change daily, the agent should look up current records when it needs them. AWS guidance comparing retrieval and fine-tuning draws this distinction, and Anthropic's writing on context engineering covers the companion discipline: give the agent only the slice of history relevant to the job in front of it.

Why does parts knowledge change dispatch more than routing does?

Routing software already finds a short path between addresses. What it cannot tell you is whether the technician who arrives will be able to finish the job. A visit that ends with a part on order costs the customer a second appointment and the company a second trip, and the cause was often knowable at dispatch time.

Parts knowledge for an agent means several linked things:

• Compatibility: which parts fit which models and revisions, and which are known not to.
• Substitutions: approved alternates and supersessions when a part number changes.
• Stock: what each van and the warehouse hold, according to the last confirmed count.
• Lead times: how long suppliers actually take, taken from your own past orders.
• Site history: what was used on this equipment before.

At dispatch, the agent reads the job description and the asset history, proposes the likely parts, compares them with each van's stock and flags a gap before anyone is sent. It suggests; the dispatcher decides whether to assign someone else, pre-order the part, or send the technician anyway and tell the customer what to expect. Van condition and servicing is a separate topic, covered in AI for fleet management.

Over time the pattern sharpens. When one fault description on one model keeps ending with the same part, that link is worth saving as a reviewed note, so the next similar call starts with a better first guess. The word reviewed matters: someone who knows the equipment should confirm the link before it guides decisions. Trades differ in detail, as the guides on HVAC dispatch help and on estimates, job status and parts in auto repair show, but the question is the same: does the right part arrive with the right person?

How does job memory improve customer updates?

Customers rarely want more messages. They want the right ones: who is coming, when, what to expect and what changed. Most update failures are memory failures. The person replying does not know a part was ordered yesterday, that this is the second visit, or that the customer asked for a call before arrival.

An agent reading the live job state can draft each update from facts: technician assigned, arrival window, parts status, whether a revisit is needed. Memory adds the personal layer. This customer prefers text messages, the site contact is the building manager and not the person who booked, and the last visit overran and caused frustration.

Set approval boundaries by the kind of statement, not by the channel:

• The agent may send routine status messages built from confirmed job state, such as technician assigned or window confirmed.
• A person approves anything that commits the company to a time outside the booked window, a cost, a warranty position or a stated cause of failure.
• Safety-related findings are explained by a technician or manager, never by the agent alone.

Dispatcher edits are the learning signal. If staff keep rewording the same draft, that wording is a candidate for the template or the agent's guidance, again after review. A small plumbing business can begin here, as described in the guide for plumbers, before touching dispatch at all.

What does this look like on a real call?

Illustrative scenario: a customer calls because a commercial water heater stops heating now and then. It is the third call about the same unit.

The agent pulls the history. The first earlier visit replaced a control board. The second technician's note says the new board was a different revision than the original and the fault came back. The agent also reads stock: one van carries the revision in the catalog, another carries the revision named in the note. A third technician attended this site last time.

Before the dispatcher assigns anything, the agent shows a short history with sources, the two revisions and which van holds which, the technician who knows the site, and a draft message acknowledging that this is a repeat visit and giving the window. The dispatcher sends the technician who attended before, asks for the right revision to be loaded, changes one sentence in the draft and approves it.

After the job, the closing note says the fault was a wiring connector, not the board. The agent records that as a new fact, marks the board theory as ruled out for this unit, and keeps the dispatcher's edit as feedback. The next call about this model starts with a better question.

What is a sensible plan for the first role?

Start narrow. One job type and one role give you something to measure and keep the cleanup of old data small. A workable order is:

• Choose one role, for example preparing dispatch for repeat visits and drafting the matching customer updates.
• Name the sources: ticketing, technician notes, parts catalog, stock counts, supplier lead times. Note which ones you trust and which you do not.
• Build the per-asset record with provenance, and have a senior technician review a sample for errors.
• Write the permissions: what the agent can read, what it can draft, what it can send and what always needs a person.
• Define one observable success criterion, such as fewer revisits caused by a part missing from the van, judged from your own records.
• Run in shadow mode first, with the agent preparing suggestions beside the dispatcher's real decisions, and compare them.
• Move to assisted mode, where dispatchers see suggestions before assigning, and review corrections every week.
• Extend to the next job type only when the first one holds.

Where are the risks, and how are they contained?

There are three main risks. The first is wrong memory, handled by sourcing every fact and letting staff correct it. The second is over-reach. OWASP authorization guidance recommends least privilege and checking permissions on every request, and the same applies here: reading job history, seeing prices, and sending messages to customers should be granted separately and reviewed from time to time.

The third is untrusted input. Customer emails, photos and supplier messages can contain text that tries to steer the agent. They should be treated as data to read, never as instructions to follow. Technical safety follows the same logic: the agent does not improvise repair procedures. It points to the manufacturer documentation held in its knowledge base and routes the question to a person.

Be Human handles this as a managed engagement. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. After that, Be Human operates the agent remotely, including monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, while your team keeps control of identity, memory, channels and tools.

How do you know the agent is getting better?

Better has to be something you can see. Choose signals from your own records: revisits caused by a missing part, how often dispatchers override a suggestion and why, how often customers must call to ask where the technician is, and how often a draft goes out unedited.

Also keep a set of past jobs whose outcomes you know. Replay them with the history as it stood at the time and check whether the suggested part and technician match what eventually worked. Anthropic's writing on evaluating agents describes this approach: define tasks, grade outcomes, and rerun after every change. Keep a log of each suggestion, the sources it used and the edits made, so weekly reviews are concrete instead of anecdotal.

If you want to find the first task in your service operation worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Is a field service agent the same as field service management software? No. Field service software stores jobs, schedules and invoices. An agent works on top of those records: it reads history, checks parts, drafts messages and prepares decisions, using the software's tools under permissions you set. In most cases you keep the software you already have.

Will an agent replace dispatchers or technicians? That is not the design. Dispatch involves judgment about people, relationships and exceptions, and technicians hold knowledge that is rarely written down. The agent takes over the reading, checking and drafting so people can spend their time on decisions, and it records what technicians learn so it is not lost.

Do we need clean data before starting? No, but you need to know which sources can be trusted. Starting with one job type and one group of equipment keeps the cleanup small, and provenance on each fact lets staff correct the record as they go. Gaps in the parts catalog or stock counts are worth finding early, because the agent will expose them.

What happens when the agent is wrong? Suggestions cite their sources, so a dispatcher can see why the agent proposed something and correct the underlying fact. Actions that commit the company stay behind approval, and the log shows what happened. Errors become corrections, and recurring evaluations check that each correction held.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.