Turn enterprise data into decisions with AI agents and Snowflake

Big companies around the world regularly ask their transformation team to take on a big job: Find a way for employees to ask a question about data — regardless of where it physically lives — and get back the right answer to that question. Often, this task means accounting for a tremendous amount of data spread throughout multiple corners of a business' vast operations.

DXC Technology excels at just this kind of data challenge, and we recently worked with a manufacturing client to build a platform that is anchored entirely on Snowflake as the central data repository. Now it is possible for every employee, from a shop-floor technician to an operations director, to simply ask a question about data — regardless of its physical location — and get an answer that is accurate, secure and scoped to exactly what that person is allowed to see.

In this article, I’m going to walk you through how the platform was built, from the data foundation all the way up to a layer of AI agents that talk to one another, and show how our solution can be tailored to fit other companies experiencing the same challenges.

Data from the shop floor arrives at the Snowflake central data repository through the HighByte DataOps platform and Ignition for enabling SCADA/IIoT platforms to directly access and manage cloud-based data lakes. This data includes sensor readings, line parameters, machine events and more. Instead of dozens of local databases and factory-level silos, there is now a single, consistent entry point for operational data from every site in the world, ready for further processing and distribution.

Of course, raw shop-floor data says very little on its own — it has to be cleaned, standardized and connected to business context. That transformation runs on dbt (data build tool), which creates a classic medallion architecture. The bronze layer keeps data exactly as it arrived from source, the silver layer cleans and standardizes it and the gold layer delivers ready-to-use, aggregated business models — the same models that later underpin the semantic views AI agents will query. Because the pipeline is built in dbt, every transformation is version-controlled, testable and repeatable, rather than a pile of hand-written, hard-to-maintain SQL.

Figure 1 illustrates a high-level view of how the Snowflake architecture operates. A master agent reaches domain agents through a Snowflake-managed MCP server. Each domain agent is armed with Cortex Search and Cortex Analyst, and structured data includes SAP data products delivered via the SAP Business Data Cloud (BDC) Connector. Some agents reach beyond Cortex Analyst and Cortex Search. A Utilities agent, for instance, can be wired to a custom tool implemented as a Snowflake stored procedure — such as sending an email alert or a summary directly from a conversation — which shows that the tool layer is extensible well past search and analytics whenever a particular domain calls for it.

The price of admission for scaling across factories

Governance determines whether a platform like this can safely serve dozens of locations at once. Every factory has its own dedicated database, into which only that factory's IoT data flows — in practice, the database naming convention encodes the specific site and environment (sandbox, dev and production are kept separate), so one factory's data never physically mixes with another's. Access to those databases and their objects is restricted to authorized employees only: for every factory and every environment there are distinct roles, separating, for instance, a “contributor” who can create and modify objects from a “reader” who can only query data and talk to agents. That structure means a misconfiguration in one plant cannot accidentally open a door into another plant's data; this is governance designed for global scale, not for a single site.

On top of that governed data foundation sit domain agents, which are specialized AI assistants, each responsible for a specific area of the business. For example, a Maintenance agent helps technicians document repairs and trace root causes, an Operations/Production agent answers questions about output and line performance, a Quality agent works over quality notifications and non-conformances, and a Costs agent lets people analyze spend at the level of cost centers and activity prices. Each of these agents runs locally for its own factory, drawing only on the data that plant, and the specific user asking the question, is authorized to see. The governance model described above translates directly into what an agent can “see” and talk about.

For agents to actually answer questions rather than just receive them, specific tools are attached depending on the nature of the data. For structured data — tables, metrics, the business-level semantic views built in the gold layer — the agents use Cortex Analyst, which translates a natural-language question into a SQL query and returns a precise, countable answer. For unstructured data — documents, instructions, protocols — Cortex Search searches content semantically and returns the most relevant passages along with their source. The same agent can therefore reach, in a single conversation, for both hard numbers from a database and a paragraph from an operating procedure.

The structured data that Cortex Analyst works with is not limited to shop-floor IoT telemetry; it also includes SAP data, exposed as ready-made data products through the SAP Business Data Cloud Connector. The integration runs in a zero-copy model: SAP exposes its tables in Iceberg format through a REST Catalog, and Snowflake reads them directly from the source storage, without physically copying the data at connection time. On that basis, a set of core data products has been built covering machine downtime, production orders, warehouse movements, product master data, quality notifications, activity types and work centers. That’s hundreds of millions of rows of SAP operational data available natively inside Snowflake. Crucially, the integration works both ways: enriched or analyzed data can be published back to SAP as a new data product, closing the loop between the transactional system and the analytics-and-agent layer.

Alongside system data there is a second, equally important stream, which is knowledge captured in documents scattered across each site's SharePoint libraries. To make that knowledge available to the agents, an integration was built on Snowflake Openflow: dedicated runtimes connect to specific SharePoint sites and index it in a Cortex Search service. As a result, a domain agent asked about the procedure for a specific type of failure can reach directly into the text of an operating instruction, with no human having to manually dig through drives and libraries.

The whole architecture — data, transformations, governance, agents and tools — is held together by one simple rule: the user should never need to know where the data lives or how it is processed. They just ask a question in natural language through Snowflake CoWork — installed directly on their mobile, or via browser on their laptop, and the right domain agent — armed with Cortex Analyst and Cortex Search — finds the answer, all while respecting the permissions of the person who is logged in.

A single domain agent at a single factory is one floor of this architecture. One level up, each factory has its own leadership agent — an orchestrator that sits above that site's domain agents and can answer a question spanning multiple agents without the person asking needing to know which specialist actually holds the answer. Higher still, for users with broader authority — that is, power users who need visibility beyond a single factory — a global agent sits above every factory's leadership agent, deciding on the fly which one to route a question to and combining results from more than one factory into a single coherent answer.

The catch is that, at the time this was built, Snowflake did not yet offer a native agent-to-agent mechanism. Rather than wait, the team engineered its own approach: at every tier, the agent above talks to the agents below it through a Model Context Protocol (MCP) server managed directly by Snowflake, where each subordinate agent is exposed as a separate, described tool. A leadership agent's MCP server exposes that factory's domain agents; the global agent's MCP server exposes every factory's leadership agent in turn. Each orchestrating agent, which is itself a Cortex agent, receives routing instructions; for example, “route maintenance questions to the maintenance agent, production questions to the operations agent, and if a question spans both, use both and combine the answers”. It makes that decision automatically, within a single conversation with the user.

Crucially, this orchestration layer never bypasses the governance model described earlier. When an agent calls a subordinate agent through an MCP server, that subordinate executes under the permissions of the person who asked the original question, not under some shared service identity. Someone holding only reader rights at one factory can use that factory's leadership agent and, through it, its domain agents, but they cannot reach another factory's agents unless separately granted access there, and. A global agent is itself only usable by someone explicitly granted a global role. Multi-agent orchestration is layered on top of role-based access control (RBAC), not routed around it.

The effect of this design shows up clearly in how an actual question moves through the system. A plant director might ask, in one sentence, something that would once have taken one or more phone calls to each site to answer: compare a performance metric between Location1 and Location2 this month, and flag any recurring maintenance issues. The global agent recognizes that this spans two factories and two domains, and calls both factories' leadership agents in parallel. Each leadership agent, in turn, decomposes its share of the question: the operations domain agent pulls the metric from its semantic view, while the maintenance domain agent searches its site's indexed documentation for recurring patterns. The two leadership agents return their partial answers to the global agent, which merges them into one coherent response delivered as a single natural-language answer, in the time it used to take just to get the right two people on a call.

What worked and what to watch for

A few choices paid off more than expected. Consuming SAP data zero-copy through the BDC connector turned what would normally be a multi-week ETL effort into something closer to hours, since there was no pipeline to build and no copy to keep in sync. Openflow's SharePoint connector delivered a fully managed, change-aware ingestion pipeline for documents without a line of custom ingestion code. And because the governance model was designed up front rather than bolted on afterward, extending RBAC to the AI layer required no separate access-control system of its own — an agent simply inherits the same boundaries as the data it is built on.

The design also came with trade-offs. Agent-to-agent orchestration through MCP servers is not free: each hop is a full agent invocation, so a deeply nested question takes longer to answer than a single-agent one, and token budgets have to be watched to avoid timeouts on long chains. SAP data arrives read-only, so any question that needs to join it with non-SAP data still requires a materialized copy rather than a live join. And Openflow's SharePoint connector does not notice a folder being renamed or moved — that still triggers a full re-ingestion rather than an incremental update. These trade-offs shaped where the team chose to invest engineering effort and where it didn't.

The resulting platform shows that a modern data and AI architecture for a global manufacturing organization does not have to trade flexibility for security. The key building blocks are:

• Full integration with SAP through the SAP BDC Connector, running zero-copy and in both directions
• Integration with SharePoint content through Snowflake Openflow, which turns unstructured procedural knowledge into something AI can search
• An agent-to-agent collaboration mechanism
• Above all, a governance model built on RBAC in which every factory, every environment and every user has exactly as much access to data as they actually need. It is that last principle that turns scaling from one factory to a dozen from a risk into a natural next step

By combining trusted enterprise data with AI agents, organizations can move beyond dashboards to intelligent, action-oriented decision-making. With platforms such as Snowflake Cortex Analyst and Cortex Search, businesses can scale expertise, accelerate outcomes, and unlock the full value of their data while maintaining governance and control. Contact us to learn how DXC can help you get started.