Power BI visual layer (thin report) and agentic development

Hi PaginatedDino 

I do not think the idea is naïve. In the scenario you describe, a Deneb-first approach can be entirely reasonable.

Agentic development changes part of the traditional calculation. A declarative Vega or Vega-Lite specification is deterministic, reusable, versionable and much easier for an agent to generate consistently than a native visual containing many loosely related formatting properties. Deneb 1.9 even provides specific PBIR guidance for programmatically or LLM-generated Deneb visuals, so this is clearly becoming a valid development pattern rather than an unintended workaround.

However, I would not equate “contained in one JSON block” with “automatically more maintainable.” With Deneb, you own not only the appearance, but also much more of the visual behaviour.

For example, cross-filtering is supported, but it is disabled by default, depends on resolvable row context, and requires the specification to represent selected and unselected states correctly. Aggregations and transformations can make that resolution considerably more complicated. Deneb also limits the number of data points passed through a selection operation.

The same applies to tooltips, context menus and drill-through. They work well when the mark retains the original row context, but transformations can break that connection. Therefore, the scaffolding would need to define interaction behaviour as rigorously as it defines axes, labels, colours and spacing.

Performance is also not simply a fixed “slight Deneb penalty.” It depends on the number of rows, marks, layers, transforms and renderer. Deneb has a default 10,000-row limit, and its documentation recommends Canvas rather than SVG for designs containing many elements. Every additional field also affects both the Power BI query and the Vega rendering workload.

Native visuals still have one major advantage: Power BI owns their platform integration. Standard interaction behaviour, accessibility, focus mode, high-contrast support and showing the underlying data are part of the normal Power BI consumption experience. With generated Deneb specifications, these behaviours should become explicit acceptance tests rather than assumptions.

Therefore, I would probably not adopt the rule:

Use Deneb only when a native visual cannot do it.

But I would also avoid:

Every visual should be a newly generated Deneb specification.

A better rule could be:

Use native visuals for standard analytical components, and use governed Deneb components whenever the organisation requires precise, repeatable presentation patterns.

If 70–80% of the required report layer can be represented by perhaps ten well-tested Deneb templates, making those templates the default is defensible. The important part is that agents should instantiate approved components rather than invent a new Vega specification for every chart.

Such a framework would ideally include:

A controlled set of supported chart patterns.
Semantic field roles rather than hard-coded report-specific field names.
Central design tokens for fonts, spacing, colours and number formatting.
Defined tooltip, selection and cross-filtering behaviour.
Performance limits for rows and rendered marks.
Visual regression tests or screenshot validation.
Accessibility, export and mobile-layout checks.
A native-visual fallback when the required Power BI functionality is more important than pixel-level control.

In that setup, Deneb is no longer merely a custom visual used for exceptional charts. It becomes an internal visualization component framework—and that is a much stronger case for making it the default within its supported boundaries.

If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly.