Agentic Context Engineering
The Bruviti AIP ingests multi-source enterprise data, transforms it into a structured knowledge fabric, compiles versioned context products, and delivers precise context through agentic retrieval workflows — replacing ad-hoc document search with precompiled, validated intelligence.
The Problem: Why Documentation Retrieval Is Hard
Enterprise service environments contain vast amounts of technical knowledge distributed across knowledge base articles, product documentation, CRM records, parts databases, call logs, service records, telemetry data, and connected device data. Standard retrieval approaches — keyword search, basic RAG, full-text indexing — treat these sources as flat document collections.
This creates several failure modes:
- Ambiguity — a query for "pump" returns results across dozens of unrelated pump types, models, and subsystems because the search has no structural understanding of the equipment domain
- Fragmentation — the answer to a single question may span a product manual, a service bulletin, a parts list, and a field service note, but these documents are not linked
- Staleness — documents exist in multiple versions with no evaluation of which version is current, accurate, or applicable to a specific equipment revision
- Context loss — a procedure retrieved out of context may reference the wrong model, assume tools the technician doesn't have, or skip prerequisite steps that vary by installation site
Context engineering addresses these problems by restructuring raw data into a queryable knowledge fabric, compiling it into validated context products, and delivering it through an agentic workflow that understands what context is needed for each situation.
Data Ingestion Pipeline
The pipeline ingests from multiple enterprise data sources and transforms raw content into structured, ontology-tagged knowledge.
Data Sources
The platform connects to the following source types:
| Source Type | Examples | Content |
|---|---|---|
| Knowledge bases | Internal KB systems, wikis | Troubleshooting articles, how-to guides, FAQs |
| Product documentation | Manuals, engineering specs, service bulletins | Equipment specifications, maintenance procedures, parts lists |
| CRM data | Salesforce, Microsoft Dynamics | Customer records, installed base, service history |
| Parts databases | ERP parts masters, inventory systems | Part numbers, compatibility, pricing, availability |
| Call logs | Contact center recordings and transcripts | Customer-reported symptoms, resolution steps, escalation paths |
| Service records | FSM systems (ServiceMax, IFS, ServiceNow) | Work orders, repair history, technician notes |
| Telemetry | IoT sensors, connected equipment | Operating parameters, error codes, performance metrics |
| Connected device data | Equipment controllers, PLCs | Real-time status, configuration, diagnostic outputs |
Intelligent Understanding
Raw content passes through NLP processing that performs entity extraction (identifying equipment, parts, symptoms, and procedures), relationship mapping (linking entities based on the ontology framework), and cross-reference resolution (connecting the same entity across different source documents). The output is content tagged with ontology-defined entity types and relationships.
Data Cleanup & Normalization
Extracted data is deduplicated, format-standardized, and cross-referenced. When multiple sources describe the same entity (e.g., a part number appearing in a manual, a parts database, and a service record), references are resolved to a single canonical entity in the knowledge fabric.
How Context Engineering Works
Context engineering operates in three sequential phases: building the knowledge fabric, compiling context products, and executing retrieval workflows.
Phase 1: Knowledge Fabric
Raw unstructured data — manuals, service records, engineering specifications — is transformed into a structured knowledge graph. Entities are tagged with ontology types (asset, subsystem, component, part, procedure, symptom, parameter). Relationships are mapped between entities (part-of, requires, mitigated-by, compatible-with, supersedes, references). Cross-references across documents are resolved so that the same equipment, part, or procedure is represented as a single node in the graph regardless of how many source documents mention it.
The result is a queryable knowledge fabric that understands the equipment domain — not just individual documents, but the structural relationships between every entity in the enterprise's technical knowledge.
Phase 2: Context Factory
The knowledge fabric is compiled into prepackaged context products — structured, versioned bundles of knowledge optimized for specific retrieval scenarios. This compilation step is what separates context engineering from standard RAG: instead of searching raw documents at query time, the system serves precompiled, validated knowledge packages.
Context products are versioned and must pass evaluation gates before release. When source data changes (a new service bulletin, an updated parts list, a revised procedure), affected context products are recompiled and re-evaluated.
Phase 3: Retrieval Workflows
Agentic retrieval workflows consume context products to serve user requests. Rather than performing raw document search, the retrieval system understands what type of context is needed and pulls the appropriate precompiled products. The workflow is detailed in the Agentic Retrieval Workflow section below.
Precompiled Context Products
The context factory produces four types of context products, each structured for a specific retrieval pattern:
| Product Type | What It Contains | Use Case |
|---|---|---|
| Entity Cards | Everything known about a specific asset, component, or part: specifications, compatibility, service history, known issues, related procedures | Technician needs complete information about a specific piece of equipment or part |
| Procedure Cards | Step-by-step repair or maintenance procedures with required parts lists, tool requirements, prerequisite conditions, and safety warnings | Technician needs to execute a specific maintenance or repair task |
| Symptom Playbooks | Diagnostic decision trees linking reported symptoms to probable root causes to resolution procedures. Includes branching logic based on equipment model, revision, and operating conditions | Technician or agent needs to diagnose an issue from reported symptoms |
| Service Packs | Bundled context for specific service scenarios — combines relevant entity cards, procedure cards, and playbooks into a single package for a given equipment type and service event | Field technician needs everything for a specific service visit (equipment context, procedures, parts, diagnostics) |
Precompiled vs. real-time RAG: Precompiled context products are already structured, validated, and versioned — retrieval is fast and consistent. Real-time RAG depends on retrieval quality at query time, has no validation layer, and produces inconsistent results across identical queries. The platform uses precompiled products as the primary retrieval mechanism, with real-time search as a supplement for edge cases not covered by existing products.
Agentic Retrieval Workflow
The retrieval workflow is a four-step agentic process that goes beyond search to actively reason about what context is needed and whether the retrieved context is applicable.
Step 1: Identify
The system analyzes the incoming query or situation to determine what type of context is needed. This involves intent classification (is this a diagnostic question, a procedure request, or an information lookup?), entity recognition (which specific equipment, part, or symptom is being referenced?), and scope determination (what level of detail is appropriate?).
The ontology plays a critical role here — it disambiguates entities. When a technician asks about "the pump," the ontology resolves which specific pump based on the service context (customer, site, equipment hierarchy).
Step 2: Retrieve
Using the identified entities and intent, the system pulls relevant context products. Retrieval is ontology-scoped: the system uses the knowledge graph's relationship structure to include related context (e.g., retrieving the procedure card for a repair also pulls the entity card for the affected component and its parent subsystem). This eliminates the fragmentation problem — all relevant context arrives together.
Step 3: Validate
Retrieved context products are validated for applicability before being served. The validation checks include:
- Model match — is this procedure for the correct equipment model and revision?
- Version currency — is this the latest version of the context product, or has a newer revision been published?
- Condition applicability — are the operating conditions assumed by this procedure consistent with the actual site conditions?
- Prerequisite check — are there prerequisite steps or conditions that must be verified before this context is actionable?
Step 4: Adapt
Validated context is tailored to the specific situation. Adaptation considers technician skill level (adjusting procedural detail), available tools and parts at the current site, local conditions (altitude, temperature, power supply characteristics), and presentation format (step-by-step for field use vs. summary for triage). The adapted context is what ultimately reaches the user — not raw documents, but situation-specific, validated intelligence.
Purpose-Built Models
The context engineering pipeline uses two categories of purpose-built models that are trained specifically for the equipment service domain.
Ontology-Aligned Embeddings
Standard embedding models encode text based on surface-level linguistic similarity. The platform's embedding models are trained on the ontology structure, so semantically related equipment concepts are close in vector space even when they use different terminology. For example, "pump seal" and "shaft seal for centrifugal pump" are mapped as near-neighbors because the ontology knows they reference the same component type — standard embeddings would treat them as only loosely related.
This alignment means that retrieval queries automatically capture ontological relationships. A search for a component retrieves content about that component's parent subsystem, sibling components, and associated procedures without requiring explicit query expansion.
Technician-Focused SLM
A small language model (SLM) fine-tuned on service language, field procedures, and domain-specific terminology. The SLM understands equipment-domain shorthand (e.g., "the unit is throwing a P0420") without requiring explanation or mapping to general-purpose language. It processes diagnostic descriptions, interprets error codes, and generates service-appropriate responses using the vocabulary that technicians use in practice.
The SLM is lightweight enough to deploy at the edge (see Edge & Offline Architecture), enabling local inference for field technicians working without network connectivity.
Domain specificity matters: General-purpose language models and embedding models lack the structural understanding of equipment hierarchies, part relationships, and service workflows that field service operations require. Purpose-built models trained on ontology structure and service-domain data close this gap — they understand the domain the way a subject matter expert does.