The analytics team at one of our enterprise clients was well-run: senior people, a modern data warehouse, good tooling. The problem was volume. Product managers, marketing leads, and CX analysts all had questions that needed someone who understood the data model. The queue never cleared, and decisions regularly waited two or three days for answers that should have taken minutes.
This situation is more common than organisations tend to admit. Significant investment goes into BI infrastructure and the dashboards that sit on top of it, and business teams then discover that dashboards are built around the questions someone anticipated, not the ones that come up week to week. The infrastructure looks capable from a distance and proves frustrating up close.
We had been running proof-of-concept analytics work with this client using a third-party agentic platform. The technology performed well enough in controlled conditions: natural language queries converted to SQL, results returned accurately, visualisations rendered cleanly. The demo was convincing. What emerged during the move toward production was a set of constraints that the platform could not resolve.
What the third-party platform couldn't do
The vendor controlled the interaction model, which meant any adjustment to how conversations flowed, how results were presented, or how the admin experience worked required raising a ticket against a roadmap the client had no influence over. In a proof-of-concept context that is a manageable limitation. In a production deployment where business users have well-formed opinions about their workflows, it becomes a serious problem. The product cannot adapt quickly enough to what users actually need.
The same constraint affected iteration speed more broadly. Tuning agent behaviour, refining evaluation logic, and adjusting how the system handled ambiguous queries all required vendor involvement. The feedback loop between real user behaviour and product improvement was too slow to build confidence.
The client's legal and security teams introduced a third concern about long-term data control. Questions about log ownership, data residency, and what leaves the environment under various conditions did not have clean answers, even with in-VPC deployment. For an organisation operating in a regulated sector, those questions matter regardless of how well the vendor's current security posture is rated.
Third-party platforms are well suited to demonstrating capability. They are less well suited to the kind of iterative, persona-specific tuning that enterprise business users require in production.
Starting from personas
We built cours to address these constraints directly. Rather than beginning with architecture, we started with the business personas who would be using the system: product managers, marketing analysts, and CX leads across several teams. For each group we mapped their top recurring analytical questions, traced how those questions connected to actual decisions, and documented the vocabulary they used naturally when discussing data. Agent configuration came after that groundwork was done.
The practical impact of this approach is significant. A Product Manager asking about cohort performance is using shorthand for a specific combination of metrics, comparison periods, and segmentation logic that her team has developed over time. An agent configured around that context interprets the question correctly. One built around a generic data model often does not, and users learn quickly not to trust it.
Before any users touched the live system, we also built ground truth datasets: real question and answer pairs developed with the business teams and used to evaluate agent accuracy from the outset. A large proportion of conversational analytics deployments skip this step and discover quality problems only after launch, at which point rebuilding trust with users is slow and uncertain.
What changed
The most immediate change was the time from question to answer. Queries that had previously waited in the analytics queue for two or three days were resolved in under a minute. Product managers stopped filing requests for recurring analyses and began exploring data directly, without needing to involve the analytics team for straightforward questions.
Over several weeks, the character of the questions themselves shifted. When access to data is frictionless, people use it more exploratively. Teams that had been asking descriptive questions about what happened in a given period began asking causal and forward-looking ones: why a particular metric moved, what the leading indicators suggested about the next quarter. That kind of analytical behaviour is what BI investments are generally intended to produce, and it rarely emerges from dashboard access alone.
Governance requirements were met throughout. Because cours is deployed inside the client's AWS environment with role-based access controls, each persona sees only the data relevant to their function. The compliance constraints the security team specified were addressed at the infrastructure layer rather than through policy documents and user training.
What we learned
Structured memory is foundational to a useful conversational analytics system. Without it, each query is stateless: the system cannot build on prior context, cannot adapt to how a particular user thinks about their domain, and does not improve over time. With layered memory covering persistent facts about the user, long-term preferences about how they want data presented, and session-level context, the system becomes progressively more useful the more it is used.
In-cloud deployment has moved from a differentiator to a baseline expectation among enterprise buyers. The clients who pushed hardest on data residency were raising legitimate concerns, and building to answer those concerns clearly removes a category of friction from commercial conversations that would otherwise slow or block deployment.
Discovery work cannot be compressed. The persona research, ground truth development, and mapping of questions to decisions all created the impression of slowing the project down. In practice, they were the reason the production deployment worked well. Engagements that skip this phase tend to ship faster and spend longer fixing accuracy problems that erode user confidence before the system has had a chance to prove its value.
Cours is now the platform we use for enterprise analytics engagements. Each deployment runs on the same AWS-native architecture and the same discovery playbook, configured for the client's specific data sources and business context. We are working with a small number of beta clients across enterprise and mid-market segments. If the situation described here is recognisable, we are open to a conversation.