Why We Built BCQuality: Closing the Gap Between What Agents Know and What BC Developers Learn

Last week I watched a coding agent generate a perfectly reasonable Customer Returns page for Business Central. Clean AL, good structure, sensible field layout. It even added error handling when the customer was blocked.

Unfortunately, the error handling was a generic Error('Customer %1 is blocked.') message. A dead end. The user reads a vague sentence, then has to close the page, navigate to the Customer Card, find the Blocked field, change it, come back, and try again.

An experienced BC developer might instead use ErrorInfo with AddNavigationAction to put an "Open Customer Card" link right in the error dialog. One click, problem solved. But the agent didn't know that pattern. The documentation mentions ErrorInfo, but the specific technique of wiring a navigation action into a business-process error? That's something you learn from building BC apps, not from reading docs.

That gap is why BCQuality exists.

Seven Years of Good Intentions

AL Guidelines launched seven years ago as a community-driven documentation site for BC development best practices. The idea was sound: collect what the community knows and put it somewhere everyone can find.

It got maybe 20% of the way there. Partial coverage, limited adoption, contributor PRs (pull requests) waiting... The problem wasn't the content. It was the delivery model. You had to read the guidelines, internalize them, and remember to apply them mid-session. Most people didn't.

I spent the last six months running BC Code Intel, which took a lot of that knowledge and made it agent-consumable. Agents that could apply guidance throughout the process, without a human needing to remember anything. It worked, but it was a one-person project, and the curation was a bottleneck.

The emergence of BCQuality

Jesper Schulz-Wedde at Microsoft and I started talking about combining the lessons from AL Guidelines (community-maintained, broad coverage) with Code Intel (agent-consumable, actually used at review time). BCQuality is what came out of that.

BCQuality is a GitHub repo with two equally important halves: knowledge and skills. 

Knowledge files are atomic markdown files with YAML frontmatter. Each one covers a single concern in under 100 lines, ideally under 50. Frontmatter tells agents which BC versions, technology stack, functional area, and countries the file applies to. When an agent runs a code review, it loads the handful of files that apply to your specific PR, not the entire extension.

Skills define how agents actually use that knowledge. An entry-point skill reads the task context (what kind of work is being done, which BC version, what changed) and routes to the right action skills. Each action skill follows a standard four-step pattern: figure out where to look, filter to what's relevant, build a worklist, then take action. The skill produces structured output that any orchestrator can consume, with findings traced back to the specific knowledge files that informed them.

Each half is designed to work with the other, and both are readable markdown you can inspect, fork, and extend.

Three layers organize the content: 

1. Microsoft-endorsed content in /microsoft/. 
2. Community-contributed patterns in /community/. 
3. Your organization's own rules in /custom/ in your fork. 

If files contradict, layer precedence resolves it automatically. This layering applies to both knowledge and skills: you can override a Microsoft action skill with your own custom version, the same way you'd override a knowledge file.

The Admission Test

Here's the part that matters most, and the part we argued about longest.

A knowledge file doesn't earn its place by being true. It earns its place by encoding something that a capable agent would get wrong otherwise. In other words, if this file didn't exist, would a modern coding agent make a mistake?

If the answer is no, the file doesn't belong. "Use HTTPS instead of HTTP" is sound advice, but any competent agent already applies it. Including it would waste context budget and dilute the signal from files that actually matter.

The files that survive tend to describe situations where you'd think one approach is correct, but a BC-specific behavior makes it wrong, and the consequence doesn't surface until production. Subtle platform behaviors, version-specific gotchas, defaults that quietly set you up to fail.

We triaged candidate knowledge from Code Intel by generating coding tasks where each anti-pattern would be tempting, then handing them to a fresh agent session with no BCQuality context. About 40% of what we initially thought was essential turned out to be stuff agents already handle correctly.

Why a Partner Should Care

Your agents are already generating and reviewing BC code against their training data. That's a decent baseline. BCQuality fills the gap between that baseline and the expertise of real BC developers. The performance patterns that look correct but tank page loads on large datasets. The error handling that technically works but creates terrible user experiences.

When AL-Go points at BCQuality, every code review automatically checks against this knowledge through the skills layer. No per-project configuration, no rules to memorize.

The custom layer is where it gets interesting for partners. Fork BCQuality, add your organization's patterns in /custom/, and your agents enforce your house rules alongside the Microsoft and community layers. Your senior developers' knowledge gets encoded and applied to every PR. When a senior person leaves, their expertise stays.

Getting Started

BCQuality is public on GitHub at github.com/microsoft/BCQuality. The repo README covers the knowledge file format and contribution process. There are community guides to getting started.

If you're running AL-Go, good news: it'll be very plug and play. The entry-point skill handles routing to the right review skills based on what's in your PR.

If you want to contribute, start by thinking about the mistakes you keep seeing in code reviews. Not the ones everyone knows about. The ones where you find yourself explaining "yes, I know it compiles, but here's what happens when..." Those explanations, compressed into 50-line markdown files with the right frontmatter, are exactly what BCQuality needs.

Please take this approach. Adapt it for your team. Push good patterns upstream to the community layer.

The repo is young and deliberately sparse. It will grow as the community contributes and we identify more industry-wide skills and knowledge that benefit all the agentic development efforts. It'll stay sharp because the triage process rejects noise. There will surely be more about this at BC TechDays 2026 in June if you want the deep dive. In the meantime, the repo is right there.

Open a file, read a skill, and if you find a gap the agents should know about, open a PR. Contributions very welcome.