An AL coding workflow should describe where inference runs and what its tools can access. These are separate architecture decisions, even when both happen on the same computer.

Microsoft’s October 7 update discusses local models and sandboxed tools for Windows and GitHub Copilot. Local inference does not make the full session offline. [6]

I would evaluate this direction with an explicit task and a reference project before changing an AL team’s standard environment.

Write a task-level policy

Consider a proposed exercise: inspect a module, implement a small change in a working copy and report validation results. The following table is my suggested evaluation policy, not a claim about a product’s default settings.

Resource	Proposed access	Reason
Reference repository	Read	Preserve the baseline
Dedicated working copy	Read and write	Contain implementation changes
Compiler and required dependencies	Explicitly available	Enable agreed validation
Network	Only required destinations	Make external dependencies visible
Credentials	Only those required by the task	Limit unrelated access
Report directory	Write	Retain the outcome and blocked checks

A policy should be tested against the actual processes. An instruction describing a boundary is not evidence that the environment enforces it.

Inspect the tool path

Microsoft describes different enforcement boundaries for shell processes, built-in file tools and remote MCP services. They should not all be treated as if they share one local sandbox. [6]

For an AL exercise, map the tools that will read source files, compile the change and contact external services. Check where each process runs and which permissions it receives. Any unsupported step should be reported as blocked rather than silently replaced with an unverified result.

Compare the completed task

Use the same input, requirement and acceptance criteria when comparing model options. Record whether the change is correct, what compilation reports and which tests actually ran.

Measure the complete task, including context preparation, tool use and corrections. A fast first response can still produce a slow delivery if the implementation needs extensive repair.

Keep dependency access separate from deployment. This proposed first exercise should end with a reviewed change and a validation report in the working copy. Publication to a Business Central environment would be a separate task.

Connect the result to ALDC

For ALDC, I see an opportunity to document task conditions alongside acceptance criteria and execution evidence. This is a proposed direction, not a release announcement.

A useful report should explain what changed, which checks ran, what failed and what the environment prevented. That makes model evaluation more meaningful and gives the next person enough information to continue the work.

Source: [6] Microsoft’s local-model and sandbox update.