In the last post, I introduced the idea that the current market conversation about AI-powered analytics is missing a layer. The data layer, the semantic layer, and the protocol layer are all getting serious attention. Gartner is publishing predictions about them. Vendors are building products around them. LinkedIn is full of thoughtful posts about semantic layers and MCP adoption and context engineering.
But above all that infrastructure sits something the discourse has not yet named clearly: the inquiry layer. This is where humans meet intelligence. It is where the entire investment either produces genuine insight or generates expensive noise.
The response to that argument has been interesting. When people hear “the human side matters,” they reach for one of two familiar ideas. The first is prompt engineering: teach people to write better queries and the AI will return better answers. The second is conversational analytics: give people a natural language interface to their data and the interaction will take care of itself.
Both are real. Neither of them is the inquiry layer. And the difference is not subtle. It is the difference between operating a tool and thinking with a partner.
One Question, Three Approaches
The best way I can show this distinction is to put all three approaches against the same business problem and let the differences speak for themselves.
The scenario is simple. A CFO opens his laptop on Monday morning. The company has been making less profit on every sale for two straight quarters, and the trend is accelerating. The board wants to understand why. He has access to financial data, operational data, and customer data across multiple source systems, all connected through governed MCP servers with a mature semantic layer in place. The infrastructure is solid.
What happens next depends entirely on how he engages with it.
Approach One: Prompt Engineering
The CFO has conducted a prompt engineering workshop. He knows that specificity matters, that he should define the scope of his question, and that he should tell the AI what format he wants the answer in.
He types: “Analyze gross margin by product line for Q3 and Q4 2025 compared to the same quarters in 2024. Break the results into a table showing revenue, COGS, and margin percentage for each product line. Highlight any product line where margin declined by more than 200 basis points.”
The AI returns a well-structured table. The numbers are accurate. Two product lines show significant profit decline. The output is clean, specific, and exactly what he asked for.
He refines: “For the two product lines with the largest margin decline, break down COGS into materials, labor, and overhead components and show which component drove the increase.”
Another clean table. Materials costs are up significantly in both product lines.
He asks one more question: “What percentage of materials cost increase is attributable to the top five suppliers for those product lines?”
A clear answer comes back. Three suppliers account for most of the increase.
He has his answer. He closes the laptop. He knows which suppliers are driving costs up and can take that to the board.
This is prompt engineering working well. Each query was specific, well-scoped, and produced accurate results. The AI performed exactly as asked.
But notice what happened. Or more precisely, what did not happen.
The CFO asked three excellent questions and got three excellent answers. Each question was independent. Each was essentially a report request delivered through natural language instead of a BI tool. The AI did not carry context forward in any meaningful analytical sense. It retrieved and formatted. The CFO directed every step based on what he already suspected. He confirmed a hypothesis. He did not discover anything.
The suppliers were the obvious suspect. He went looking for them and found them. The question is whether that is the full story, or whether it is the story that was easiest to reach.
Approach Two: Conversational Analytics
The CFO uses a vendor platform marketed as conversational analytics. The interface looks like a chat window. He types a natural question and gets a visual response.
“Why are our margins declining?”
The platform returns a dashboard-style view: a margin trend line, a breakdown by product line, and a highlight showing which segments dropped the most. It is visually polished. He can click on elements to drill further.
He clicks on the product line with the steepest decline. The platform shows a waterfall chart of cost components. Materials are up. He clicks on materials. A supplier breakdown appears. He clicks on the top supplier. A table shows pricing trends over four quarters.
He has arrived at the same place as the prompt engineering approach, possibly faster. The interface is intuitive. The visuals are clear.
But the experience was fundamentally guided. The platform decided what to show first. It chose the visualization types. It determined the drill path. When he clicked on materials, it showed suppliers because that was the pre-configured drill hierarchy. The platform’s designers had anticipated this sequence of questions and built the navigation accordingly.
This is the old BI model wearing a conversational costume. The interface accepts natural language, but the interaction underneath is still structured around pre-built analytical paths. The CFO followed a path someone else designed. He did not follow his own thread of inquiry.
And he arrived at the same conclusion: suppliers are the problem. Which may be true. But the analytical frame was never his to direct.
Approach Three: The Inquiry Layer
The CFO sits down with the same data, the same semantic layer, and the same MCP connections. But he approaches interaction differently.
“Show me gross margin by product line, trailing eight quarters.”
The AI returns the trend. Two product lines are compressing. But something else catches his eye. A third product line, one that is not declining, has unusual volatility. It swings quarter to quarter in a way the others do not.
“That third product line, the one bouncing around. What is driving the volatility? Break it into revenue and cost components separately.”
The AI separates the two. Revenue is stable. Costs are oscillating. Specifically, labor costs spike in Q1 and Q3 and drop in Q2 and Q4.
“Is that a seasonal pattern? Pull in headcount data for that product line by quarter.”
Headcount is flat. The labor cost swings are not driven by hiring and firing. Something else is happening.
“Break labor costs into regular and overtime for that product line.”
Overtime spikes align perfectly with the cost spikes. Q1 and Q3 have massive overtime. Q2 and Q4 have almost none.
“What happens in Q1 and Q3 operationally that drives overtime? Is there a production cycle or a demand pattern I should look at?”
The AI pulls in order volume data. Order volume is consistent across quarters. But fulfillment lead times spike in Q1 and Q3. The same number of orders is being processed, but they are taking longer to fulfill, which drives overtime.
“Why would lead times spike if volume is flat? Pull in the supplier delivery data for components going into that product line.”
Two key component suppliers have inconsistent delivery schedules. They deliver late in Q1 and Q3, which pushes production into compressed windows, which requires overtime to meet commitments.
Now the CFO has something genuinely different. The two product lines with obvious profit declines have a supplier cost story, yes. But the third product line, the one nobody flagged because its margins were not declining on average, has a hidden operational fragility. Its margins look stable only because of the overtime costs and the non-overtime quarters average out. But the overtime quarters are eroding profitability, and the root cause is the same supplier reliability issue manifesting in a completely different way.
He never would have found this through prompt engineering, because he was not looking for it. He never would have found it through conversational analytics, because no one designed a drill path that connects margin volatility to overtime patterns to supplier delivery schedules. He found it because he noticed something unexpected, named it, followed it across data sources, and let the thread lead him somewhere he did not anticipate.
That is the inquiry layer at work.
What Made the Difference
The three approaches used the same data, the same semantic definitions, the same infrastructure. The difference was not technical. It was cognitive.
In the prompt engineering approach, the CFO optimized his inputs. He asked precise, well-formed questions and received precise, well-formed answers. But precision is not the same as discovery. Every question he asked was shaped by what he already believed. The AI confirmed his hypothesis efficiently. It did not challenge it.
In the conversational analytics approach, the platform guided the exploration. The visualizations were helpful and the drill paths were logical. But they were someone else’s logic. The analytical frame was embedded in the product, not directed by the person using it. The CFO followed a path. He did not blaze one.
In the inquiry layer approach, the CFO did something neither of the other approaches enabled. He noticed an anomaly he was not looking for. He named it. He followed it across multiple data sources. He let the context build over a sequence of exchanges that no one could have anticipated or pre-built. The AI carried the analytical frame forward, maintained context, and navigated across sources. But the direction came from him. The judgment about what mattered came from him. The decision to pursue the volatile product line instead of the obviously declining ones came from him.
The inquiry layer is not about asking better questions. It is about sustaining a directed thread of analytical thinking through a medium that can keep up with you.
What the Inquiry Layer Actually Requires
If it is not prompt engineering and it is not a platform feature, what is it?
It is the ability to hold a question open. Most business interactions with data are designed to close questions as quickly as possible. But strategic insight does not come from closing questions. It comes from holding them open long enough for unexpected patterns to emerge. The CFO in the third scenario did not close the question when he got the obvious answer. He held it open. He noticed something peripheral. He followed it.
It is the ability to read what the AI is actually doing. An inquiry-capable user does not just read the answer. They consider what sources were queried, what assumptions were made, what was included and excluded. This is not distrust. It is the same discipline any experienced analyst applies when reviewing someone else’s work.
It is the ability to shift analytical frames mid-conversation. The CFO started with a profitability frame. Midway through, he shifted to an operational efficiency frame without losing the connection to the original question. That shift requires recognizing when the current frame has delivered what it can and a new perspective is needed.
It is the ability to synthesize across the conversation. After eight or ten exchanges, the most valuable step is to pause and ask what the findings mean as a whole. The AI can help connect the pieces, but the human must judge whether the conclusion makes sense in a business context.
None of this can be installed or purchased. It develops the way any complex cognitive skill develops through repeated practice with real problems. Organizations that take the inquiry layer seriously will need to create space for that practice, accepting that the first twenty conversations will be mediocre and that the skill compounds over time. The people who become most capable at this will not necessarily be the most technical people in the room. They will be the people who understand the business most deeply and who have the instinct to follow a thread wherever it leads.
What Comes Next
The profit scenario revealed something worth sitting with. The most valuable insight came not from analyzing a declining metric but from noticing that a stable metric was hiding volatility underneath. The analytical frame shifted from “what is going wrong” to “what looks right but is actually fragile.”
That kind of frame shift, seeing the same data differently by changing the dimensional lens through which you examine it, is not just a useful technique. It points toward something deeper about the relationship between how we structure data and how we think with it. The dimensions we use to analyze our businesses, product lines, customer segments, time periods, cost categories, are not natural features of reality. They are choices. And when the intelligence layer can navigate between dimensional frames fluidly, the rigidity of those choices starts to become visible in ways it never was before.
That is territory worth exploring. And it is where this series goes next.
This is part of an ongoing series exploring how AI and conversational interfaces are reshaping data architecture and business intelligence. Previous posts are available at insightsindata.com.
© 2026 Paul Nevill / Insights in Data
