Business Central 29.0 Preview: AL Tooling Starts Being Designed for Agents Too

Microsoft has published the public preview of Business Central 2026 release wave 2, version 29.0. After going through the change list, one thing stands out for me well above the number of features.

Business Central is starting to prepare its development platform for a scenario where whoever consumes AL tooling is not necessarily a person working inside Visual Studio Code.

It can also be an agent. I have been saying this all year.

The usual brake first: this is prerelease documentation, the features can change, and the preview targets Business Central online sandbox environments exclusively. Not production, not on-premises. The public preview runs from the first week of September until 29.0 reaches general availability in the first week of October 2026, and Microsoft will add more information at that point.

With that said, there is plenty to unpack. And where there is smoke, there is usually fire.

An AL toolset far more prepared for agents

Group some of the development news together and a fairly clear pattern shows up. Business Central 29.0 brings capabilities such as running data queries through an MCP Server, dynamic workspace configuration for AL MCP, discovery of the objects installed in a connected environment, free AL object ID allocation performed by agents, debugging of recorded failures through AI agents, profiling of slow sessions through agents, an AL Language Server independent from Visual Studio Code, AL test execution from the command line and CI/CD, and structured compiler diagnostic logs.

Taken one by one, these are improvements to AL code tooling. For writing code. Taken together, and this is the part that matters, they tell a considerably more interesting story.

Until now, a good part of the AL development experience was built around a simple premise: a developer uses Visual Studio Code, installs the AL extension and works on a project. That model remains perfectly valid. But another one now appears next to it:

agent → tools → AL language → Business Central environment

And that changes the range of what is possible. Sound familiar? It should. That is agentic programming.

MCP stops being limited to APIs that already exist

One particularly interesting item is the ability to run custom data queries through an MCP Server. Microsoft indicates that MCP applications will be able to define, validate and execute data queries even when no specific API exists yet for reaching that information.

One of the hard problems when connecting agents to an ERP is precisely controlled access to context. You may have hundreds of tables and processes, but an agent is normally limited to whatever APIs someone decided to publish.

If MCP starts providing safe, governed mechanisms for querying additional information, the space of possible solutions grows considerably. This does not mean opening the database to the agent, and reading it that way would be a mistake. The opportunity is in giving the agent semantic, controlled tools for obtaining the context it needs. Which brings me back to what I announced in the Graph Saga: mitigating what the agent does not know that it does not know.

There are also improvements aimed specifically at the AL MCP Server. It will be possible to start the server without a previously defined AL project, add projects dynamically at runtime, and use preconfigured connection details for headless scenarios without triggering authentication prompts over and over. Logging mechanisms for diagnosing MCP server activity appear too, which matters quite a lot for automation.

An agent running inside a pipeline, a CLI or a development harness should not depend on someone opening Visual Studio Code first and preparing its context by hand. Context has to be buildable, discoverable and verifiable at runtime. That small conceptual shift is what separates using AI to help write code from building genuine agent-assisted engineering systems.

The AL language server leaves Visual Studio Code

This is probably the item that interests me most. Microsoft will allow running the AL language as a standalone server, providing completion, navigation, references, rename, formatting and other project-aware capabilities outside Visual Studio Code.

It may look like a very technical change, but the consequences are significant. A language model can write AL reasonably well. The hard problem starts afterwards, and it has one name: context.

It needs to know the real symbols in the project, resolve references, understand objects, detect errors, navigate dependencies and work against the true state of the workspace. In other words, it needs language intelligence. Being able to consume that intelligence outside VS Code opens the door to other clients, other tools and, above all, development agents. It is a far more meaningful evolution than simply shipping a more powerful model.

Microsoft starts naming the agent directly

There is a detail here I find revealing. Microsoft is no longer hiding the consumer of these capabilities behind generic words like automation or developer tooling. The documentation talks about AI agents. That is not an accident.

An agent will be able to locate available IDs within the project ranges, avoiding manual checks and possible collisions. It sounds minor, and if you have worked with agents you know it is not. An agent will also be able to work on a problematic session, collect its snapshot and use it afterwards for AL debugging. And it will be able to schedule profiling, gather CPU and memory information, locate expensive AL paths and summarise SQL and HTTP activity.

This is where the conversation changes. We are no longer talking only about generating code. We are talking about agents able to take part in different stages of the engineering cycle: discover, implement, compile, test, diagnose, profile. That is much closer to a code engineering agent than to a coding copilot.

Feedback designed to be consumed by agents

Another piece of this puzzle is ALTool. Business Central 29.0 will allow using it to build, deploy and run AL test projects from scripts or pipelines, returning structured JSON with information about tests executed, passed, failed and skipped. Builds will also be able to produce structured, project-specific compiler error logs.

For a developer this improves CI/CD. For an agent it means something extra: feedback built to be consumed by agents. An agent should not have to interpret ambiguous console text when it can receive a structured response stating exactly what compiled, what failed and where. That detail will matter more and more.

AL tests evolve in the same direction, with support for more extensible, data-driven test suites: parameterised tests built on reusable data sources, and lifecycle handlers for setup, cleanup, logging, measurement and reporting. This fits a trend we keep seeing. As the amount of code generated or modified by agents grows, the need for automatic verification grows faster.

Generating faster without being able to verify faster only moves the bottleneck somewhere else.

Underneath AL, the platform moved too

Not everything revolves around agents. One of the most important platform changes affects how table extensions are stored: Microsoft introduces a model where all the fields of an AL table live in the same database table, aimed at improving the performance of operations working across extensions. It also enables something that was particularly limited until now, defining indexes that combine fields from the base table and from its extensions.

Alongside it come other useful capabilities: enabling or disabling indexes from AL, enabling or disabling SIFT indexes from Business Central, warnings when a table approaches SQL column limits, control over isolation levels in queries and Isolated Storage, and checking through Record.IsDirty whether a record holds unsaved changes.

The language itself moves as well. The one I find most interesting is the ability to provide default implementations in AL interfaces, which will allow evolving an interface with new methods without immediately breaking every existing implementation, using RequiredPending and analyzer rules to manage the transition afterwards. It will also be possible to migrate fields from Integer to BigInteger, limit global symbol resolution to a given minor version, and get clearer diagnostics when the sections of an AL object are declared in the wrong order. Less eye-catching than a new agent, and probably appreciated by anyone maintaining extensions over several years.

Outside development there is movement too. Document layouts advance towards a more composable model, with report themes, reusable headers and footers, layout lifecycle control and new Word add-in capabilities. Report packs will allow running several financial reports and producing a single PDF, either directly or scheduled through Report Inbox or email, and those outputs will be automatable through Power Automate or MCP. MCP again. Probably not for the last time.

The preview also carries functional news spread across product areas: improvements to the Payables Agent, new Expense Agent capabilities, withholding taxes in the standard, Shopify B2B evolution, tariff information synchronisation, EDI through E-Documents and Peppol BIS 3, and work on subcontracting, quality inspections, manufacturing and Sustainability Management. Several of those deserve their own analysis as the wave progresses. But my first read of 29.0 sits clearly somewhere else.

My reading of Business Central 29

We have spent some time talking about how to use agents to develop Business Central. Perhaps we should start asking the question the other way round: what would Business Central have to offer to become a platform genuinely prepared for agents to work on it?

We would need programmatic access to context. Language intelligence. Compilation. Testing. Structured diagnostics. Profiling. Environment discovery. Tools usable without a graphical interface. And mechanisms small and specific enough for an agent to use them as tools.

Review the Business Central 29.0 news and quite a few of those pieces start to appear. It is still a preview. There will be changes, limitations and a lot left to test. But the direction is becoming hard to ignore.

The future of AL development may not consist of writing AL with AI. It may consist of building an environment where specialised agents can work on AL with the same tools, context and verification mechanisms we use ourselves.

Business Central 29.0 starts putting several of those pieces on the table.