Business Central 29 AI Agents Can Allocate Available AL Object IDs

Microsoft's AI at Work roadmap entry 573346, titled "Dynamics 365 Business Central: Development - Let agents allocate free AL object IDs", says coding agents can find available IDs for AL objects and extension objects within a project's ranges. The goal is fewer manual range checks and fewer collisions with objects the project already declares. The entry is marked Launched for General Availability on the Worldwide (Standard Multi-Tenant) cloud, lists the web platform, and gives October 2026 as the general availability date.

It's a small feature. It still fixes one of the most common sources of avoidable compile errors in AL development.

What Microsoft actually announced​

The roadmap entry is short, so here is everything it claims:

• What it does: Coding agents can find available IDs for AL objects and extension objects inside the project's ID ranges.
• The problem it targets: Manual range checks, and collisions with objects already declared in the project.
• Scope limit: Only IDs in the connected environment are considered.
• Microsoft's stated value: Agents can scaffold AL objects without reading ID ranges by hand, which should make generated code more reliable and cut the fixes needed before it compiles.

Microsoft says its AI at Work roadmap gives estimated release dates and descriptions, and that all of it can change. Treat the October date as Microsoft's target, not a promise that every tenant has the feature today.

Where it fits: Business Central 29.0​

Independent coverage places the feature in the Business Central 29.0 release cycle. TechSphere Dynamics, writing about the 29.0 preview documentation, listed among the release's capabilities 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. The same list includes agent-driven debugging and profiling, an AL Language Server that runs independently of Visual Studio Code, command-line test execution, and structured compiler diagnostic logs.

TechSphere also gave a timing caveat: the preview targets Business Central online sandbox environments exclusively. Not production, not on-premises. It said the public preview runs from the first week of September until 29.0 reaches general availability in the first week of October 2026, which matches the roadmap's October 2026 date.

Section summary: This is one piece of a larger 29.0 effort to make AL tooling work for agents as well as people. It is aimed at the multi-tenant cloud and scheduled for general availability in October 2026.

Why object IDs trip agents up​

AL extensions declare their allowed ID ranges in app.json, the extension manifest. Microsoft's documentation describes two settings, idRange and idRanges, and says you must use one or the other. Any object outside the declared range causes a compilation error. With idRanges, overlapping ranges are not allowed and also fail compilation.

The error you'll see is AL0297. Microsoft's diagnostic page says it fires when an object's ID falls outside the ranges declared in app.json. The documented fixes are to move the object's ID into an existing range or to extend the range in the manifest. The example uses the per-tenant extension band of 50,000–99,999, with a sample range of 50,100 to 50,149.

Microsoft's object-range documentation explains the wider numbering scheme:

Microsoft now advises new publishers to request an App Object Range rather than an RSP range.

An agent creating a table extension, a page and two codeunits in one pass has to respect the manifest's ranges and avoid every ID the project already uses. If it guesses wrong, the result is a compiler error and another round of fixes. Microsoft's existing agent tools can already detect compile failures and retry, but avoiding the bad ID in the first place is cheaper than recovering from it.

Section summary: The manifest's range is a hard rule enforced by the compiler. An agent that knows which IDs are free can skip a whole category of errors.

How it fits with the existing AL agent tools​

Microsoft's 2026 release wave 1 plan, "Use AI agent tools for AL development", has general availability dates of April 3, 2026. It describes tools that let GitHub Copilot and any Model Context Protocol (MCP)-compatible agent build, publish, search symbols, run diagnostics and debug AL extensions. They are available in two places:

• Visual Studio Code Language Model Tools, used by GitHub Copilot in agent mode
• The AL MCP server (almcp), a standalone server launched through altool launchmcpserver for headless environments, CI/CD pipelines and agents running outside VS Code

Existing tools include al_build, al_compile (MCP only), al_publish, al_downloadsymbols, al_symbolsearch, al_getdiagnostics and several debugging tools that only work in VS Code. Microsoft says the tools can detect compile failures and suggest next steps, so an agent can keep iterating until the code compiles.

ID allocation fills an obvious gap in that set. Agents could build, compile and diagnose, but choosing a valid number was still up to them. One thing remains unconfirmed: Microsoft has not said which surface or tool name exposes ID allocation. The roadmap entry lists only "Web" as the platform, so don't assume a specific tool name or VS Code command until Microsoft documents one.

The fine print: what "free" means​

The phrase "only IDs in connected environment are considered" carries most of the weight in this announcement.

It means:

• The agent checks against the project's declared ranges.
• It avoids IDs already used in the project and the connected environment.

It does not mean (at least nothing published says so):

• A global registry of IDs across all your environments
• Coordination between developers working on separate branches
• Checks against AppSource apps that aren't in the connected environment
• Any guarantee that the generated code compiles

That last point matters for teams. A developer on one branch and an agent on another can still pick the same "free" ID if neither one's work exists in the environment the other is connected to. The community has worked on this for years. Microsoft MVP Vjekoslav Babic's AL Object ID Ninja promises "zero-configuration, dead-simple, no-collision object ID assignment for multi-user repositories." Other tools take a similar approach. One agent skill published on Skills.lc lets agents allocate the next available Business Central AL object ID/number by scanning .al files and idRanges in app.json using the bundled PowerShell script.

The AL extension can also suggest IDs already. Microsoft's manifest documentation says an ID is suggested automatically when you create new objects. Business Central MVP Yun Zhu has shown that pressing Ctrl+Space where the object ID goes brings up the suggestion. He also noted a limitation: if you add the dependencies property and download the symbol file, this will not check for object IDs in other extensions.

My read, based on general industry experience rather than Microsoft documentation: the new feature is probably closest to that built-in suggestion, packaged so an agent can call it, plus awareness of the connected environment. It isn't a replacement for a team-wide ID reservation system. If your team already uses one, keep it.

Section summary: The agent can avoid collisions it can see. Collisions it can't see, such as other branches, other developers or unconnected environments, are still your problem.

Practical checklist for AL teams​

If you use Copilot agent mode or an MCP-based agent for AL work, here's how to get value from the feature:

1. Check app.json first. The feature looks inside project ranges, so a wrong range means the agent will reliably pick IDs from the wrong range. Use either idRange or idRanges, not both, and make sure ranges don't overlap.
2. Use the right band. Per-tenant work goes in 50,000–99,999. AppSource apps use their assigned range. Never use 0–49,999 for extension objects.
3. Point the agent at the right environment. Free IDs are calculated against the connected environment, so connect to the sandbox that reflects your project's real state.
4. Review the IDs in pull requests. Business Central 29.0 was in sandbox-only preview through September, and Microsoft hasn't documented how the agent chooses among multiple ranges or whether you can override its choice.
5. Be careful with published objects. Microsoft's AppSourceCop guidance (rule AS0013) says objects already in your baseline version can't simply be renumbered. They have to be marked obsolete and replaced. An agent fixing a range error must not renumber shipped objects.
6. Keep team-wide coordination in place. For multi-branch or multi-developer repositories, the connected-environment check doesn't replace shared reservation tooling.

The bottom line​

Roadmap item 573346 is not a headline feature, and Microsoft doesn't pretend it is. It addresses a real annoyance: agents that write good AL code and then give a table an ID that is already taken or out of range. With general availability set for October 2026 alongside Business Central 29.0, and the existing build, diagnostics and MCP tools already shipped, Microsoft is clearly building AL tooling that agents can use end to end.

Microsoft's word "allocate" suggests more than the feature delivers. It finds open IDs in the environment you're connected to; it doesn't reserve them across your organization. Developers who keep that distinction in mind will get fewer compile failures. Teams that treat it as a full ID management system can still end up with two objects fighting over the same number after a merge.