A Fortune 500 global leader in data infrastructure, this company serves thousands of enterprises across cloud, hybrid, and on-prem environments. One of its fastest-growing products is a Storage-as-a-Service offering that lets enterprises consume storage on demand with usage-based billing.
The Engineering and Analytics team runs the platform, tracks customer consumption, and handles reporting across the org. More than 15 internal teams including product, engineering, customer success, finance, and legal come to this group whenever they need a clear picture of customer usage, billing, service behavior, or operational exceptions.
As the product scaled, that dependency became a bottleneck.
The problem
Customer data lived across multiple systems. Dashboards covered a narrow set of standard metrics. Anything beyond that meant analysts writing custom queries, stitching data manually, and validating results before anyone could act.
For each customer, teams needed answers to questions like:
How much storage was consumed this month vs. last?
Does usage look abnormal anywhere?
Is the invoice aligned with actual consumption?
Are there discrepancies across billing and usage systems?
A single customer-level analysis took 20 to 30 minutes, even for relatively simple questions. Requests queued up across finance, product, and operations. Decisions got delayed or made on incomplete information.
When the product was smaller, this was manageable. At scale, it wasn't.
First attempt: building an in-house conversational assistant on MCPs
The team first tried to solve this in-house.
They built an internal conversational assistant that let teams ask operational questions in natural language. The architecture followed a pattern common in enterprise AI: user queries routed through an agentic layer that invoked predefined MCP-style interfaces connected to backend systems and databases. Each MCP exposed a curated capability like retrieving account data, usage information, or operational records, which the language model then used to construct responses.
It was a reasonable starting point, but real questions rarely mapped cleanly to a single data source. Even simple requests required entity resolution, cross-database joins, and business rules that weren’t captured in any one system.
Because the assistant couldn’t access underlying data directly, it was constrained to whatever the MCPs exposed, broad endpoints that often returned a lot of irrelevant output. The model had to guess what mattered and how to proceed, without real grounding in the company’s operating logic.
In practice: inconsistent answers, frequent timeouts, and results teams couldn't rely on. Six months of engineering effort, roughly $30,000 a month to run, and real-world accuracy on business-critical questions sitting around 40%.
The team recognized the approach itself was the problem, not the execution. Read more on why MCPs fall short for enterprise data
Bringing in Genloop
Rather than expanding MCP coverage further, the team partnered with Genloop to rethink the foundation.
The goal wasn’t another dashboard or a chat interface layered on top of the same broken architecture. It was an analytics layer that could sit across all their data, understand how the business actually works, and operate with the confidence of an experienced analyst.
How Genloop was deployed:
Connected directly to all major data sources, structured and unstructured, with complete governance controls. No medallion ETL to unify all sources in one place.
A living context graph that assimilates the data, processes, decisions, and user context
Skills that let teams get ad hoc business questions solved in seconds
A dashboard that users could create themselves and use to schedule reports or presentations directly.
A system that evolves naturally with the business through a self-learning loop
Embedded as an iframe in their internal product
Instead of blindly selecting tools and wandering across interfaces, the system could now construct execution plans grounded in the organization’s operational logic. It queried downstream systems with confidence and applied process context during analysis.
For the team, the experience was simple: ask a question in plain English. Genloop handles the joins, the calculations, and the cross-system checks. The output is a clear, auditable answer. No ticket, no wait.
What changed
Metric | Before (Internal Build) | After Genloop |
|---|---|---|
Time per analysis | 20-30 minutes | Seconds |
Answer accuracy | ~40% | ~90-95% |
System failure rate | 84% | ~0.01% |
Monthly infrastructure cost | ~$30,000 | Significantly lower |
Engineering maintenance | High, growing | Minimal |
Data source coverage | Limited | All major systems |
Self-service access | Analyst dependent | Business users enabled |
"Genloop's ability to seamlessly join across multiple data sources has been invaluable. Our chatbots now return results with 95% accuracy."
Director of Engineering
What teams could actually do after deployment
Questions that previously required coordination across analytics teams could now be investigated directly by product managers, customer success, and operations stakeholders.
In day-to-day use, teams could:
Create customer-facing presentations from live data in seconds
Run investigative analysis through a simple chat without filing tickets
Get proactive anomaly alerts and trigger remediation without waiting for someone to notice
Support questions and variations from any business user without analyst involvement
Spot bottlenecks and resolve them without a backlog in between
Capability expanded naturally as the team exposed additional datasets and processes. The analyst team didn't have to rebuild anything. It just got broader.
Business impact
The numbers are one part of it. The bigger shift was in how teams actually worked.
Billing and invoicing cycles got faster. Finance and ops could verify usage, reconcile discrepancies, and move without waiting in a queue. Analyst bandwidth freed up and instead of fielding repeat requests, the team shifted focus to work that actually needed them. Decision confidence improved across product, finance, and operations because leaders finally had a consistent, transparent view of customer usage and revenue.
The conversation changed too. It went from "can someone pull this for me?" to "given what we're seeing, what do we do next?" That's the shift that actually matters.
What this signals for enterprise AI
This story is not unique. A lot of enterprise AI projects hit the same wall: they build on interfaces instead of building on data. The MCP approach feels architecturally clean until real questions start coming in, and then the gaps show up fast.
Reliable enterprise AI needs systems that understand operational structure, not just systems that can call APIs. The difference between a chatbot that sometimes works and an analyst you can depend on is whether the system actually knows how your business works.
This team got there by embedding reasoning directly within their data ecosystem. The result wasn't just faster answers. It was a more scalable, data-driven organization where insights are part of daily operations, not a request you make to a separate team.
