Use cases

What a data team's routine work looks like when agents do it. You talk, in plain words; AI agents do the work, under rules you set, and a person approves every change. Five activities, each shown on real screens from the family's own use cases. Analyse: ade-catalog reads the estate and draws the lineage, down to each measure with its expression intact. Build: from a conversation, ade-ops writes the Databricks notebooks and builds the Power BI report on top, under gates a person sets. Diagnose: every number is checked against the source engine, what differs is declared, and ade-tower flags a deploy that reported success on a stale model. Find: ade-lens takes a plain question, opens the right report on the right page, and answers with a trust badge and the query behind it. Manage: ade-tower puts every repo's work on one board, shows whose court each item is in, and answers who holds the ball, traced to the ticket notes. The agents execute; people approve; every step is traced.

The team has already chosen its target: a Qlik Sense app moves to Databricks for the data and Power BI for the report. The hard part is not rebuilding the report. It is proving that every number survived. The app, built for this demo on synthetic data, uses the expressions that make these migrations hard: set analysis, TOTAL, Aggr and search sets. First, ade-catalog reads the app. From the load script it shows which files feed which tables. It links each Qlik measure to the tables it reads and the KPI it feeds, with the expression intact, and it stores every measure with its fields and sources. Then ade-ops assesses every object and says why it lands where it does: converted by rule, checked by a person, redesigned, or out. Expressions become DAX that keeps Qlik's semantics, and what has no faithful rule is refused and listed, never guessed. The load script becomes Databricks notebooks, the data lands with the same rows, and the Power BI report is generated from the Qlik sheets. Then comes the proof: every translated measure on every slice, read from the live Qlik engine and from Power BI, side by side. 146 of 154 cases match. The other 8 are one Aggr expression that the two engines evaluate differently. The reason is measured and declared, for the business to decide. Last, ade-lens brings the verdict to the people who use the numbers: the divergence is shown as declared, and an agent beside the migrated report explains a KPI from the model. Here that KPI is "Customers above margin target", 27 of 60, and the agent shows the DAX it ran to check it.

The same method, the other way. The team has chosen Qlik as the target, and a Power BI report has to move there with its numbers intact. ade-ops reads the Power BI semantic model and the report definition: tables, relationships, measures, pages and visuals. Each DAX measure becomes a Qlik expression by rule, with Power BI's semantics kept: a KEEPFILTERS filter becomes an intersection in set analysis, an AVERAGEX over customers becomes an Aggr that takes the chart's own dimensions. What has no faithful rule is refused, with the reason, never guessed. Relationships become Qlik associations, the data is extracted, and a new Qlik Sense app is built with the same sheets. Then the proof: every measure on every slice, the value from the published Power BI model against the value the live Qlik engine returns. 154 of 154 cases match. This was proven on our own round trip: the Power BI model is the one ade-ops generated from a Qlik app, so its DAX is the regular kind our own translator writes.

A business user rarely knows which report holds the answer. They only have the question. Here they ask it beside a live Power BI report, and the agent does the navigating. "Which region is behind plan? Show only that one." The answer is East, −8.0% against plan, and the report filters itself through its own slicer, so every figure is read from the page on screen. "Where are the stockouts? Take me there." That answer lives in another report, so the agent opens it, straight on its warehouse floor plan, and its reply names the report and the page it chose. "Which supplier is slipping?" The drop is computed across all 36 suppliers, not picked by eye. Last, the whole report goes to Excel, one sheet per page, as real tables. The answers stand on the reports and models the company already built, used as they are, with the user's own permissions.

A business user wants a number, not a dashboard. They ask ade-lens in plain words, "In which country do our franchises sell the most?", against a Power BI model that ade-lens's own catalog marks as certified. The answer comes back as a sentence and a small table: Japan, 21,591 in total revenue across 1,387 transactions. It carries a trust badge saying how it was built. Here the badge is "Composed · certified model": a new query composed on the certified model, not one pre-approved measure. One click opens the trail with the exact DAX query the model ran, and the rows it returned are the figures in the answer. The number arrives with where it came from.

Once a Copilot Studio agent is in production, the questions change: who uses it, what do they ask, what do its tools do, and what does it cost? ade-tower's runtime module answers from the platform's own records, read-only. One view lists every agent with its sessions, users, questions, tool calls and estimated credits, and splits business sessions from test-pane ones day by day. Each tool shows its calls, consent waits, errors, p50 and p95 times, and the connector it really used. The conversations read as a chat: search a word in the questions or pick a user, open one session, and see the tool calls folded under each turn. A sources page says how each figure is read, what it covers and how long it is kept. Where two sources disagree, it says so: here the platform's analytics count no sessions for one agent, and the transcripts do.

When several people and their AI agents work across many repos, nobody can say who holds what, or what is stuck, without asking around. ade-tower reads what the work already leaves behind and puts it in one view. Every ticket board, from every repo, lands on one board, project by project. Each open item shows whose court it is in: waiting for review, blocked, stalled, late or not started. A timeline is drawn from the dated notes in each ticket, so nothing is typed twice. One person's cockpit shows what they hold and what moved in their projects. Below the work sits what actually ran: commits, deploys and agent sessions, read from git and the ops log, with who, what and when for every event. A deploy that reported success on a stale model is flagged, not trusted. Agents roll up to the person who runs them, and events that no identity resolves stay "unresolved" instead of being guessed. Then you can ask the tower, for example who is holding the ball right now. The answer comes from this record, with each step of the chain traced to the ticket note it comes from.