Within Modern BI and Big Data programmes, organisations still lose enormous time on repetitive, technically heavy work: gathering requirements, mapping KPIs, designing dimensional models, generating Spark code, building Power BI models, and migrating legacy workloads. To address this, the CoE has created A Team – a family of GenAI‑powered agents designed as accelerators, not replacements, across the full lifecycle of data projects.

From internal exploration to client‑ready products

The A Team initiative started as an internal exploration project inside the Modern BI and Big Data Centre of Excellence, whose core mission is to drive innovation by continuously testing new features, building robust solutions, and only then bringing them to customers. Rather than selling unproven ideas, the CoE fosters an innovation-first mindset, prototyping internally, validating both value and limitations, and only then packaging capabilities as mature, reliable products for client projects.

Over the last year, agents and “agentification” in combination with GenAI have been the hottest topic inside the CoE. The team has focused on learning how to orchestrate multiple specialised agents, how to embed them in existing engineering ecosystems (Databricks, Fabric, VS Code, GitHub Copilot, Genie Code, among others) and how to ensure that humans remain in control. These agents are explicitly framed as accelerators, giving teams more speed and consistency, while preserving human responsibility for design and validation.

The A Team architecture: groups of specialised agents

A Team is the umbrella project name for a set of agent groups, each targeting specific phases of the data lifecycle. Each agent is designed to operate independently—given the right input format—even though they can also be orchestrated end‑to‑end in multi‑step flows. This modular approach favours adoption in real projects, where teams rarely switch everything at once and instead introduce new accelerators incrementally.

At the time of the session, three groups are the most prominent:

• SWAT Kimball – agents focused on BI requirements, KPI mapping, dimensional modelling and Spark‑based physical implementation.
• Ciphersmiths – agents focused on code migration and modernisation (“lift‑and‑shift plus best practices”).
• Librarians – agents focused on documentation of code, data pipelines and databases, currently under active development.

Additional agents for data quality, observability, test generation, framework validation, cost assessment and orchestration are in the pipeline or on the horizon.

SWAT Kimball: from KPIs to star schemas

SWAT Kimball addresses the most fragile and labour‑intensive part of BI projects: turning business KPIs into robust dimensional models and executable code. The workflow typically starts from a business document describing KPIs and their mathematical formulas, plus a “print‑out” of one or more databases with table, column and data type metadata. The preferred input is Markdown because LLMs read it more reliably and efficiently, but PDF and other formats can be converted to Markdown up‑front (for example via another LLM such as Claude).

Key agents in SWAT Kimball include:

• KPI Wizard – reads KPI formulas and database metadata, maps each KPI to source columns, calculates a confidence score per mapping, and suggests additional KPIs that would make sense given the data.
• Confidence Judge – a “LLM as judge” that recomputes and validates the confidence calculations and fixes any errors directly in the mapping document.
• Model Storyteller – consumes the validated KPI‑to‑source mapping and produces a detailed logical dimensional model and star schema design, including fact tables, dimensions, grain, SCD strategy, keys and additive/non‑additive measures.

• KPI Sentinel – acts as an LLM-as-judge, validating that all requested KPIs are covered in the model and flagging missing or ambiguous elements. It produces a pass/fail style assessment complemented by structured warnings.

• DIMS Builder and Facts Builder – for each dimension and fact, generate PySpark notebooks targeting Databricks or Fabric, following internal frameworks and best practices.
• Notebook Inspector and Functional Sentinel – operate as LLM-as-judges, summarising the generated notebooks, checking adherence to coding templates and best practices, and verifying that the requested logic is correctly implemented.

Throughout the flow, humans stay in the loop to validate mappings with stakeholders, approve the logical model, and review generated code, treating the agents as high‑speed assistants rather than autonomous decision‑makers.

Ciphersmiths: industrialising code migration

Ciphersmiths focuses on the painful reality of migrations, where large legacy codebases must be moved to new platforms or engines. Traditional lift‑and‑shift approaches quickly hit quality limits, especially when thousands of lines of code are sent to a single LLM call; quality degrades beyond roughly a few hundred lines and some segments may not even be migrated. Ciphersmiths addresses this by decomposing work and applying layered validation and optimisation.

Core agents include:

• Source Repartition – analyses source code and splits it into logical blocks below a configured size threshold, avoiding cuts inside procedures or functions.
• Code Migrator – performs the actual transformation from source to target language or framework, block by block.

• Code Inspector – functions as an LLM-as-judge by comparing source and target blocks, highlighting missing pieces or red flags, and ultimately deciding whether the migration is acceptable.

• Migration Fixer – a fresh agent instance that re‑works problematic blocks using the Code Inspector’s report, avoiding reinforcing previous mistakes.
• Code Wise – applies a set of best‑practice heuristics to “clean up” migrated code, reducing repetition and improving performance so that the outcome is more than a naive lift‑and‑shift.
• Migration Mapper – generates a detailed mapping between source and target objects, enabling manageable human validation of large migrations.

This approach recognises that automation reduces the coding effort but increases the need for careful validation; the Migration Mapper is crucial to make that validation feasible.

Librarians and beyond: documentation and governance

The Librarians group aims to solve the chronic lack of up‑to‑date documentation in data projects. Existing agents already document SQL and PySpark code, as well as Azure Data Factory ARM templates, explaining what each pipeline and script actually does. Other agents read large databases in chunks and produce structured, business‑friendly documentation that supports data cataloguing and governance.

On the roadmap, the team is designing:

• An orchestrator agent that can call other agents automatically and only involve humans when needed.
• Agents for data quality monitoring, observability and test generation in CI/CD pipelines.
• Cost‑assessment agents, particularly for Databricks, that analyse system tables to suggest performance and cost optimisations.

These initiatives are being prototyped first with tools like GitHub Copilot and Databricks Genie Code, with the CoE actively testing what should live inside Databricks versus outside, and when to use instruction‑heavy prompts versus smaller reusable skills.

Why this matters for clients

For clients, A Team’s GenAI agents translate into faster delivery without compromising quality, enabling more consistent implementations and better documentation across BI and data engineering projects. By treating agents as accelerators rather than black-box replacements, the CoE keeps human experts in control while unlocking meaningful gains in productivity and maintaining high standards of reliability and performance.