The Governed Analytics Stack: Why Open Source Declarative Layers Are Replacing Both Code Chaos and BI Copilot Lock-In

Enterprise data teams are discovering that the two dominant models for AI-assisted analytics are failing them in opposite directions. Agent-generated analytics produce flexible, powerful outputs that quickly become ungovernable piles of mixed-language files with no audit trail and no consistent schema. Proprietary BI copilots offer safety and structure, but the UI surface constrains what agents can actually do, and the vendor controls the ceiling. The architectural question that matters for heads of data and engineering is not which of these models to choose. It is how to build a third path using open source declarative layers that give agents governed rails without collapsing the analytical freedom that justifies the investment.

The Governance Gap Is Structural, Not Operational

The problem with agent-generated analytics is not that the agents write bad code. Most modern code-generation agents produce syntactically correct SQL or Python for a given prompt. The problem is that there is no shared contract between what the agent produces and what the downstream system expects.

When an agent generates a metric definition in one session and a slightly different version in another, both may be technically valid. Neither is authoritative. Over time, the data team inherits a collection of ad-hoc definitions that cannot be reconciled without manual archaeology.

This is a structural failure, not an operational one. No amount of prompt engineering or agent fine-tuning resolves it because the gap exists at the layer below the agent, in the absence of a declared, version-controlled semantic model that the agent must write against.

Why BI Copilots Do Not Close the Gap

Proprietary BI copilots appear to solve this by constraining agents to a governed surface. The agent can only produce outputs that the BI tool's API permits, which limits the blast radius of any single bad generation. That constraint is real and valuable in certain contexts.

The cost is equally real. Copilots embedded in BI platforms are optimised for the vendor's data model, not the organisation's. Metric definitions, join logic, and aggregation rules are encoded in the tool's proprietary layer, which means they are not portable, not independently testable, and not accessible to the rest of the data stack.

When a finance team asks why a dashboard number differs from a warehouse query, the answer is often trapped inside the BI tool's internal state. That is not a governance posture. It is a black box with a better interface.

The Declarative Layer as the Architectural Pivot

The pattern that resolves both failure modes is a declarative semantic layer sitting between the data warehouse and the agent's output surface. Tools like dbt's semantic layer, Cube, and LookML-style YAML definitions represent metrics, dimensions, and join paths as version-controlled code rather than as embedded BI logic.

What Declarative Means in Practice

A declarative metric definition specifies what a metric is, not how to compute it in any particular context. The agent writes against this specification. Any dashboard, notebook, or downstream API that consumes the metric reads from the same authoritative definition.

This matters commercially because it decouples analytical flexibility from governance risk. An agent can generate a new dashboard configuration, a custom cohort analysis, or a one-off executive report without redefining what "monthly active users" means. The definition is fixed upstream. The agent operates within it.

Audit Trail Design

A declarative layer also makes audit trail design tractable. Because every metric query passes through a defined interface, the system can log which definition version was used, which agent session triggered the query, and which downstream surface consumed the result.

Without this layer, audit trails require instrumenting the agent itself, which is fragile and session-dependent. With it, the audit trail is a property of the semantic layer, not of any individual agent run. That distinction matters significantly for regulated industries where lineage is a compliance requirement, not a nice-to-have.

Open Source Tooling and the Vendor Lock-In Calculus

The case for open source implementations of this pattern is not ideological. It is about where the control boundary sits. When the semantic layer is open source and version-controlled in the organisation's own repository, the definitions are owned by the engineering team. They can be tested in CI, reviewed in pull requests, and migrated independently of any BI vendor's release cycle.

Proprietary semantic layers exist inside vendor platforms and move on vendor timelines. If the vendor deprecates a metric type or changes how joins are resolved, the organisation's governance posture changes with it, without a code review and without a rollback path.

The open source alternative introduces its own operational costs, particularly around tooling maintenance and schema migration management. Those costs are real and should be scoped honestly before committing to the architecture. For most teams above a certain data maturity threshold, however, the long-term control is worth the short-term overhead.

Deploying Agents Against a Governed Surface

Once the declarative layer is in place, the agent's role changes from metric author to query composer. The agent reads the available metric definitions, constructs queries that conform to the declared schema, and passes outputs to a rendering layer that does not need to understand the agent's internal reasoning.

This separation has a practical consequence for agent reliability. Agents that generate free-form SQL against a raw warehouse schema are sensitive to schema drift, naming inconsistencies, and undocumented join paths. Agents that query a stable semantic API are insulated from most of those failure modes because the semantic layer absorbs the complexity.

The governance benefit compounds over time. As the semantic layer grows, the agent's effective analytical surface grows with it, without introducing new governance risk. Each new metric definition is reviewed, tested, and merged through the same process as any other infrastructure change. The agent inherits the governance without requiring additional agent-level controls for each new capability.

Companion piece to our broader work on agent-driven analytics governance. See Governed Self-Serve Analytics: Agent Abstraction Layer for how to architect the abstraction layer between AI agents and BI dashboards, covering auditability and scalable agent-driven reporting.