Beyond Semantic Search: How We Built a Production-Grade SKU Cross-Reference Agent
The Industry-Agnostic Challenge: The Crisis of Certainty
In the world of industrial distribution and complex supply chains, the hardest problem isn't "search" , it is certainty.
Whether you are managing plumbing fittings, electronic components, grocery, pharmaceutical or a horizontal SKUs, the core challenge is identical: identifiers fragment across vendors, catalogs, and legacy systems. A customer doesn’t just want something "similar." They need to know exactly which item maps to their internal source of truth, whether a SKU is truly interchangeable, and precisely where technical ambiguity begins.
Returning a "similar" item is easy. Resolving to the correct SKU is what protects pricing integrity, fulfillment reliability, and customer trust. At Nagent AI, we developed a system that operates with the restraint and traceability of a seasoned professional, not a chatbot.
The Architectural Philosophy: Identification vs. Discovery
Most enterprise AI fails because it treats every query as a search problem. We approached this as a multi-stage resolution problem. Our solution utilizes a hybrid Multi Agent Workflow System (MAWS) based orchestration, combining the reasoning power of Gemini 3 Pro (Decision Maker) with the execution capabilities of OpenAI 5.2 Assistants, all managed through the Nagent AI No-Code Agent Builder.
:quality(80))
Intent-First Classification
We introduced an Identifier Classification Layer whose sole responsibility is to understand the "DNA" of the input. Before any retrieval happens, the system determines if the input is:
A vendor-specific identifier (MPN).
A manufacturer catalog code.
Internal organization SKU.
Unstructured descriptive text.
By establishing intent upfront, the system avoids "guessing" downstream. If the intent is an exact identifier, the system enters Authoritative Lookup mode. If it is a description, it enters a highly constrained Discovery mode.
Step-by-Step Methodology to Solving the SKU Bottleneck
Step 1: Authoritative Mapping Over Similarity
The first non-negotiable rule is that authoritative resolution must always beat semantic similarity. Our vector store, powered by Pinecone, is structured to prioritize exact matches.
The Logic: We search a unified vector store for explicit vendor-to-internal SKU links.
The Execution: If a direct mapping is found, the system "locks" that anchor SKU. Similarity-based results are never allowed to override or contaminate this authoritative link. This prevents "noisy" matches from surfacing when an exact part is known to exist.
Step 2: Treat Confidence as a System Constraint
In enterprise AI, "false certainty" is a trust-killer. We treated confidence as a rule-enforced contract:
Exact Matches: Minimum confidence floor of 85%.
Similarity Results: Capped at a maximum of 20-40%, ensuring they never act as anchors.
"Not Found" as a Value: We made "Not Found" a first-class outcome. The system is programmed to stay silent rather than offer a weak, potentially dangerous suggestion.
Step 3: Solving the "Vector Blind Spot"
Standard vector embeddings struggle with precision. They often cannot distinguish between a 2-inch pipe and a 2.5-inch pipe because the "semantic" difference is negligible, even though the physical difference is a failure.
The Solution: Metadata Filtering. We stored structured attributes (size, material, type) as first-class metadata alongside embeddings. We implemented a "Filters-First, Vectors-Second" approach. The system first filters for structurally compatible items; only then does it use vector proximity to rank them. This ensures that only a 2-inch PVC fitting is compared to other 2-inch PVC fittings.
Step 4: The Deterministic Breakthrough (Hash-Based Cross-Referencing)
Once an anchor item is identified, we solve the interchangeability problem without using vectors. We introduced two deterministic signals:
Spec_Hash: A unique fingerprint representing exact functional compatibility. If two items share a spec_hash, they are binary-safe replacements (Interchangeable Commodities).
Family_Hash: Captures adjacency within a product family (closely related but not guaranteed drop-in replacements).
This turns the agent from a "searcher" into a Product Intelligence Engine. It doesn't "guess" that a part is an equivalent; it knows based on encoded engineering specs.
The Technical Stack: A Hybrid Intelligence Model
Building a system that behaves like a senior expert required a specific combination of specialized models:
Agent Orchestration (Nagent AI): The "brain" that manages the logic flow, ensuring the hand-off between different stages is seamless and follows the business rules.
Decision Maker (Gemini 3 Pro): We utilized Gemini’s high-context reasoning for the classification and "Silent/Not Found" decisions. Its ability to follow complex, multi-step logic was optimized through parameter tuning to favor precision over creativity.
Specialist Assistant (OpenAI 5.2): Once a WISE number or SKU is identified, OpenAI's assistants act as the "Technical Librarian," reaching into the PIM (Product Information Management) master files to extract granular attributes like range, material, and weight.
Runtime & Vector Store: Nagent AI Runtime coupled with a highly structured Pinecone index allows for sub-second retrieval across millions of rows of industrial data.
The Knowledge architecture (Pinecone Metadata Schema)
Every product record (vector) in our store is enriched with a structured metadata payload. This allows the Gemini 3 Pro Decision Maker to apply hard filters before the vector similarity score is even calculated.
:quality(80))
The Retrieval Logic: Filters-First, Vectors-Second
When the Lead Orchestrator receives a query, it doesn't just ask Pinecone "what is similar?" It executes a two-step retrieval dance:
Phase A: The Anchor Retrieval
The system first searches for the normalized_mpn. If a match is found with a confidence score 85%, it extracts the spec_hash for that specific item.
Phase B: The Hash-Based Expansion
Once the anchor spec_hash is known, the system triggers a Deterministic Match Query:
Query: SELECT * FROM pinecone_index WHERE spec_hash == "A1B2C3D4"
Constraint: This query ignores the vector embedding entirely. If the hashes match, the items are binary-safe equivalents.
Testing for Production: Failure-Driven Iteration
We did not tune our prompts based on "almost right" answers. We tuned them based on Real Failure Cases:
Wrong Confidence: Did the system give a 70% confidence to a similarity match? (Fixed by enforcing caps).
Over-Helpfulness: Did the system suggest a fan when the user asked for a size that doesn't exist? (Fixed by enforcing "Expert Clarification" loops).
Leading Zero Blindness: We implemented a Mandatory Retry Protocol. If a search for SKU ID 07824 fails, the system autonomously retries as 7824.
Our test cases were written as Acceptance Criteria. A test only passed if the system returned the correct anchor SKU, the correct confidence level, and—crucially—remained silent when no valid match existed.
Strategic Outcomes: The Expert Persona
By the end of the implementation, the system no longer behaved like a chatbot. It behaved like a Senior Counter Professional:
It knows what it knows: (Authoritative Match).
It knows what it can suggest: (Spec-Equivalent Match).
It knows what it doesn't know: (Safe Silence).
Why This Matters to the Business
Prevents incorrect substitutions
Protects margin integrity
Reduces manual counter lookups
Increases trust in digital channels
Conclusion: The Difference Between a Demo and a System
For any industry managing complex catalogs, model choice is secondary to the Architecture of Restraint. By separating identification from discovery and treating "Silence" as a valid outcome, we have built a system that protects the supply chain.
Built with Nagent AI Agent Building Studio This solution was developed using Nagent AI's enterprise-exclusive Studio, which empowers domain experts to build, deploy, and govern complex multi-agent systems without writing code.
This architecture was built for organizations where a wrong match is more expensive than no match.
If you’re dealing with SKU fragmentation, catalog chaos, or “almost correct” AI systems in production, we’re open to architecture reviews and pilot discussions.
Talk to us if:
Your catalog spans multiple vendors and legacy systems
“Similar” results are breaking pricing or fulfillment
You need deterministic guarantees, not probabilistic guesses