As enterprises race to deploy AI agents, many are discovering that the model is only part of the equation. The harder challenge is the data underneath: fragmented across warehouses, lakehouses, operational databases, logs, and SaaS applications, and often lacking the business context an agent needs to investigate a problem rather than simply answer a question. The distinction matters. Where a traditional BI copilot helps users query existing analytics infrastructure, a data analytics agent can independently form hypotheses, run queries, validate findings, and carry out an end-to-end investigation toward a business objective.
In this VMblog Q&A, Weimo Liu, co-founder and CEO at PuppyGraph, shares his perspective on what it takes to bring that vision to life. He discusses whether enterprises can build a “self-service Palantir,” why Text-to-SQL alone falls short for relationship-heavy investigations, and what AMD’s decision to open-source its OPTIMA Data Intelligence Platform signals about the importance of the data layer. Liu also outlines a practical path from idea to production, explains why agent development is an ongoing process rather than a one-time project, and details the architectural requirements, including enforced permissions, traceability, and guardrails, that make AI-generated results trustworthy and auditable.
++
VMblog: What’s the difference between a data analytics agent and a traditional data or BI copilot?
Weimo Liu: A BI copilot typically helps users interact with existing analytics infrastructure. It can generate SQL, create dashboards, explain metrics, and answer questions based on predefined datasets or semantic models.
A data analytics agent goes a step further. Instead of simply answering an individual question, it can independently investigate a business problem through multiple steps. It can formulate hypotheses, identify relevant data sources, execute queries, explore relationships, validate findings, and synthesize conclusions.
For example, a BI copilot might answer, “How did revenue change last quarter?” An analytics agent could investigate, “Why did revenue decline in a particular region?” It might correlate customer churn, product availability, supplier delays, pricing changes, and operational incidents across multiple systems.
The fundamental difference is the level of autonomy and investigative capability. A copilot assists with individual analytical tasks; an agent can carry out an end-to-end investigation toward a business objective. In practice, the two can coexist, with a copilot serving as the user interface for more capable agents.
VMblog: Can enterprises build a “self-service Palantir” with AI agents?
Liu: Palantir has demonstrated the value of connecting enterprise data through an ontology: a shared representation of business entities, relationships, and operational processes.
Historically, building this kind of system has required significant engineering resources, domain expertise, and customized application development. This has made it difficult and expensive for many organizations to replicate.
AI agents could fundamentally change this equation.
An agent can help discover data relationships, generate ontology mappings, translate business questions into executable queries, and build analytical workflows. Business users can interact with the resulting system using natural language rather than learning complex query languages or navigating dozens of dashboards.
However, the key is not simply putting an LLM on top of a data lake. Enterprises still need a reliable data foundation, explicit business semantics, governed access controls, and a query engine capable of executing complex analytical tasks.
The opportunity is to make the capabilities traditionally associated with sophisticated enterprise intelligence platforms much more accessible, without requiring every organization to build a large centralized engineering team.
VMblog: How does an enterprise take a data analytics agent from an idea to production?
Liu: Moving an enterprise analytics agent into production requires more than connecting an LLM to a database. It is an engineering process that involves several layers.
First, identify a concrete business problem with measurable outcomes. Start with a specific workflow, such as fraud investigation, cybersecurity threat analysis, supply chain intelligence, or IT operations.
Second, connect the relevant enterprise data sources. These might include data warehouses, lakehouses, operational databases, logs, and SaaS applications.
Third, establish a semantic layer or ontology that describes business entities and their relationships. This gives the agent a reliable understanding of what the data represents and how different datasets connect.
Fourth, provide the agent with appropriate query and execution tools. It needs to retrieve data, perform multi-step analysis, and follow relationships across systems.
Fifth, implement enterprise governance, including authentication, authorization, data-level permissions, audit logging, and restrictions on what the agent can execute.
Finally, establish evaluation and monitoring processes. Test the agent against representative business questions, verify its results, track query performance and costs, and monitor its behavior in production.
A successful deployment usually starts with one well-defined use case and expands as the organization builds confidence in the underlying infrastructure.
VMblog: What can enterprises learn from AMD’s decision to open-source OPTIMA, its Data Intelligence Platform?
Liu: One important lesson from AMD’s OPTIMA initiative is that enterprise AI agents need more than powerful models and GPUs. They need a well-organized data foundation that provides business context.
Enterprise information is often fragmented across IT systems, operational databases, financial applications, security platforms, and data lakes. An agent operating on isolated data sources may answer individual questions, but it will struggle to understand broader relationships across the organization.
AMD’s Data Intelligence Platform addresses this challenge by connecting diverse enterprise data into a contextual intelligence layer that supports analytics and agent-driven workflows.
Its decision to make OPTIMA available as an open, modular reference architecture is also significant. Rather than prescribing one fixed technology stack, it gives organizations flexibility to adopt and replace components based on their existing infrastructure.
I believe this reflects an important direction for enterprise AI: the competitive advantage will increasingly come from how effectively organizations structure, connect, and govern their data, rather than simply which foundation model they choose.
The broader lesson is that the data layer should be designed as a foundational part of the agent architecture, not treated as an afterthought.
VMblog: How do you design a data engine for AI agents rather than for human users?
Liu: Traditional analytical systems are largely designed around human interaction. They help users explore dashboards, write SQL queries, generate reports, and visualize results.
AI agents have different requirements. They need a reliable data execution layer that can support complex investigations autonomously and repeatedly.
For an agent, several capabilities become particularly important:
- Structured interfaces: Agents need well-defined query APIs and tools rather than relying exclusively on natural-language interfaces.
- Explicit relationships: They need to understand how entities connect across potentially thousands of tables.
- Efficient execution: They must be able to execute complex queries and multi-hop traversals with predictable performance.
- Data freshness: They should work against current enterprise data without introducing unnecessary data duplication or synchronization delays.
- Governance: Every query must respect the identity and permissions of the user or agent making the request.
- Traceability: Results should be explainable and auditable, including the underlying queries and data sources.
This is the architectural philosophy behind PuppyGraph. We focus on providing a graph query engine over existing enterprise data, allowing agents to navigate relationships across distributed data sources without first moving everything into a separate graph database.
The objective is to make the data infrastructure a dependable execution engine for agents, rather than just another interface for people to interact with.
VMblog: How long does it take to put an enterprise data analytics agent into production? Is it a one-time project or an ongoing process?
Liu: The timeline depends heavily on the use case, data readiness, security requirements, and the number of systems involved.
A focused proof of concept can often be built relatively quickly. A data platform team can launch an initial agent within a few weeks, demonstrate its value through a real business use case, and use those results to secure additional resources and budget for broader deployment.
However, turning that initial success into a reliable, enterprise-wide solution requires considerably more work, including data integration, semantic modeling, access control, evaluation, and production monitoring.
More importantly, building an enterprise agent is not a one-time deployment.
The first version may address a relatively narrow business problem using a limited set of data sources. Over time, organizations can expand the agent’s capabilities by connecting additional systems, introducing new business relationships, refining the ontology, and incorporating feedback from users.
The business environment also changes continuously. New data sources appear, schemas evolve, business rules change, and new analytical questions emerge.
Therefore, I believe enterprises should approach agent development as an incremental process. The goal is not to build one perfect agent that answers every possible question, but to establish a governed data and execution foundation that allows agents to evolve continuously.
VMblog: Why isn’t Text-to-SQL sufficient for enterprise data analytics agents? When does graph technology become important?
Liu: Text-to-SQL is a significant step forward because it allows users to query structured data using natural language. It works particularly well for questions involving known tables, straightforward joins, and aggregations.
However, enterprise investigations are not always simple SQL-generation problems.
Consider a cybersecurity investigation that needs to connect user identities, devices, network events, software vulnerabilities, historical incidents, and organizational relationships. The relevant information may be distributed across hundreds or thousands of tables.
The challenge is not just generating SQL. It is discovering which relationships matter and following them across multiple steps.
With Text-to-SQL, the agent must repeatedly infer table relationships, choose joins, and reconstruct business semantics. As the schema becomes larger and more complex, this can become increasingly difficult.
Graph technology provides a different abstraction. It makes entities and their relationships explicit, allowing an agent to navigate connections and perform multi-hop investigations more naturally.
This does not mean SQL becomes obsolete. SQL remains excellent for many analytical workloads, particularly aggregations and structured reporting. Graph and SQL can complement each other.
The important question is which abstraction best represents the problem being investigated. For relationship-heavy analytics, graph can give agents a much more natural way to reason about enterprise data.
VMblog: How can enterprises make AI-generated analytical results trustworthy and auditable?
Liu: Trust is one of the biggest barriers to deploying autonomous agents in enterprise environments.
An agent may generate a convincing answer, but enterprises need to know whether the underlying analysis is correct, whether the agent accessed authorized data, and how it reached its conclusion.
There are several important architectural requirements.
First, permissions must be enforced by the data infrastructure, not simply by instructions in an LLM prompt. Agents should operate under properly authenticated identities and respect existing access-control policies.
Second, analytical operations should be traceable. Organizations should be able to inspect the queries executed, the sources accessed, and the intermediate results used to reach a conclusion.
Third, the agent needs guardrails. Query validation, restricted execution capabilities, approval requirements for sensitive operations, and appropriate tool permissions can prevent unintended actions.
Finally, organizations need systematic evaluation. They should test agents against known business questions, expected results, edge cases, and changing data conditions.
Ultimately, trustworthy enterprise agents require a combination of AI capabilities and traditional data engineering principles. Governance, correctness, and auditability must be built into the architecture from the beginning rather than added after deployment.
##
