We built an enterprise data agent—and you can too

Here's a scenario that plays out daily at most enterprises: someone needs a number. Maybe that number is the performance of a field marketing campaign, maybe it’s a regional sales figure, or maybe it’s expenses broken down by cost center. A dashboard can at best answer the initial question. But sometimes you need to take a deeper dive into multiple data sources to get truly actionable information, or need to break down your query by a dimension that the dashboard was not previously designed for. 

While questions queue up for the analyst or the dashboard developer, organizations pay the opportunity costs: decisions are made more slowly, and actions are delayed.

The Data and AI team wanted something different for Red Hat. We built Dataverse Agent, Red Hat's internal data agent that lets employees ask questions about our data in their own natural language and get trusted, auditable answers in seconds.

The data foundation

Like many businesses, Red Hat had data locked in source systems and legacy warehouses, databases, and spreadsheets. Before we even started to build the data agent, we implemented a data platform, called Dataverse internally, with the following principles:

• Data product ownership: Each major data domain has a defined owner responsible for quality and documentation. The guidance files aren't written by a central team—they're maintained by the people who know the data best.
• Reduced duplication: Consolidating redundant data sources meant the agent has fewer places to look and less conflicting information to reconcile. Aligning on source-aligned and aggregate data products allows humans and agents alike to deterministically use the correct source of truth.

You can learn more about how we cleaned up our data to prepare for our AI journey in a recent blog post from Red Hat CIO Marco Bill and CTO Chris Wright, “Our journey to AI-centricity, part 1: Building on a stable foundation.”

Our enterprise data agent represented the opportunity to build on these prior transformations to drive more business value. In this blog post, we’ll discuss what we built, see some new problems we encountered along the way, and explain why we decided to open source foundational AI templates so you can build something similar.

Agent challenges

Dataverse solved many existing problems and solidified our data foundation. It was necessary, but alone it was not enough. Building a user-friendly agentic platform introduced a new set of challenges.

Trust: The accuracy problem

As we all know by now, an AI agent can return an incorrect answer with complete confidence. There's no hesitation, no "I'm not sure about this." Credibility is easily lost when a wrong number ends up in a presentation—or, worse, when it drives an automated action. Agents need to explain themselves like a human analyst would, and that includes providing sources and reasoning.

Adoption: The usability problem

Nontechnical users often find it easier to message a colleague than to figure out how to phrase a question for an AI tool. If using an agent requires prompt engineering—or, worse, configuring a Model Context Protocol (MCP) connection in a developer tool like Cursor—most people will never get past the first step. We built a browser-based interface so users can just open a tab and ask. The agent needed to meet users where they are, not demand they learn new tools.

Context: The institutional knowledge problem

When we first rolled out the Dataverse Agent, it could read our schema, but it didn't know how to translate "last quarter's results" to "annual contract value" or "ACV." It didn’t know that the phrase "active customers" could mean different things depending on the product being discussed. Answers that are technically correct but business incorrect are still wrong, and arguably worse than no answer at all. We needed to provide the agent with context-rich guidance to codify how a domain expert would use the data.

Accountability: The ownership problem

When an AI agent suggests a course of action that doesn't work out, who's responsible—the user, the data product owner, or the AI team? Ambiguity makes users cautious, and to maximize value, the agent needs to be trusted for both high- and low-stakes queries. We needed clear lines: the data product owner creates the product guidance and performs user acceptance testing on common questions; the AI team creates an agent that provides information and explains its reasoning; and users make the ultimate decisions and own the outcomes that arise in their specific use case.

How we built it

The challenges we discussed in the previous section aren’t hypothetical, and a lot of enterprise AI projects don’t properly answer them and then stall after the pilot phase. Our architecture was designed to address them all.

The core approach

The transformations Red Hat made to its data foundation resulted in source-aligned and aggregate data products ready for AI to build on.

We built a guidance architecture (Figure 1) that functions as a data product skill—a set of structured documentation that teaches the AI tool what our data actually means in business terms. The Dataverse Agent walks along the guidance architecture and across the source and aggregate products in the data warehouse.

The guidance architecture

Let's walk through what happens when a sales leader asks, "What was last quarter's North America annual contract value (ACV)?" This is where the guidance architecture enables the agent to make use of usage and query construction knowledge developed by domain experts. The agent first consults the routing guidance to map "ACV" to the right data product. Then it uses the product documentation and a large language model (LLM) to translate "last quarter’s ACV" into the correct Structured Query Language (SQL) definition, filter the query by geography, and return the result.

Figure 1. Guidance architecture

When a user asks a question, the agent uses an LLM at multiple points in this sequence. It's not guessing based on database column names—it has explicit documentation about what each table means and how it should be used.

The query pipeline

Every query follows a 4-step workflow:

identify_dataproducts → shortlist_tables → get_sql → execute_sql

1. Identify data products: Based on the question, determine which data domain is relevant
2. Shortlist tables: Within that domain, identify the specific tables needed
3. Generate SQL: Write the query using the schema and business rules from the guidance
4. Execute and return: Run the query and present results with explanation

You can see where this query pipeline fits into the overall Dataverse Agent architecture in Figure 2.

Figure 2. Dataverse Agent architecture

Each step is logged. Users can see why the agent chose a particular table or how it interpreted their question. This addresses the trust problem directly—the reasoning is visible, not hidden.

The agent integration layer

The Dataverse Agent uses MCP as the standardized interface between the agent and our data. This matters because it makes the architecture composable. You can swap components, add new data products, or integrate with different systems without rebuilding everything.

Built on Red Hat OpenShift

We run the entire architecture on Red Hat OpenShift. Keeping the agent and MCP on the same platform as our data estate means we reuse the security and compliance we’ve already built in, keep compute in-house, and scale agentic workloads without standing up a parallel AI stack. It’s Red Hat on Red Hat—we drink our own champagne. 

Access control by design

A common concern with AI agents is access control: who can query what? We avoided this problem by design. The agent authenticates through Red Hat’s existing single sign-on (SSO) technology, and inherits the user's data platform permissions. If you are not provisioned for a data product, the agent cannot access it for you. There are no new permission systems, no shadow IT, and no compliance gaps. The governance processes we already trust are the same ones the agent uses.

Agent behavioral guidelines

In addition to the enterprise data agent workflow, we defined a set of behavioral rules for the agent that shape how it communicates:

• Clarify before executing: If a question is ambiguous, ask a clarifying follow-up question rather than guessing.
• Explain your reasoning: In every answer, include a plain-English explanation of what any proposed SQL query is doing and why.
• Suggest next questions: Guide users toward useful follow-ups rather than leaving them guessing at what to do next.
• Translate the schema: Use business terminology in responses, not database column names or other technical terminology.

Advanced agent features

Along the journey towards deployment to a production environment, we discovered opportunities to strengthen the enterprise data agent.

Scale

Scale matters as we grow 2 dimensions: users and content. It’s especially important that the agent can handle thousands of concurrent users without degradation, so we designed templates for horizontal scaling.

On the content side, we need enough data products available for the agent to be broadly useful. Early in the journey, we took a labor-intensive approach: asking data product owners to provide the domain expertise that populates the 3-layer guidance architecture. This works, but it doesn't scale to hundreds of data products with hundreds of tables each.  

We have moved towards an automated intake and maintenance process that is more scalable. This process analyzes historical query patterns from business analysts who have previously interacted with tables via direct SQL statements—which columns they filter on, which joins they make, and which aggregations they request. This past usage data helps us infer the guidance the agent will need when users start asking questions in natural language instead. The goal is to generate draft guidance automatically, then have data product owners review and refine rather than author from scratch.

Memory layer

Early in our journey, if a user told the enterprise data agent, "When I ask about revenue, I always mean North America," that context did not persist beyond that session. We’ve recently built quality-of-life features that allow more customized and efficient use:

• Persistent memory: Context that follows users across sessions
• Project folders: Memory scoped to specific initiatives or analyses
• Rules: Behavioral preferences that users can select from or define themselves 

Deep agent capabilities

Version 2 of the Dataverse Agent will move to an AI skills-based architecture, where capabilities exist as modular, discoverable documents the agent can read and reason about on demand. In practical terms, this means routing guidance and per-product data context each become independently maintained skills that are decoupled from the agent's core prompt and called by subagents. The promise of this approach is a leaner, faster agentic experience for our users.

Business wins

We have 40 official data products available in the enterprise data agent's user interface, supporting approximately 1,000 unique agent users and about 70 daily active users. More than half of our users successfully activate (which we define as making 3 or more successful queries in their first week using the agent), and we use product-led growth strategies to track usage across data products to understand how we can drive adoption from different functions within the organization.

We've seen Red Hatters use the data agent for real work. Here's a small sample of asks from the last 30 days, summarized straight from our observability platform: 

• Cost-center spend against forecast 
• Product pipeline by region
• Account and subscription deltas 
• Bookings and co-sell signals for strategic accounts 
• Greenfield opportunity structure
• Partner renewal health
• Purchase-requisition status checks
• Org hierarchy
• Headcount across functions 

All of these were answered without a ticket, a join, or a schema hunt in between.

The open source templates

We didn't build this agent to keep it internal to Red Hat. If you’re interested in building your own AI agent, you can benefit from the lessons we learned rather than starting from scratch. We have open sourced several AI templates that you can adopt and use as a starting point, and made them available. Check out these AI templates at aitemplates.io. These templates include enterprise features for deployment in modern container environments.

• template-agent: A production-ready AI agent framework. Includes the guidance architecture, the query pipeline and the behavioral configuration. Enterprise features including SSO integration and observability are built in.
• template-mcp-server: The MCP integration layer for connecting agents to data sources. This includes enterprise features like deploying on Kubernetes, and Red Hat OpenShift native and asynchronous interfaces using FastAPI.
• template-ui: The UI template is a production-ready chat interface for template-agent Deep Agents. It provides a React chat UI with a Fastify backend-for-frontend that proxies the Deep Agent LangGraph streaming API.

These templates are designed to get you to a working system in days rather than months. Fork them, adapt them to your environment, and, if you improve something, consider contributing back.

The repositories are available on GitHub:

• Explore the template Agent here
• Explore the template MCP here
• Explore the template UI here

In August 2026, the AI Templates moved to a deep agent architecture. Dataverse Agent will adopt those updates in the next release (Version 2).

If you're building something similar to the Dataverse Agent, start with the templates, try them in your environment, and tell us what breaks. If you improve something, consider contributing back. That's how we all get better, the open source way.