Business Central v29 brings agent-assisted snapshot capture
into the debugging workflow. The useful question is how we turn that
recording into a diagnosis we can check.
Javier Armesto · Circe Innovation
TechSphere Dynamics · Research checked on 18 October 2026
An agent can write an AL procedure, explain its intention and suggest
a correction when something goes wrong. But what happens when the
explanation sounds reasonable and the application still fails? Have we
found the cause, or have we simply found a convincing story?
Microsoft’s “Debug recorded Business Central failures with an AI
agent” feature deserves attention because it connects the conversation
with recorded execution. That is a practical step towards better
investigations. It also gives us a reason to be more precise about what
an agent has actually achieved.
Prefer YouTube? Watch the 33-second explainer on Tech Sphere Dynamics. Conceptual illustrations; ALDC/Codex tests are pending.
What changes in v29
The new path lets an agent prepare a snapshot capture, wait while a
person reproduces the failing scenario, and collect the recording for
investigation. The user still performs the reproduction. This uses the
existing snapshot engine rather than replacing it. [1]
Snapshot debugging itself predates v29. The change is the
agent-facing route into the workflow. In the editor, AL’s tools already
provide snapshot actions; v29 documents an additional connection path
through ALTool’s snapshot MCP proxy. [2][3]
My interest is in the connection between code generation and runtime
evidence. A repository tells an agent what the code says. A recording
can help an investigation examine what happened in a particular
execution. Neither removes the need to understand the business rule.
Availability:
Microsoft’s pages still disagree
As checked on 18 October 2026, the v29.0 overview lists this feature
as generally available. That overview was updated on 1 October 2026.
[4]
The snapshot guide, dated 21 August 2026, still describes the agent
capability as preview with a prerelease of runtime 18 and Business
Central Server 29. The ALTool reference, updated on 1 October 2026,
repeats that preview qualification. [1][3]
There is therefore a current documentation inconsistency, not just an
old note we can safely ignore. I would describe this as a v29 capability
listed as GA in the release overview, with technical documentation still
carrying preview requirements. Before planning a customer rollout, check
the actual server build, installed development tools and exposed
capabilities. I have not verified a minimum production-ready ALTool
build for this workflow.
The tools
are related, but they are different surfaces
“MCP support” is too broad a description for an implementation
decision. These are the boundaries that matter:
| Surface | Documented role | What it does not establish |
|---|---|---|
| VS Code AL Language Model Tools | Editor-integrated actions for AL work, using the active launch configuration. |
Availability of the same tools in an external agent host. |
VS Code al_snapshotdebugging |
initialize, finish and viewactions, including opening recorded traces in the editor. |
An identical tool name or schema in Codex. |
ALTool launchmcpserver |
Standalone AL workspace tools, such as build, compile, symbols and diagnostics. |
That the workspace server includes the VS Code debugger tools. |
ALTool launchsnapshotmcpproxy |
A stdio bridge to snapshot capabilities in a running BC environment; no local AL project is loaded. |
That receiving an archive gives Codex a working snapshot inspection interface. |
| Business Central MCP server | The environment-side service that the snapshot guide identifies as hosting the snapshot capabilities. |
Interchangeability with the local AL workspace MCP server. |
| Troubleshooting MCP Server for AL | Access to frames, variables and source during a paused VS Code debugging session. |
A general offline reader for arbitrary historical recordings. |
Sources: [1][2][3][5][6][7].
Microsoft documents automatic snapshot-proxy registration in VS Code
agent mode, deriving the connection from launch.json.
Outside the editor, the host must launch the proxy and authenticate
correctly. [3] A configuration that works for one host should not be
copied into another host’s configuration format without checking it.
Capture,
inspection, diagnosis and validation are separate achievements
I would keep four explicit milestones in any investigation:
Capture: there is a recording of the intended
reproduction. A successful tool call alone is not enough to establish
that the relevant failure was recorded.
Inspection: the investigator can access useful
execution state and relate it to the correct application version.
Possessing a binary archive is not the same as reading its contents.
Diagnosis: the proposed cause explains the observed
state and the business behaviour. The explanation should identify
supporting evidence, competing explanations and information that is
missing.
Validation: a targeted test fails before a
correction and passes after it, and relevant regression checks support
the change. A diagnosis can be correct while a proposed correction is
incomplete.
These are acceptance criteria I propose for our engineering workflow.
They are not results from a completed Codex experiment.
What to check
before trusting the explanation
The recording has limits. Variables are captured at snappoints and AL
exceptions, rather than continuously. Matching symbols and deployed code
matter. The MCP path also requires an enabled environment MCP server,
D365 Snapshot Debug and D365 ATTACH DEBUG,
including for the caller’s own session. [1]
That changes how I would review an agent’s report. For each claim, I
want the recorded value or execution point that supports it. If the
needed state was not captured, the report should say so and propose
another observation. An empty result must not become evidence that
nothing happened.
The separate Troubleshooting MCP documentation is also useful here:
it describes a paused active debugger, limits analysis to its current
stack, and explicitly calls for verifying variables, frame order and
source versions. [7] We should not silently promote that into proof that
an external host can inspect every collected snapshot.
For partners, the practical implication is ownership. Who selects the
scenario? Who confirms that the capture is relevant? Who checks the
explanation against the requirement? Those responsibilities should
remain visible even when an agent performs more of the tool work.
Where ALDC could fit
For ALDC — AL Agentic Engineering System, I see a possible
investigation workflow: preserve the failure description and version
baseline, collect a controlled recording, require an evidence-backed
diagnosis, then carry a proposed correction into review and testing.
The important connection is between artifacts. A diagnosis should
point to evidence. A proposed change should point to the diagnosis. A
test should demonstrate the behaviour we intend to restore. A reviewer
should be able to follow those links without having to trust the agent’s
confidence.
This is a proposed application of ALDC. My tests of this v29 workflow
with ALDC in Codex are pending. I am not claiming that Codex can already
collect, inspect, diagnose and validate a correction through this
combination.
The experiment I want to run
next
Start with a reproducible failure in an isolated sandbox and record
the tool and server versions. First test discovery and capture. Then
establish whether Codex can inspect the recording through an available,
supported surface. If it cannot, record that boundary and use VS Code
for human inspection.
Only after that should we assess the diagnosis. Include a case with
insufficient evidence, because admitting uncertainty is part of the
behaviour we need to test. Keep correction and regression validation as
a later, separately measured stage.
The feature is worth exploring because it can bring runtime evidence
closer to an agent’s investigation. My acceptance criterion remains
simple: can another developer check the explanation against what was
captured?
Evidence first. Human judgment, always.
Official sources
All sources accessed on 18 October 2026. These are documentation
findings, not local execution results.