An analytics agent reports 120,000 new users. The operating dashboard says 108,000. Both can show their SQL, and both claim to use current data. The problem is larger than one wrong answer: do the agent and the existing data products share the same assets, semantics, identity, and controls?
That question makes DataBuddy’s architecture more interesting than its three visible roles—data engineering, analytics, and governance agents. Underneath them, the product connects ingestion, lakehouse storage, catalog, unified semantics, and AI-ready data knowledge into a shared chain. An Agent Harness ties that chain to context, tools, security, and evaluation.
The core architectural bet is clear: make the data platform understandable, operable, and governable by agents before asking agents to do production work.
Reading the architecture in two directions
Read the diagram vertically first. Heterogeneous sources enter a lakehouse and asset-management system, pass through catalog and semantics, become AI-ready knowledge, and are consumed by agents or dashboards.
Then read it horizontally. The Agent Harness provides context, memory, skills, tools, security, and evaluation across the task. The governance agent connects standards, quality, metadata, lineage, and policy across the data lifecycle. The upper section is business delivery, the middle is the capability platform, and the bottom contains engines and storage. They are different responsibilities in the same request, not independent product stacks.
The data chain: accessible is not yet understandable
Enterprise data arrives from databases, messages, files, logs, and business applications. Moving it into a lakehouse solves access, but an agent still needs to know how tables relate, what a field means, which metric definition is approved, whether an asset is fresh, and whether the current user may access it.
DataBuddy’s architecture draws these concerns as one continuous chain: multimodal ingestion, asset management, unified semantics, AI-ready data knowledge, and delivery through agents and BI. The order matters.
For data work, AI-ready should mean more than embedding documents. It needs at least four kinds of objects:
- structural knowledge: tables, fields, partitions, lineage, quality, and freshness;
- business knowledge: metrics, dimensions, entities, relationships, synonyms, and scope;
- execution knowledge: trusted queries, tool parameters, workflows, and failure handling;
- governance knowledge: ownership, permissions, sensitivity, intended use, and audit rules.
Unless those objects can be retrieved, cited, and used to constrain execution, the agent is still guessing from schema names.
Catalog and semantics: one business language for agents and BI
The architecture places TC Catalog at the center of the data assets and exposes Unity Semantics to both agents and dashboards. That design directly addresses the opening conflict. If conversational analysis invents a temporary definition while BI uses a governed metric, greater agent flexibility simply creates more versions of the truth.
Shared semantics do not require every analysis to be prebuilt. A useful division of labor is to let the semantic layer provide stable metric, entity, join, and policy boundaries while the agent chooses investigative steps inside them. When exploratory work falls outside the governed layer, its temporary assumptions should be visible rather than presented as an organizational standard.
In a product evaluation, “How many sources do you support?” is less revealing than three change tests: Does editing a metric affect both the agent and the dashboard? Can one entity retain identity across systems? Can a historical report state which semantic version it used?
Agent Harness: the runtime around the model
Tencent Cloud’s current description of Buddy presents it as a unified AI entry point across the platform, with page capabilities packaged as callable Skills. The Harness in the architecture is the runtime that connects those skills to context, memory, tools, security, and evaluation.
Consider a request to diagnose a fall in new-user conversion:
- Buddy receives the current page, user identity, and business-domain context.
- Catalog and semantics supply the approved metric, relevant assets, and trusted joins.
- The planner breaks the task into reproduction, segmentation, funnel diagnosis, and anomaly checks.
- An analytics skill invokes query and Python tools within the user’s effective permissions.
- Verification checks whether segments reconcile to the total and whether the source data is current.
- The result is delivered with traceable evidence and can be explored further or turned into a dashboard.
Remove any step and familiar failures return: the wrong metric, unauthorized detail, an expensive query, stale data explained as a business change, or a conclusion nobody can reproduce. A Harness is valuable because it manages the state, contracts, and controls needed over repeated tasks—not because it wraps one model call.
Why the three agents should share a foundation
Engineering, analytics, and governance may appear as separate product experiences, but the underlying work is tightly coupled.
An analytics agent may detect a field anomaly that should become a quality rule, after which an engineering agent repairs the pipeline. A model produced by the engineering agent must enter catalog and semantics before an analytics agent can reuse it safely. A governance agent that cannot see real query and task context will struggle to prioritize quality work.
The shared foundation should let one task create governed assets that the next task can consume. Whether that loop actually closes is more important than the number of isolated features each agent can demonstrate.
Security claims need adversarial tasks
The official architecture describes identity-bound execution, input and output guardrails, and controls for high-risk SQL. These are sensible design goals, but a document claim is not the same as an observed control.
A pilot should deliberately create conflicts: ask an unauthorized user to drill into sensitive records, follow an aggregate answer with a request for raw detail, trigger a large scan, and switch data domains within one session. Observe whether the system blocks the task during planning, rejects it at the tool boundary, or filters only after execution. The trace should retain the identity, policy decision, SQL, approval, and final output.
For consequential SQL, a confirmation dialog is not enough. An approver needs the affected objects, estimated scope and cost, and a recovery path to make an informed decision.
A POC that resembles production
Because the product capability documentation evolves, a useful POC should be organized around durable business tasks rather than a feature-menu checklist.
| Test | Task design | Pass condition |
|---|---|---|
| Semantic consistency | Calculate one metric through the agent and dashboard, then revise its definition | Both surfaces use the same version; historical results remain traceable |
| Cross-role loop | Detect an anomaly, create a governance rule, and repair the pipeline | Context and assets move across roles without manual copying |
| Permissions and risk | Attempt unauthorized drill-downs, sensitive fields, broad scans, and high-risk SQL | Identity reaches the tool; blocking and approval leave an audit trail |
| Recoverability | Inject stale data, a schema change, and a tool timeout | The system locates the failure, stops the false conclusion, and proposes recovery |
The final review should compare the architecture with the current delivery state. Planned, preview, and generally available capabilities should not be treated as interchangeable. The decisive question is not whether the demo appears omniscient. It is whether engineering, analytics, and governance can work from the same semantics, identity, and evidence. That is what determines whether a Data Agent can move from presentation to production.