Marina Tosic, writing on Towards Data Science, defines a data agent in one line: a report you can talk to. Her article is about the one in Microsoft Fabric, and the pipeline behind that line is concrete. The agent reads the schemas of the sources you attach, decides which one likely holds the answer, writes SQL, DAX or KQL, validates the query, runs it under the asker’s own credentials, and replies with text or a table. I like the definition, but the part I keep returning to is what it assumes. The hard part was never the report. It was the modelled, governed data underneath, and that still has to be built by hand before any agent can sit on top of it.
What a data agent does
Fabric’s version sits on top of OneLake sources: a lakehouse, a warehouse, a Power BI semantic model, a KQL database, an ontology. It runs on the Azure OpenAI Assistant API, and Microsoft Learn describes the same steps Tosic lists: pick the source based on the question and the schema, generate the query, validate, execute, answer. You teach it by selecting tables, writing instructions, and adding example queries, and the setup is iterative rather than one-shot.
The distinction the article ends on is the one worth keeping: an AI agent acts, while a data agent grounds. Grounding means fetching numbers you can defend. Acting means changing something, like drafting the email or issuing the refund. In Fabric you can mount it as a knowledge source inside a bigger agent, so the thing writing the email pulls its revenue figures from the thing whose only job is revenue figures. That split is what I’d carry over to store work, and with agent surfaces arriving in WooCommerce via MCP, it matters now.
Your store data probably isn’t ready for it
A data agent reads schema and instructions. On a normal WooCommerce store, the schema for orders is the posts table plus an unbounded pile of meta rows, and the business definition of revenue lives nowhere consistent. Does revenue include pending orders? Are refunds subtracted? Refunds are at least their own records, shop_order_refund. Which currency wins in a multi-currency setup? Fabric’s answer to all this is the governed data estate, tables designed around the questions people ask. For a store, the equivalent is a curated reporting layer with the definitions written down, and no amount of prompt engineering substitutes for it.
Some of that layer already ships. HPOS, the default for new stores since WooCommerce 8.2, moved orders into dedicated tables (wc_orders, wc_order_addresses, wc_order_operational_data, wc_orders_meta) with real columns and indexes instead of postmeta joins. That is a far better surface to ground a query against. But it’s still a live transactional store rather than a semantic model. There is no net revenue column anywhere. Net revenue is a decision, and in Fabric that decision ends up in the agent’s instructions and example queries. So the modelling work didn’t vanish along with the dashboards. It moved from chart definitions into instructions, and somebody still has to write those carefully.
Where I’d draw the line
The split worth stealing is the risk boundary. Grounding is read-only and answerable; acting writes data. When you wire an AI assistant to a store, don’t give it one big toolbox. Put a narrow, read-only grounding endpoint in front of the curated layer, and keep acting tools like creating a coupon or updating an order behind their own capability checks. Fabric executes queries under the stakeholder’s credentials, so a person who can’t see a segment doesn’t get it in an answer. The WordPress equivalent is a permission callback, and it’s the step I see skipped most often on custom endpoints.
<?php
// Grounding endpoint: one curated source, one capability, fixed metrics.
add_action( 'rest_api_init', function () {
register_rest_route( 'bbioon/v1', '/insights', array(
'methods' => 'POST',
'permission_callback' => fn () => current_user_can( 'view_woocommerce_reports' ),
'callback' => 'bbioon_run_insight',
'args' => array(
'metric' => array(
'type' => 'string',
'enum' => array( 'net_revenue', 'orders' ),
),
),
) );
} );
function bbioon_run_insight( WP_REST_Request $request ) {
global $wpdb;
$table = $wpdb->prefix . 'wc_orders';
// Definitions live here, in reviewable code, not in the prompt.
$sql = match ( $request->get_param( 'metric' ) ) {
'net_revenue' => "SELECT DATE(date_created) AS day, SUM(total_amount)
FROM {$table}
WHERE type = 'shop_order' AND status IN ('wc-completed','wc-processing')
GROUP BY day",
'orders' => "SELECT DATE(date_created) AS day, COUNT(*) AS n
FROM {$table}
WHERE type = 'shop_order' GROUP BY day",
default => null,
};
if ( null === $sql ) {
return new WP_Error( 'bad_metric', 'Unknown metric', array( 'status' => 400 ) );
}
return rest_ensure_response( $wpdb->get_results( $sql, ARRAY_A ) );
}Here the model’s only job is picking the metric and phrasing the answer, which is the part models are good at, while counts and definitions stay in code where a colleague can review them. I’m not sure the fixed-enum approach survives once people want ad-hoc slicing, by segment, by channel, excluding wholesale, and at some point generated SQL over a curated schema is the honest design. If you go there, point it at a read replica or a nightly copy. One bad generated join against the live orders table during a sale is a bad afternoon for everyone.
The limits that still bite
Tosic notes answers come back as text or a table rather than a visual, and follow-up questions replace drill-downs. That works until someone needs the chart for a board slide. The interpretation problem doesn’t go away either: a dashboard can cast a metric in the wrong light, and a confident paragraph can do the same with better grammar. The ten-minutes-before-the-meeting request becomes a chat message instead of a spreadsheet export, but the person who knows which statuses to count is still the bottleneck. Cost is the quiet one. Every question is a model call plus a query, while a cached dashboard is nearly free after the first build.
So numbers people check daily should stay a report. For the ad-hoc tail, an interface that asks rather than just counts beats another chart nobody opens, and that’s where this kind of agent belongs.
If you’re weighing this on a store, the useful first step is picking the five questions people ask and checking whether your current tables can answer them without heroics. That audit, and building the layer behind it, is work I do, so feel free to send me your setup if you want a straight answer about what’s ready.
This week I wouldn’t start with the agent on any client site. I’d take those five questions, confirm the HPOS tables cover them, and put the revenue definition in one place any future tool can read. Once that exists, the chat layer is a small job. The definitions take longer.
