[Case Study] 60 AI Agents, One Industrial Knowledge Layer: How a Leading Steel Manufacturer Built Enterprise RAG

Industry: Steel, mining, and industrial operations
Client: Leading integrated steel manufacturer, identity withheld
Use case: Enterprise RAG, graph retrieval, on-premise small language models, and reusable agent infrastructure
Delivered scope: A governed retrieval layer connecting Google Drive, SAP, ERP, CRM, databases, and internal documents to an on-premise SLM and enterprise agents
Disclosure: The client has been anonymized. The delivered system scope and topline figures come from the Conscious Engines engagement record. The public evidence does not disclose the savings period, concurrent agent activity, or monthly active-user definition.

1. Outcome at a Glance

Conscious Engines built a shared enterprise intelligence layer for a large integrated steel manufacturer. Instead of giving every AI agent a separate set of connectors, indexes, permissions, prompts, and model APIs, the architecture placed governed retrieval and a private model layer underneath the portfolio.

The result was a reusable foundation for more than 60 internal agents, with a stated user base of roughly 2,000 employees and lower dependence on external model APIs.

The most important number is not the 60 agents. It is one shared knowledge layer beneath them. Every additional agent could reuse the same connectors, access policies, retrieval infrastructure, and private inference capacity. That changes the economics of enterprise AI from building isolated assistants to operating a platform.

The client's integrated operations span data-heavy workflows across production, maintenance, procurement, sales, logistics, finance, safety, and workforce management. At that scale, an answer about a purchase order, specification, breakdown, dispatch, or policy often depends on several systems and several permission domains.

2. Why a Steel Enterprise Needs More Than Document Search

The initial problem was fragmentation. Useful knowledge lived across Google Drive, internal documents, SAP, ERP, CRM, operational databases, and employee workflows. Each source contained only one part of the answer.

A general document chatbot could search PDFs, but it could not reliably answer the full class of industrial questions the manufacturer faced:

• Which maintenance procedure applies to this equipment model, and what does its recent work-order history show?
• Which customer enquiry matches available grades, dimensions, inventory, delivery windows, and approved commercial terms?
• Which supplier contract, purchase order, goods receipt, inspection result, and invoice belong to the same transaction?
• Which safety procedure applies to this plant, role, asset, and current permit condition?
• Which production plan is affected by a material delay, machine constraint, or dispatch exception?
• Which policy applies to this employee, location, grade, and effective date?

These are relationship questions as much as language questions. A relevant paragraph is useful, but the system also needs to understand that an asset belongs to a line, a work order refers to that asset, a manual applies to its model, a spare part comes from an approved vendor, and the requesting employee has access to some but not all of those records.

The cost of building every agent separately

Without a common layer, each new agent can create duplicated work:

1. build connectors to the same enterprise systems;
2. extract and normalize the same files and records;
3. create another vector index;
4. reproduce permissions in application code;
5. send large contexts to an external frontier model;
6. create a separate evaluation set and monitoring workflow;
7. become stale when a source schema, policy, or model changes.

This creates an N-agents by N-systems integration problem. A shared knowledge service reduces it toward one controlled integration per source and one reusable retrieval contract for every approved agent.

Why ordinary RAG was not enough

Vector retrieval is strong at semantic similarity. It can find a maintenance passage even when a user does not know the exact document title. It is weaker when the answer depends on explicit multi-step relationships, version rules, or structured identifiers.

Graph retrieval complements it. A graph can represent relationships such as:

plant -> production line -> asset -> work order -> failure code -> spare part -> supplier

or:

customer -> enquiry -> product grade -> specification -> inventory -> dispatch route -> contract term

The combination lets the system retrieve both what sounds relevant and what is operationally connected. The language model then explains the result using approved context. This distinction is central to building reliable RAG for industrial operations: the answer layer should not invent the relationships that the enterprise systems already know.

Why privacy and control mattered

Industrial knowledge includes commercial terms, employee information, customer data, internal policies, asset histories, process know-how, and security-sensitive records. Sending every query and every retrieved document to an external model can increase cost and governance exposure.

An on-premise SLM created a private inference path for recurring enterprise tasks. Supporting cloud infrastructure could still handle appropriate services, but the model and data path did not need to be identical for every request. This is a practical example of why one model is not an enterprise AI strategy.

3. What Conscious Engines Built

The delivered system can be understood as seven layers. The core design separated enterprise knowledge from any one user interface or foundation-model vendor.

The high-level flow was:

Drive + SAP + ERP + CRM + databases + documents

-> Conscious Engines ingestion and governance

-> vector index + enterprise knowledge graph

-> on-premise SLM and approved cloud services

-> enterprise agents

-> authorized employees

Vector and graph retrieval had different jobs

The vector layer answered questions like, "Where is the procedure that describes this failure pattern?" It translated the question and enterprise content into numerical representations, then ranked content by semantic relevance.

The graph layer answered questions like, "Which procedures, prior incidents, work orders, and suppliers are connected to this asset?" It traversed explicit relationships instead of relying only on similar wording.

Used together, they reduce two common failure modes:

• semantic miss: the user and the source use different terms for the same concept;
• relationship miss: the right records do not look linguistically similar but share a business entity, identifier, date, plant, contract, or asset.

Governance belonged inside retrieval

Enterprise RAG is safe only when retrieval respects the user's authorization before documents or records enter the model context. The correct pattern is:

identity -> role and attributes -> source permission -> retrieval filter -> model context -> cited response

The agent should receive only the evidence the user could access in the source system. Sensitive fields should be excluded or masked where required. Query, retrieval, model, citation, and user-feedback events should be logged for audit and evaluation.

This is why the system was an infrastructure project rather than a chatbot project. The valuable asset was the governed path from question to evidence. The interface could change without rebuilding the knowledge layer.

The on-premise SLM changed the cost curve

The engagement record attributes more than $15,000 in avoided external model or API spend to the hybrid architecture. The public evidence does not disclose the measurement period, baseline traffic, currency treatment, or included infrastructure costs, so the figure should be read as a reported saving rather than a normalized cost audit.

The economic mechanism is still clear. A smaller private model can process high-volume, bounded tasks such as query classification, intent routing, entity extraction, metadata generation, summarization, structured response generation, and simple question answering. A larger cloud model can remain available for low-volume tasks that need broader reasoning.

A production cost model should be reported as:

cost per accepted answer = total inference + retrieval + infrastructure + review cost / accepted answers

Token price alone is insufficient. A cheaper model that creates more reviews or more failed answers may cost more per outcome. The platform therefore needs a domain evaluation set, answer-quality thresholds, and a fallback policy, as described in the enterprise AI evaluation-set playbook.

4. Where the Architecture Creates Value Across Steel Operations

The delivered knowledge layer was designed for reuse. The specific next-step applications below are an expansion roadmap, not claims about completed Conscious Engines delivery. They show what the same retrieval, graph, SLM, speech, and agent infrastructure can support when connected to the appropriate systems and approved by the client.

These opportunities belong on a roadmap because they reuse the delivered foundation. Each one should enter production only after its own workflow definition, data-access review, evaluation set, human-approval policy, and KPI baseline are complete.

How to measure platform value

The business case should separate platform value from individual-agent value.

Platform value includes:

• external model and API spend avoided;
• duplicate connector and index work avoided;
• lower cost to launch the next agent;
• fewer access-control implementations to maintain;
• faster source refresh and policy updates;
• common observability and evaluation across agents.

Agent value includes:

• search and preparation time released;
• shorter resolution or approval cycles;
• fewer errors, exceptions, and escalations;
• higher equipment availability, throughput, or service levels;
• lower fuel, energy, freight, or working-capital cost.

A defensible value model is:

annual value = time released + operating loss avoided + external spend avoided + duplicate build cost avoided - annual platform cost

Every term should use an approved baseline and measured adoption. "Employees served" should not be converted into productivity value without active-user rate, task frequency, time saved per accepted answer, and a realistic realization factor.

The next evidence dashboard should therefore include monthly active users, queries per agent, accepted-answer rate, citation correctness, p50 and p95 latency, cost per accepted answer, fallback rate, external-model share, answer abstention, user overrides, source freshness, and incidents involving unauthorized retrieval.

5. What Manufacturing Leaders Should Take Away

This case illustrates a broader enterprise AI principle: the reusable system around the model is usually more strategic than the model itself.

First, enterprise knowledge should be built once and reused. Sixty isolated agents can become sixty integration and governance liabilities. A shared retrieval layer turns them into consumers of common infrastructure.

Second, structured and unstructured data must meet. Documents explain policies, procedures, and context. SAP, ERP, CRM, and databases hold the current operational state. Vector and graph retrieval connect both forms of evidence.

Third, private SLMs are strongest when the task boundary is clear. They do not need to know everything. They need to perform the enterprise's frequent tasks at the required quality, latency, privacy, and cost. Frontier models can remain escalation tools rather than the default runtime for every call. The strategic and financial rationale is developed further in the bespoke enterprise AI business case.

Fourth, access control is part of model quality. An accurate answer assembled from evidence the user should not see is a failed answer. Identity, permissions, retrieval, citations, and audit logs belong to one design.

Fifth, a platform should be judged on marginal deployment economics. The key question is not only whether agent number one worked. It is whether agents 10, 30, and 60 became faster and cheaper to launch because the enterprise had already built the common layer.

Production evidence standard

The strongest proof for a system like this is a measured user journey. For example: an engineer asks a maintenance question, the system retrieves the correct manual section and related SAP history, the answer cites both sources, and the interaction reduces the time to a verified next action. One measured workflow is more persuasive than a long list of theoretical capabilities.

Conscious Engines builds private, task-specific AI systems around enterprise data, permissions, workflows, and economics. For industrial companies, that can include enterprise RAG, knowledge graphs, on-premise SLMs, speech systems, voice agents, optimization models, and the evaluation layer that decides when each model is safe to use.

The goal is not to put the largest model behind every employee. It is to create one governed intelligence layer that makes every approved model and agent more useful.

Related Conscious Engines research

• The AI-native factory is more than computer vision
• The factory floor data problem and voice AI
• The on-premise ACG Capsules factory copilot
• Why one model is not an AI strategy
• Why an enterprise evaluation set becomes an AI moat
• The bespoke enterprise AI business case

Sources and evidence boundaries

• Conscious Engines engagement record. It is the source for the delivered architecture and the 60+, approximately 2,000, and $15,000+ figures. The client's identity is intentionally withheld, and normalized measurement definitions are not publicly disclosed.