{"slug": "introducing-agent-native-analytics", "title": "Introducing Agent Native Analytics", "summary": "Agent-Native Analytics launched as a product that places an AI agent inside the analytics application alongside dashboards, metric definitions, and connected data sources, allowing it to write BigQuery SQL, dry-run queries against the warehouse, and save panels directly to dashboards. The product is built on Agent-Native, an open-source TypeScript framework whose agent and interface share typed actions, a common application data model, and application state such as the current page, filters, and date range. Agent-Native Analytics also includes a living data dictionary of approved metric definitions, authoritative sources, join patterns, owners, and known caveats that the agent consults before writing dashboard SQL.", "body_md": "# Introducing Agent Native Analytics\n\n[AI](https://www.builder.io/blog/topics/ai)\n\nLast week I exported a CSV out of our warehouse, pasted it into a chatbot, and asked it why signups dipped in August. It did a decent job. It found the dip, guessed at a cause, and drew me a chart.\n\nThen I closed the tab and all of it was gone.\n\nThat's what analysis in a chatbot gets you. The work happens, and then it evaporates. Nobody else can see the chart, nothing got saved to a dashboard, and the next person to ask starts over with their own export, their own definition of \"signup,\" and their own answer.\n\n[Agent-Native Analytics](https://www.agent-native.com/apps/analytics/?ref=matthew) puts the agent inside the analytics product, next to the dashboards, metric definitions, and connected sources your team already uses. Ask for weekly active users over the last six months and it checks the approved definition, writes the BigQuery SQL, dry-runs it against the warehouse, and renders the chart. Say \"add this to the Growth dashboard and break it down by plan,\" and the panel saves itself into the dashboard while you watch.\n\nRefresh the page. It's still there. That's what changes when the agent and the interface share actions, data, and current context.\n\n## The chat box is only the front door\n\nA chat interface is useful when a request is easier to say than to configure. But the chat box is only the control surface. What matters is whether the agent receives structured application context and can use the same operations and records as the UI.\n\n[Agent‑Native](https://www.agent-native.com/docs/what-is-agent-native/?ref=matthew) is an open-source TypeScript framework built around a different relationship between the agent and the application. They share three foundations:\n\n1. **Shared actions.** A capability is defined once as a typed action. The agent can call it as a tool, while the interface calls the same implementation from code. Both paths use the same schemas, validation, permissions, and business logic.\n2. **Shared data.** Work created through the agent and work created through the UI live in the same application data model. A panel saved in conversation is the same panel that appears on the dashboard.\n3. **Shared application state.** The agent receives relevant context such as the current page, dashboard, filters, date range, or selected resource. That is what makes instructions such as “add this” and “break this panel down” meaningful.\n\nFor normal application work, the agent does not need to click through the interface. It uses the same action layer as the UI.\n\n## One analytics question contains a small specification\n\n“Show weekly active users” sounds like a simple query. In a real company, it hides a set of decisions.\n\nWhat counts as active? Which identities and events qualify? Which timezone sets the week? Which table is authoritative?\n\nA query can be valid SQL and still answer the wrong question.\n\nThat is why Analytics includes a [living data dictionary](https://www.agent-native.com/docs/template-analytics-dashboards/?ref=matthew) for approved metric definitions, authoritative sources, join patterns, owners, and known caveats. The agent consults that vocabulary before writing dashboard SQL.\n\nIn our walkthrough, Weekly Active Users is an approved Growth metric with a specific source and definition. The private table name is incidental. What matters is that the meaning is explicit and reviewable.\n\nThe dictionary reduces guessing; it does not make judgment unnecessary. Owners can review definitions, experts can inspect queries, and the team can update an entry when its business logic changes. Governance becomes part of the product instead of text pasted into every prompt.\n\n## From one question to a validated chart\n\nHere is what happens behind that opening request.\n\n### 1. Consult the metric context\n\nThe agent begins with the question, the active organization, and the relevant screen state. It looks up Weekly Active Users in the data dictionary and uses the approved definition, source, and caveats as context for the work.\n\nIf the metric is missing or ambiguous, the honest response is to surface that uncertainty or ask for a decision. Silently inventing a definition would produce a faster chart and a weaker analytics product.\n\n### 2. Choose the connected source\n\nFor this walkthrough, the source is the connected BigQuery warehouse. The connection is configured once and reused across questions, dashboards, and investigations. The user does not need to upload another export or redescribe the schema in every conversation.\n\nAnalytics can also work with configured product, revenue, engineering, support, communication, and content sources. More important than the evolving catalog is that sources are durable, access-controlled application connections—not one-off prompt attachments.\n\n### 3. Write and validate the SQL\n\nThe agent writes the panel query from the approved context. The SQL remains visible, so somebody who knows the data can inspect the tables, joins, filters, and aggregation rather than accepting a black-box answer.\n\nWhen Analytics saves new or changed SQL for a BigQuery dashboard panel, it dry-runs that SQL against the warehouse before persisting the change. That catches problems such as invalid columns or tables before a broken panel becomes part of the dashboard. A successful dry run shows that BigQuery accepts the query; it does not prove that the business definition is correct. That still depends on the dictionary entry and human review.\n\n### 4. Render the answer in the product\n\nOnce the query returns data, Analytics can render it as a chart, table, or metric suited to the result. In this case, six months of weekly values become a time-series chart.\n\nUsers can ask the question without writing SQL, but SQL dashboard panels keep the generated query inspectable in the dashboard UI. Analytics also includes a separate SQL Query Explorer for direct BigQuery work. Natural language speeds up the path to an answer without removing the underlying tools experts need.\n\nReturning the chart is useful. Turning it into a persistent, editable, shareable resource is the bigger step.\n\n## The answer becomes part of the product\n\nThe follow-up is deliberately contextual:\n\nAdd this to the Growth dashboard and break this panel down by plan.\n\n“This” and “this panel” resolve because the agent receives the active result and dashboard as structured context. The user does not have to restate the query, paste a dashboard ID, or identify the chart again.\n\nThe action writes the panel into the dashboard’s saved configuration and breaks the result into the relevant plan series. Refresh the page or return later and the panel remains. From there, a person can inspect the SQL, resize or reorder the chart, and share it; the agent can continue from the same state.\n\nPersistence makes the result reusable. Governance makes it worth reusing.\n\n## One action contract serves both agent and UI\n\nThe Analytics template implements its shared-action model as typed contracts. A dashboard read declares its inputs, HTTP method, read-only status, agent exposure, and authentication requirements once. The UI calls that contract through application hooks; the agent receives the permitted contract as a tool.\n\nAn illustrative shape based on the [open-source dashboard action](https://github.com/BuilderIO/agent-native/blob/main/templates/analytics/actions/get-sql-dashboard.ts) looks like this; omitted implementation is marked explicitly:\n\nThe point is the contract. Validation and access boundaries do not disappear when an instruction arrives in conversation. A dashboard-composition action can validate panels, save the resource, and return a deep link. The agent does real work without becoming a privileged parallel product.\n\nRelevant screen state completes the loop. Analytics can provide the current dashboard, filters, view, and selected resource. This is not omniscience or a browser dump; it is structured context supplied by the application.\n\n## What this changes for product builders\n\nAnalytics is one example, but the design test applies to any product where an agent and a person need an ongoing role in the same work.\n\n- **Define capabilities as product contracts.** If “create report,” “assign ticket,” or “publish page” exists only inside a click handler, the agent needs a second implementation. A shared action gives both surfaces one schema, permission boundary, and behavior.\n- **Make context explicit.** The current page, selected record, active organization, and visible filters should be structured state—not clues the model has to infer from prose or pixels.\n- **Model durable artifacts.** The most useful output is often not a message. It is a dashboard, document, ticket, campaign, or design that remains in the application after the conversation ends.\n- **Keep judgment visible.** Agent-native does not mean hiding the work. Queries, definitions, approvals, errors, and revisions should be inspectable in the interface appropriate to the domain.\n- **Use an agent where the work is genuinely open-ended.** A direct model call is simpler for one generated response, and ordinary application logic is better for a fixed sequence. The agent-native pattern earns its complexity when the agent and UI must keep collaborating on evolving work.\n\nThese choices change chat from a feature into one participant in the product’s operating model.\n\n## Analytics is more than text-to-SQL\n\nThe same model extends beyond the initial dashboard:\n\n- **Understand:** reusable SQL and Explorer dashboards, saved investigations, the data dictionary, and direct SQL exploration.\n- **Publish:** filters, saved views, sharing, scheduled dashboard email reports, and alert rules over first-party event counts.\n- **Operate:**[uptime checks, public status pages, error triage, and session replay](https://www.agent-native.com/docs/template-analytics-monitoring-and-sessions/?ref=matthew) with console and network context.\n\n[Connected sources](https://www.agent-native.com/docs/template-analytics-connectors/?ref=matthew) span warehouses and configured SaaS systems. For registered providers, an API escape hatch can reach endpoints or filters not covered by built-in actions; adding a new source means extending the template in code. These surfaces do not all use one SQL path. What they share is that the agent works with real application resources while people retain an interface for inspection and control.\n\n## Start from a complete product, not a blank scaffold\n\nWe publish Agent‑Native Analytics as a hosted app and a complete open-source template. Rather than starting from a blank framework, the template includes the product UI, agent surface, application data model, authentication, and deployment structure. Agent‑Native calls this model [Cloneable SaaS](https://www.agent-native.com/docs/cloneable-saas/?ref=matthew).\n\nMetric definitions, exclusions, permissions, infrastructure, and review practices differ from company to company. With the template in a repository you control, developers and coding agents can change the interface, add actions, connect a source, introduce a visualization, and review those changes through the team’s normal engineering process.\n\nThat differs from the embedded product agent’s day-to-day role. It works through granted actions and integrations. Source changes require an explicitly equipped coding or workspace agent and normal review and deployment discipline.\n\nTeams can control the application code, queries, deployment, and data stack. BigQuery remains the connected warehouse, while Analytics persists application resources such as dashboards, settings, analyses, and monitoring configuration in its own database. “Own your stack” is more accurate than claiming that no data ever crosses a system boundary.\n\n## Try the workflow yourself\n\nStart with a question whose answer your team already understands. [Try the hosted Analytics app](https://analytics.agent-native.com/?ref=matthew), connect a source, and inspect the metric definition, generated SQL, and result before saving it to a dashboard.\n\nOr create the complete Analytics template in your own repository:\n\nThe useful test is not whether the model can produce a plausible answer. It is whether the application turns that answer into durable work people can inspect, edit, trust, and continue.\n\nThat is Agent‑Native: software in which people and agents operate through the same product—and build on each other’s work.\n\n[Try Agent‑Native Analytics](https://analytics.agent-native.com/?ref=matthew) or [start from the open-source template](https://www.agent-native.com/docs/template-analytics-developers/?ref=matthew). Then tell us what it should do next.", "url": "https://wpnews.pro/news/introducing-agent-native-analytics", "canonical_source": "https://www.builder.io/blog/introducing-agent-native-analytics", "published_at": "2026-09-10 18:00:00+00:00", "updated_at": "2026-09-15 15:18:08.017027+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Agent-Native Analytics", "Agent-Native", "BigQuery", "TypeScript"], "alternates": {"html": "https://wpnews.pro/news/introducing-agent-native-analytics", "markdown": "https://wpnews.pro/news/introducing-agent-native-analytics.md", "text": "https://wpnews.pro/news/introducing-agent-native-analytics.txt", "jsonld": "https://wpnews.pro/news/introducing-agent-native-analytics.jsonld"}}