Opening and positioning
We align expectations, provide industry context and set the conceptual lens through which the rest of the workshop is read. ALDC is not an internally invented framework — it is the AL concretisation of a discipline that is consolidating across the agentic coding community.
Welcome
Workshop on GitHub Copilot for Business Central, agents and discipline in AL. Material designed to follow at your own pace — each block stands on its own.
Javier Armesto · 20+ years with Microsoft Business Applications. This workshop captures what was learned building agents, skills and open-source frameworks on AL. Everything here is material used in real projects, not theory.
Something worth underlining: if when following the material something doesn’t work as described — and it can happen, we’re working with agents — that’s part of the learning. What fails teaches more than what works perfectly.
Positioning · ALDC vs vanilla LLM
The central problem this entire workshop addresses has a name: context decay. The code an LLM generates is usually good at the start and degrades as the session grows longer, the context expands, or the requirement is ambiguous.
There are two distinct mental models for working with Copilot today. They are not rivals — they are suited for different moments.
The two mental models
Vanilla LLM
- One prompt — one response
- Context accumulates in session
- The LLM decides what to do
- Good for exploration
ALDC
- Disjoint roles, HITL gates, Skills Evidencing
- Memory externalised in files
- The spec decides what to do, the LLM executes
- Good for production
Vanilla is not bad. It's perfect for a prototype, a quick test, a one-off migration script. The problem appears when it's used where it doesn't belong — client code, extensions going to production, integrations with core functionality.
BC-Bench · the objective yardstick
BENCHMARKING FRAMEWORK · MICROSOFT
BC-Bench
Microsoft's framework for evaluating AL coding agents on Business Central. It is the official reference.
- Evaluates real AL tasks (creating objects, fixes, extensions)
- Measures success rate, clean compilation, tests, convention adherence
- Allows comparing agents against each other with clear rules
You can check my guide on BC-Bench: javiarmesto.github.io/BC-Bench-Guide
SDD Primer · external validation and conceptual framework
ALDC is not an internal invention. It is the AL concretisation of Spec-Driven Development — an emerging consensus in the agentic coding industry that already appears in courses, spec authoring tools, and technical publications.
Conceptual map · canonical SDD → ALDC Core → ALDC Ecosystem
Canonical SDD
- Constitution
- Plan →
- Implement →
- Validate →
- Replan
ALDC Core
- Decalogue 12 rules
- architect/spec/conductor
- Skills Evidencing
- No-self-review
ALDC Ecosystem
- ALDC ↔ CIRCE ↔ Delfos
- Extension Manifest
- (async bridge)
Canonical SDD · Project Constitution, plan by feature, implement, validate, replan. The industry consensus.
ALDC Core · Takes that consensus and hardens it with the real constraints of AL and BC: ID ranges, ownership by app, explicit dependencies, naming conventions, permission sets. The spec is not improvised for each feature — it is fixed once and the agent follows it.
ALDC Ecosystem · ALDC for AL, CIRCE for Copilot Studio, Delfos for Power BI. Three squads connected by an asynchronous Extension Manifest. The manifest appears working in Block 4.
1:1 correspondence · canonical SDD ↔ ALDC
| Layer | Canonical SDD | ALDC |
|---|---|---|
| Project contract | Constitution | Decalogue + decisions.md |
| Feature design | Plan + spec | al-architect + al-spec.create |
| Execution | Agent implements | al-conductor + 3 subagents |
| Validation | Scorecard | review-subagent + no-self-review |
Each ALDC layer has a direct equivalent in canonical SDD. The difference lies in how ALDC separates the roles.
Canonical SDD is mono-agent — the same agent designs, implements and validates. ALDC separates four functions: architect designs, spec.create details, conductor executes, review-subagent audits. No self-review.
It's the difference between a soloist and an orchestra with a conductor. Not pedantry — it's the only way to make agent use auditable in a regulated project.
Greenfield vs brownfield · ALDC adapts
🌱 Greenfield
New AL extension. The Constitution is written once and the agent never again guesses ranges, conventions or dependencies. Tech debt decreases from day one.
🏚 Brownfield
NAV→BC upgrade, inherited custom code. Discipline first, then changes. Assisted discovery and decisions.md to document legacy without rewriting.
Two scenarios where ALDC changes shape but keeps the philosophy. Today's workshop is greenfield — CRONUS case with a new extension. But the takeaway: ALDC adapts, and the more complex the project, the more discipline pays off.
The spec is the brain.
The agent, the muscle.
The human architect, the one who signs.
Agenda and the case we'll build
Four blocks. The first is a warm-up — Copilot used well. The second steps up — how ALDC structures what Copilot does. The third introduces orchestration with roles. The fourth is the full hands-on, the complete case from start to finish.
What you take away from the workshop
Public repo
The aldc-workshop repo with the solved case in the solution branch.
Open exercises
Challenges to continue on your own after the workshop.
Supplementary material
Post-workshop content shareable according to interest and demand.
What this block covers
Welcome
Opening and creator introduction. Industry context.
Positioning
Context decay. Vanilla vs ALDC. BC-Bench as the objective yardstick.
SDD Primer
3-block conceptual map. 1:1 correspondence table. Greenfield vs brownfield. The spec phrase.
Agenda and case
The 4 blocks with the break. Barista Incidents introduced as expectation. The 3 deliverables.