​

The Intelligence Layer

An agent can work in a demonstration and still fail in a live field service operation. The failure appears when usage grows. Costs rise, answers slow down, and each request rebuilds context that the system should have retained. By late 2024, VH3 AI had production agents processing hundreds of thousands of jobs across multiple large clients. That work exposed the limit of classic retrieval. Semantic search over raw job records can find nearby text. Operational work requires connected history, structured outcomes, pattern detection, and a current scope for each task. A chatbot that answers “how many jobs did we complete last week?” uses a different path from an agent that prepares a site briefing, investigates a recurring fault, monitors SLA risk, and synthesises five years of history. The intelligence layer supplies the additional memory and routing those workflows need.

​

The retrieval problem

Classic retrieval embeds a query, finds nearby chunks, and passes them to a model. The pattern suits a single question and a single answer. An agent runs a task. It crosses entity relationships, checks history, evaluates patterns, and produces a recommendation. The agent therefore needs a retrieval contract. The platform returns a prepared bundle of resolved, current, authoritative operating context. The agent can use that bundle without rebuilding the same context on every run. VH3 AI implements that contract with four complementary memory primitives. Each primitive handles a different part of the operational question, and the synthesis path combines their results.

​

The four primitives

​

1. Relational memory and the knowledge graph

Many field service questions depend on relationships. Which engineer has worked at this site? Which sites share a parent customer? Which jobs cluster around the same asset? Which fault patterns connect engineers who have never worked together? The knowledge graph answers those questions by linking jobs to engineers, sites, customers, outcomes, equipment, and history. A query can start at any linked entity and traverse the relevant relationships in either direction. Entity resolution handles source data that different people write across different systems. For example, the platform can resolve “Tesco PLC”, “Tesco Stores”, and “Tesco Express Watford” to the same customer when the evidence supports that link. The graph supports reporting, discovery, monitoring, and synthesis. Every consumer works from the same linked entities.

​

2. Semantic memory and meaning-based search

Some questions ask for similar faults, outcomes, or precedents. They depend on meaning, even when the records share no keywords. The vector index stores fault descriptions, job notes, worksheet answers, and engineer observations by meaning. A search for “boiler intermittent fault” can find “heating system cutting out sporadically” and “intermittent heating loss”. The search returns graph-linked job records with their engineers, sites, outcomes, and history. Builders receive connected records instead of detached text fragments.

​

3. Structured memory and enriched operational records

Field service data arrives as free text and inconsistent fields. Different engineers can record the same outcome in different formats, and different devices can produce different worksheet shapes. The enrichment pipeline processes each job once. It classifies the fault type, structures the work performed, identifies equipment, resolves the operational outcome, and links the job to the correct entities. The pipeline stores a compact record that downstream agents, reports, and automations can read without repeating extraction. This pre-computation moves interpretive work to ingest. Every report, briefing, automation, and agent query reads the same prepared artefact. The platform does the work once and reuses the result.

​

4. Temporal memory and continuous monitoring

Sentinels run as deterministic background evaluations against the operational record. Each sentinel watches for defined conditions such as performance slips, site deterioration, SLA drift, dormant customers, overdue service intervals, emerging fault clusters, and growth signals. The sentinel evaluates stored fields and graph relationships on a schedule or after relevant data changes. Detection does not require an LLM call. When a condition crosses its threshold, the platform records the evidence and routes an actionable signal to the right person or team. Temporal memory gives the operation a way to act on change, not only answer questions.

​

How the primitives combine

The synthesis layer combines the primitives for each workflow. A pre-visit engineer briefing draws on all four.

• Relational. The engineer sees prior jobs at the site, the people who attended, and the recorded outcomes.
• Semantic. The briefing includes similar faults from elsewhere in the operation and their precedents.
• Structured. The briefing reads compact records from the last three visits.
• Temporal. The briefing includes active sentinel results for the site or customer.

The engineer receives operating context assembled from current, resolved records and scoped to the work ahead. A fault investigation follows the same path. Relationship traversal supplies job history and engineer connections. Meaning-based search finds similar incidents. Structured records supply classified fault data. Sentinels show whether the pattern is new or recurring. An account review combines the customer’s linked jobs with structured performance data, similar communication patterns, and current dormancy or risk signals. A single retrieval method cannot support all of these workflows. The synthesis path needs connected memory and task-specific routing.

​

The domain model: why the substrate speaks one language

The four primitives remain useful only when they refer to the same entities. VH3 AI therefore defines a field service model for work performed at a place, for a customer, by an engineer, on equipment, with an outcome. Those concepts have explicit meanings and relationships. A job carries history. A customer has a hierarchy. A site has operational links beyond an address. In this documentation, the substrate names the decoupled, persistent operational knowledge graph and vector index in the customer’s account. VH3 AI stores resolved entities and relationships in the graph. It stores meaning-based representations of operational text in the vector index. Enriched records, cases, sentinel definitions, and operating rules connect to that same account-level foundation. An LLM call performs ephemeral inference in a context window and returns a response. The call reads the substrate, but its temporary context does not become the system of record. A later request can use the persistent records without relying on the previous model session. VH3 AI maps incoming data to the canonical model. Source systems use different names, fields, and assumptions. The model applies the same definitions and resolution rules before a job enters the intelligence layer. The platform classifies the job, resolves its entities, and links its customer, site, engineer, outcome, and equipment. This produces three practical effects. Queries stay consistent across sources. Engineer performance aggregates, fault searches, and repeat-visit sentinels use the same entity definitions regardless of the source FMS. Entity resolution follows rules. The model defines what counts as a customer, what evidence can link two records, and which relationships must exist before the platform draws a link. The ingestion pipeline applies those rules as new data arrives. Intelligence stays portable. A second field system can resolve into the same model. Historical records keep their entity links, and the operational picture remains in the customer’s account when the source system changes. VH3 AI keeps the detailed schema, classification taxonomy, and resolution rules private. Builders receive the contract at each endpoint. They can rely on consistent, resolved, connected records regardless of the upstream source.

​

Pre-computation and retrieval cost

Many AI tools rebuild the full context pipeline for every interaction. A new session triggers a search, context assembly, and model call. A user query, automation, or report then starts from zero. VH3 AI enriches each record once at ingest. The onboarding process builds the graph, and incremental updates maintain it as new jobs arrive. The platform produces the compact record once and serves it to every consumer. Serving a hundred users from the same foundation costs less per query than serving them from a system that rebuilds context on every call. The second team inherits work that the first team already funded. A new automation reads prepared context without generating it again. Shared preparation lowers the model cost per query as usage grows.

​

Mature on day one

The intelligence layer needs history to surface patterns, resolve conflicts, and produce useful synthesis. VH3 AI loads up to five years of operational history during onboarding. The ingestion pipeline enriches every job, resolves every entity, maps every relationship, and reconciles source conflicts before go-live. Agents can use that foundation on day one. Each new job then follows the same enrichment path and joins the graph and vector index. The account gains evidence without a warm-up period.

​

What this means for builders

VH3 AI exposes the intelligence layer through a full API and an MCP surface. Builders can query every primitive and bring their own model, framework, and agents. When you build on the intelligence layer, your agents start from a prepared, resolved, current understanding of the operation. They read the account’s persistent records and request model inference only when the task needs language or judgement.

​

Next step

Choose one known customer and one recurring fault. Call the operational discovery endpoint, compare the returned linked jobs with the source record, then add a sentinel for the pattern if the evidence supports it. Continue with Building on the layer when the first read matches the operation.