ChatGPT
Claude
Part 2 of 2 — A proof-of-concept architecture and engineering walkthrough
From “What happened?” to “What should I investigate next?” with governed semantic analytics, Cortex Agent, Cortex Analyst, Cortex Search, and Streamlit.
Manufacturing analytics · Cortex Agent · Cortex Analyst · Cortex Search · Streamlit
Introduction
In Part 1, we built the foundation: governed data, a semantic layer that defines every metric exactly once, three read-only analytical capabilities, and a Streamlit dashboard created in just three prompts. That dashboard answers “what happened?” reliably — but the moment someone asks “why?”, it hands the problem back to the human. This second part picks up from there. We keep the dashboard and the governed layer exactly as they are, and add an agentic layer on top: a Cortex Agent that decides which governed tool to call, Cortex Search that grounds recommendations in plain-language procedures, and a conversational Streamlit interface that answers in FACT, ANALYSIS, and INVESTIGATE NEXT. Then we walk through a worked example — why did downtime increase for machine 1000LS? — and the governance that keeps the whole system honest. A quick note on what is live and what is modeled: all data is synthetic, the dashboard screens come from the real build, and the agent response, interface mock-up and configuration snippets are representative.
Why a KPI Dashboard Is Not Always Enough
A dashboard is a reporting surface. It aggregates governed metrics and renders them as cards, trends, and bar charts. That is exactly what it should do, and the POC’s Streamlit application still does it — production, downtime, OQA compliance, and loss events all render as KPI cards with supporting charts. The limitation is not accuracy, it is depth: a dashboard shows the current state of a metric, but the moment someone asks “why,” the dashboard hands the problem back to the human.
On a manufacturing floor, that handoff is expensive. An engineer who notices that downtime on a machine has climbed has to open a filter panel, isolate the machine and date range, cross-reference loss codes, check which shift was running, and look at which operators logged the most time — all before forming a hypothesis worth escalating. Every one of those steps is a separate query against the same governed data, run manually, in sequence, by a person.
The POC’s premise is that a well-scoped agent can run that same sequence of governed queries automatically, and hand the engineer a synthesized starting point instead of a blank filter panel.
From “What Happened?” to “What Should I Investigate Next?”
The central idea in this POC is a three-way distinction that shows up in every agent response:
| Category | Definition |
|---|---|
| FACT | A metric returned directly from a governed analytical tool — for example, total downtime minutes for a machine over a date range. |
| ANALYSIS | A pattern observed across multiple FACTs — for example, that a disproportionate share of downtime falls in one shift or one loss code. |
| INVESTIGATE NEXT | A recommended next analytical step for a human — not a conclusion, a direction. |
The distinction matters because it is the difference between a system that reports patterns and one that quietly claims to have found root cause. This POC does not claim causality. When downtime is concentrated around one operator, the agent is instructed to describe that operator as accounting for “a larger share of the observed downtime,” never as the cause of it. That phrasing shows up throughout the sample response in this article, and it is a deliberate constraint on the agent, not an oversight.
Architecture
The architecture separates concerns into six layers: raw data, a governed data layer, a semantic layer, three governed analytical tools plus a search capability, an orchestration layer (Cortex Agent), and a presentation layer (Streamlit). Figure 1 shows the full flow from the manufacturing engineer’s question down to the underlying governed tables, and back up again.
Figure 1. End-to-end architecture of the manufacturing intelligence copilot.
Two design decisions carry the rest of the article:
- The agent decides which governed tool to call. It does not decide what a metric means — that decision was made once, upstream, in the semantic layer.
- The semantic layer is the single place where “downtime,” “attainment,” and “OQA compliance” are defined. Every tool, and therefore every agent response, inherits that definition rather than reconstructing it.
Cortex Search: Grounding, Not Metrics
The loss code glossary is exposed through Cortex Search rather than Cortex Analyst, and that distinction is deliberate. Cortex Search is not queried for numbers — it is queried for plain-language explanations of a loss code or a maintenance procedure, and it is only invoked after a numeric pattern has already been established by the Downtime or Production Analyst. In the demo scenario later in this article, Cortex Search is what turns “Tool Change accounts for a large share of downtime” into “here is the tool change procedure reference,” without ever being asked to produce a downtime total itself.
Adding Agentic Orchestration
Cortex Agent is not the data model, and it is not a fourth analytical tool. It is the orchestration layer sitting above the three governed tools and the search capability. Its job is to read the user’s natural-language question, decide which governed tool (or tools) the question calls for, issue the calls, and assemble the results into a structured response.
| Question Type | Tool Selected |
|---|---|
| Production output, trend, attainment, yield, scrap | Production Analyst |
| Downtime, loss codes, loss reasons, shift or operator concentration | Downtime Analyst |
| OQA compliance, missing inspections | Quality Analyst |
| Procedure or terminology lookup | Loss Code Glossary (Cortex Search) |
# Representative Cortex Agent tool configuration
tools:
- name: production_analyst
type: cortex_analyst
semantic_view: MFG_INTELLIGENCE.SEMANTIC.PRODUCTION_ANALYST
- name: downtime_analyst
type: cortex_analyst
semantic_view: MFG_INTELLIGENCE.SEMANTIC.DOWNTIME_ANALYST
- name: quality_analyst
type: cortex_analyst
semantic_view: MFG_INTELLIGENCE.SEMANTIC.QUALITY_ANALYST
- name: loss_code_glossary
type: cortex_search
service: MFG_INTELLIGENCE.SEMANTIC.LOSS_CODE_GLOSSARY_SEARCHThis configuration shape reflects how the POC registers each governed capability as a tool the agent can select — treat this as a reference pattern rather than a guaranteed-stable API contract.
Why not let an LLM generate unrestricted SQL against the raw manufacturing tables instead? Two reasons carry the most weight in this POC. First, unrestricted SQL generation means the metric definition is re-derived on every question, with no guarantee that “total downtime” means the same thing this time as it did last time. Second, it removes the access boundary that a semantic view provides — a semantic view can expose exactly the dimensions and facts a role is allowed to see, while an LLM writing raw SQL has no equivalent restriction baked in. The agent-over-governed-tools pattern keeps both of those guarantees intact.
How the Investigation Workflow Works
For a comparison-style question — “why did downtime increase” — the agent does not jump straight to an explanation. It works through an ordered sequence: identify the machine, establish the current and comparison periods, query the primary metric for both periods, determine whether it changed, break the change down by loss code, examine shift and operator concentration, check production context if relevant, and only then synthesize the evidence into FACT, ANALYSIS, and INVESTIGATE NEXT sections. Figure 2 shows that sequence end to end.
Figure 2. Cortex Agent orchestration flow for a period-comparison question.
This is the structural reason the copilot is more useful than a single text-to-SQL query: a single query can return one number, but it cannot decide on its own that the number is worth decomposing by shift and operator, or that a procedure lookup would help. The ordered workflow is what turns one fact into a synthesized, actionable response.
Building the Streamlit Manufacturing Copilot
Streamlit is intentionally the presentation layer, not the intelligence layer. The application renders machine, date range, and shift filters; a previous-period comparison; nine KPI cards grouped by domain (production, downtime, and quality), each with a change-versus-prior indicator; a production alert; trend and breakdown charts by loss code, shift, and operator; and a chat-style “Ask the Manufacturing Copilot” panel. Figure 3 shows the conceptual layout — modeled on the POC’s actual Snowflake Streamlit screens, which display the same filter panel, KPI cards, and downtime-by-operator/shift charts shown in this article’s source screenshots.
Figure 3. Illustrative Streamlit manufacturing analytics interface, modeled on the POC’s dashboard and copilot panel.
# Representative Streamlit -> Cortex Agent call
import streamlit as st
question = st.text_input(
"Ask about downtime, operators, loss booking..."
)
if question:
response = call_cortex_agent(
question=question,
machine_filter=selected_machine,
date_range=selected_date_range,
)
render_investigation_result(response)Streamlit’s role is to collect the filters and the question, pass them to the agent, and render the structured response — it does not compute any metric itself.
Everything the reasoning does happens before this render step. Streamlit’s only job afterward is to lay the response out under the ANSWER / KEY METRICS / EVIDENCE / ANALYSIS / INVESTIGATE NEXT headings.
Designing Evidence-First Responses
Every number the agent surfaces must originate from a tool result, not from the model’s own estimate. That constraint is what makes the FACT / ANALYSIS / INVESTIGATE NEXT structure enforceable rather than aspirational: FACT lines are copied from a tool response, ANALYSIS lines describe a pattern across more than one FACT, and INVESTIGATE NEXT lines are always phrased as a next step, never as a conclusion.
A Walkthrough: Why Did Downtime Increase?
The demo scenario asks the copilot a single question: “Why did downtime increase for 1000LS during the last 30 days?” To make this scenario meaningful, the POC’s synthetic data generator intentionally engineers a signal around machine 1000LS: downtime is materially higher in the recent period, Tool Change and Machine Idle are meaningful contributors, the pattern concentrates in Shift 2, and operator ZOEY M logs a disproportionately large share of the observed downtime. This is synthetic demonstration data, engineered specifically to give the architecture something worth investigating — it does not describe a real production facility.
This pattern is visible directly in the POC’s own Streamlit output: the downtime-by-operator chart shows ZOEY M with the tallest bar of any operator, and a Production Alert panel flags “machine idle for 960 minutes” with ZOEY M called out as the operator with the highest recorded downtime on the filtered machine set.
The agent works through this question using the ordered workflow described earlier, and returns a structured response. Figure 4 shows that response in the same ANSWER / KEY METRICS / EVIDENCE / ANALYSIS / INVESTIGATE NEXT layout the Streamlit copilot renders.
Figure 4. Evidence-first investigation response for the 1000LS downtime question.
A Note on the Numbers in Figure 4
The current-period and previous-period downtime figures shown here are illustrative, built to be directionally consistent with the POC’s own KPI card (1,440 minutes of total downtime) and its “machine idle for 960 minutes” alert. The supplied POC artifacts did not include an explicit current-vs-previous downtime comparison pair, so these two figures should be read as a representative pairing rather than a verified export from the running application. The operator and shift concentration — ZOEY M recording the highest downtime, and the pattern concentrating around Shift 2 — does match the POC’s own dashboard output.
FACT vs Analysis vs Investigate Next
It is worth restating this model on its own, because it is the single design principle that keeps the copilot from overstating what it knows.
| Layer | What It Is | What It Is Not |
|---|---|---|
| FACT | A number returned directly by a governed tool. | An estimate or an inference. |
| ANALYSIS | A pattern observed across two or more FACTs — concentration, coincidence, a larger share. | A causal claim. |
| INVESTIGATE NEXT | A recommended next analytical step for a human. | A conclusion or a directive. |
Concretely, the agent is never allowed to say an operator “caused” a downtime increase. It is instructed to say the operator “accounted for a larger share of the observed downtime,” or that a shift “coincides with” the pattern. That is a narrower claim, and it is the correct one given what the underlying data can actually establish.
Governance and Safety
Governance in this POC is not a single control — it is a property of the architecture, enforced at each layer rather than checked once at the end. Figure 5 shows the same layered flow from Figure 1, annotated with the specific governance property each layer is responsible for.
Figure 5. Governance responsibilities mapped to each architectural layer.
- Semantic governance — business metrics are defined once, in governed semantic views, not reconstructed by the LLM on every question.
- Tool boundaries — the agent can only call the specific analytical capabilities it has been configured with; it has no general query access.
- Read-only analytical behavior — none of the three analyst tools can modify data. The POC does not require, and does not implement, any write path.
- Evidence-first responses — every number in a response must trace back to a tool result.
- Fact vs interpretation — observed facts and analytical interpretation are kept in visibly separate sections of every response.
- No unsupported causality — the agent is constrained to correlation language, never causal language, unless the underlying data can actually support a causal claim (which this POC’s data cannot).
- Scope boundaries — a question outside the three governed domains is expected to be declined rather than answered speculatively.
- Production isolation — this POC runs in an isolated environment against synthetic data, entirely separate from any production system.
Dashboard vs Agentic Analytics
Figure 6 puts the two workflows side by side. The traditional path ends at “manual investigation” — the dashboard has done its job, and the human takes over from there. The agentic path does not skip the human; it moves the human’s decision point later, after evidence has already been assembled and a first hypothesis has already been narrowed down.
Figure 6. Traditional KPI dashboard workflow compared with the agentic investigation workflow.
It is worth being precise about what changed and what did not. The governed data and the governed metric definitions are identical in both paths — nothing about the underlying semantic layer changes when the agent is introduced. What changes is how many of the investigative steps a human has to perform manually before reaching a decision point.
Technical Implementation Notes
A few implementation details are worth calling out explicitly, since they affect how the architecture should be read:
- Cortex Agent, Cortex Analyst, and Cortex Search configurations shown in this article are representative of the POC’s implementation pattern. Where an exact configuration syntax is still evolving, it should be treated as a reference artifact rather than a guaranteed-stable API contract.
- The Streamlit application queries the governed semantic layer for its own KPI cards and charts — it does not need the agent for the baseline dashboard view, only for the conversational investigation panel.
- All demo data is synthetic, generated specifically to produce a legible signal around machine 1000LS for this walkthrough.
Production Considerations
Moving this pattern from POC to a production manufacturing environment would require strengthening several areas that this proof-of-concept intentionally left out of scope:
| Area | What Production Would Require |
|---|---|
| Authentication and RBAC | Real identity federation and role-scoped access to each semantic view, not a single POC role. |
| Data masking | Column-level masking for any operator- or personnel-identifying fields. |
| Observability | Tracing of every agent tool call, not just the final response. |
| Auditability | A durable log of every question asked and every tool result returned. |
| Cost controls | Query and token budgets per user or per workspace. |
| Workload isolation | Separate warehouses for the copilot workload versus other analytical workloads. |
| Data quality | Automated checks on the governed layer, upstream of the semantic views. |
| Testing | Regression tests on semantic view definitions and agent tool routing. |
| Failure handling | Defined behavior when a tool call times out or a semantic view is unavailable. |
| Monitoring | Alerting on agent error rates and latency, separate from data-quality monitoring. |
Future Architecture
Several extensions are natural next steps, but none of them are implemented in this POC — they are listed here as future work, not as capabilities already present:
- Richer Cortex Search content — expanding the glossary beyond loss codes into full maintenance procedures.
- Anomaly detection — proactively flagging a downtime pattern instead of waiting for a question.
- Predictive analytics — forecasting downtime risk rather than only explaining historical patterns.
- Automated alerts — routing a synthesized investigation result to the right team without a manual question.
- Agent observability — dedicated tracing and evaluation tooling for agent tool-selection accuracy.
- Maintenance and SAP context — joining downtime investigation with work-order and maintenance history data.
- Deeper production-quality integration — replacing synthetic data with a governed connection to live manufacturing systems.
MCP as a Future Extension
This article deliberately does not make the Model Context Protocol (MCP) a central topic, because it is not part of what this POC implements. The current progression is Streamlit → Cortex Agent → governed analytics, all inside one Snowflake-native application. A natural future direction would extend that progression one step further — exposing the Manufacturing Copilot itself as an MCP-accessible capability, so that an external enterprise agent could call into the same governed analytical tools this article describes. That extension is conceptual. It is not built, tested, or implemented in this POC, and a future article would be the right place to explore it in depth.
Key Takeaways
- A governed semantic layer is what makes agentic analytics safe to build — the agent should decide which tool to call, never what a metric means.
- Separating FACT from ANALYSIS from INVESTIGATE NEXT is a structural constraint, not a formatting choice; it is what keeps correlation from being presented as causation.
- Cortex Search belongs in an investigative workflow as a context and procedure lookup, not as a source of metrics.
- An ordered investigation workflow — scope, compare, break down, synthesize — produces a more useful response than a single text-to-SQL query, because it decides what is worth decomposing further.
- Agentic analytics accelerates the investigation process; it does not replace the human decision at the end of it.
Conclusion
Technically, the pattern comes down to a clean separation of responsibilities. Governed tables hold the data, semantic views define what each metric means, Cortex Analyst turns questions into queries against those views, Cortex Search supplies procedural context, and Cortex Agent decides only which tool to call and in what order. Because the agent never writes SQL against raw tables, a metric like total downtime resolves to the same definition on every question, and access is bounded by what each semantic view exposes. Read-only tools keep the blast radius limited to analysis.
The same discipline shapes the output. An ordered workflow — scope, compare, break down, synthesize — does more than a single text-to-SQL call, and a response contract that traces every number to a tool result keeps FACT, ANALYSIS, and INVESTIGATE NEXT separate. The work that remains is the engineering around the agent: tracing every tool call, regression-testing semantic views and tool routing, role-scoped access and column masking, and cost and latency budgets. Get those right and the agent becomes a dependable interface to governed analytics rather than a shortcut around it.
