Production · in daily use on real D365 F&O projects
From a spec — or a bug —
to a grounded solution
XppAtlas is an on-prem AI engineer for Dynamics 365 F&O. Hand it an FDD and it delivers a reviewed, ready-to-import release; hand it a bug and it traces the root cause across your standard, ISV, and custom X++ — reasoning even across compiled layers with no source. Grounded in your real code, verified before it lands, and every byte stays on your network.
On-prem · works with the agent you already use · builds and diagnoses across standard, ISV & custom# 1 — hand it a spec: → deliver "add a credit-hold flag to the customer + block posting" ? 2 questions for the BA // a vague spec doesn't stall it ✓ builds what's clear, stubs the rest — grounded in your source ✓ compiles · BP-clean → release/ ready to review and import # 2 — hand it a bug: → investigate "e-invoice sometimes rejected — no stack trace" ✓ traced: your model → ISV package (no source) → standard ✓ root cause found · fix proposed, grounded in real code
Why agents fail at X++
X++ is a niche language on a codebase no foundation model has properly seen. So the agent pattern-matches from old AX blog posts and fills the gaps with confident guesses. The fix isn't a bigger model — it's giving the agent your actual code to check against. That grounding is the foundation both jobs below stand on.
Without grounding
It guesses method names, signatures, and table fields — then writes code that fails to compile.
With XppAtlas
Every symbol is verified against the indexed source before it lands in your code.
Without grounding
It has no idea your customizations or ISV packages exist, so its answers stop at standard X++.
With XppAtlas
Standard, ISV, and your custom models are all indexed and searched in one query.
Without grounding
Change one class and you find out what broke at compile time — or in production.
With XppAtlas
Ask who calls it and what a change would touch, with the real cross-reference graph.
# Without XppAtlas: ✗ agent writes SalesTable::exists(salesId) // invented method — build fails # With XppAtlas: → check_symbol("SalesTable", "exists") ✓ exists: false · nearest_matches: exist ✓ agent writes SalesTable::exist(salesId) // verified — compiles first try
Build — from a spec to a reviewed release
Give XppAtlas an FDD or a change request. It reads it against your real standard, ISV, and custom code, asks what the spec left ambiguous, builds the rest, verifies it, and hands you a release you review and import. Nothing touches your models until you say so.
Give it the spec
An FDD or a written change request. It grounds every decision in your actual code and the standard — not a general model's memory of old AX.
It asks what's ambiguous
An incomplete spec doesn't stall it: it prepares the exact questions a business analyst needs to answer, builds everything unambiguous now, and stubs the rest to fill once the answers land — cross-checking against what's already built and the standard.
Grounded, verified, reviewed
Every symbol it writes is checked against your source before it lands; the change is compiled and best-practice-linted; the alternatives it weighed and why the chosen approach won are recorded.
A release you import
Output is a timestamped release folder that mirrors your package layout, plus an object manifest. You review the diff, copy it into your model, and build in Visual Studio — every byte stayed on your box.
Diagnose — from a symptom to a root cause
D365 bugs rarely come with a clean stack trace, and the failing layer is often an ISV package with no source. Give XppAtlas a precise repro or just "posting sometimes fails for some vendors" — it works the relation graph and the evidence to the actual cause, across your custom code, ISV packages, and standard, reasoning across compiled-only layers instead of dead-ending at the first boundary.
Understood or mysterious origin
A precise repro or a vague "it sometimes fails" — it traces to the real cause with cited evidence, not a plausible guess from an old blog.
Across compiled-only layers
When the trail runs into an ISV package with no source, it reasons across the package's public metadata to the point that matters — instead of stopping where the source stops.
Evidence, then a fix
Every step of the trace cites real artifacts in your source; the proposed fix is grounded and reviewable before anything changes.
How it works
Both jobs run on one engine, entirely on the developer's machine — no cloud upload, no per-seat agents, no IDE lock-in.
Index your dev box
XppAtlas builds a semantic, full-text, and relation-graph index from your own PackagesLocalDirectory — standard Microsoft models, ISV packages, and your customizations — for the exact D365 version you have installed.
Everything stays local
The index lives on the developer's machine and queries run there too. Code is embedded with a local model on CPU; cloud calls are off by default and never required for core search.
Agents stop guessing
Claude Code, GitHub Copilot — any MCP-capable agent gets search, call graphs, extension points, and symbol verification. Hallucinations die at the source.
Built for D365 F&O, not adapted to it
General code-search tools see XML blobs. XppAtlas understands tables, forms, data entities, security artifacts, and CoC extensions — and how they reference each other.
Anti-hallucination symbol check
The agent verifies a method, field, or enum value exists — including inherited and extension members — before it writes code that uses it. "Doesn't exist" comes back as an answer, with the nearest real match.
Grounded code generation
When the agent writes X++ or form metadata, XppAtlas checks every class, table, method, and label it referenced against your indexed source — and lints generated forms against F&O UX patterns — before the code lands. Each scaffold carries evidence lines citing what its choices are grounded in.
Semantic + keyword + graph search
Hybrid retrieval over code meaning, exact names, and the relation graph — posting class to table to form, in one query.
Extension-point discovery
CoC targets, delegates, data and form events — ranked, with callers and impact radius, so changes land where Microsoft intended.
Compiled-only models — reasoned across, not skipped
ISV layers and other "no source" models are indexed by their public metadata — types, signatures, inheritance, and extension points — read by reflection, so the agent sees them next to your X++ source. When a trail runs into a compiled layer, the agent reasons across it to the point that matters instead of stopping at the first sourceless boundary — and every byte stays on your box.
Version-exact index
Built from your own PackagesLocalDirectory, so it matches the exact build you run. After a Microsoft update, re-index and keep working — the index always reflects the source you indexed.
Model-level access control
Hide vendor or customer models from contractors. Access control is per model, with relation suppression so hidden code doesn't leak through cross-references.
Works with the agent you have
It's a standard MCP server: ready-made registration templates for Claude Code and GitHub Copilot (Visual Studio 2022 & VS Code); anything else that speaks MCP connects the same way. No proprietary IDE plugin.
check_symbolverify a method, field, or enum value exists — inherited and extension members includedsemantic_searchsimilarity search over X++ chunks — ask in plain English, get the methods that do itsearch_chunks_regexregex search over indexed source — the grep-equivalent probeexplore_artifactfull profile of an object: chunks, inbound and outbound relations, extensionsbuild_process_blueprinttrace a business process from an entry-point artifactestimate_change_radiuswhich artifacts a change would impact, before you make itrank_extension_pointsrank CoC targets, delegates, and events for an anchorreview_xpp_changereview X++ changes for common compile and runtime risksgenerate_scaffoldX++ stub scaffolds for supported template typescheck_generated_identifiersverify every symbol in generated X++ exists in your source before it landslint_form_xmlcheck generated form metadata against F&O UX patternsWhat it looks like in practice
A few real tasks an agent handles once it can see your codebase — asked in plain English, answered from your actual source across standard, ISV, and custom layers.
# "Where do we validate the customer credit limit before posting?" → semantic_search("validate customer credit limit before posting") ✓ CustCreditLimit::check() — standard ✓ ContosoCustPostInvoice::assertCredit() — your customization real methods, across layers — not an API guessed from an old AX blog
# "Run our logic after a sales line is inserted." → rank_extension_points("SalesLine") ✓ insert() — Chain of Command ranked #1 · upgrade-safe ✓ onInserted — data event alternative ranked by upgrade-safety, with callers and impact — so the hook survives the next update
# About to change InventTable::itemName() → estimate_change_radius("InventTable", "itemName") ✓ callers across Sales, Purch, and your Retail extension ✓ two CoC wrappers · one data event subscriber what the change would touch — before the agent edits, not at compile time
# Agent drafted a class that calls SalesTable::updateHeader() → check_generated_identifiers(draft, model="Contoso") ✗ SalesTable::updateHeader — not found // invented ✓ nearest: SalesTable::update // real method in your source the whole draft is verified before it's written — not at compile time
# "How does our posting hook into standard invoice posting?" → build_process_blueprint("ContosoInvoicePostController") ✓ ContosoInvoicePostController — your model ✓ └ VendInvoiceJournalPost — standard ✓ └ ISVComplianceCheck — ISV package · compiled, no source one blueprint spans custom → ISV → standard, in the order they run
It remembers why
Every task done through XppAtlas records not just what changed, but the evidence behind it, the alternatives that were rejected, and why the chosen approach won. That trail stays on your box — so the design rationale doesn't leave with the person who had it, and a change request weeks later picks up where the last one left off.
Ask why, any time
"Why is this customization shaped this way?" comes back with the recorded reason — not a guess about unfamiliar code.
Picks up weeks later
A follow-up change lands two weeks on? Hand it the doc — XppAtlas restores the task's context, the decisions behind it, and a fresh baseline, then makes the edit in line with the original intent.
Fixes respect intent
The agent sees the rejected alternatives, so it won't "fix" a bug by reintroducing a path that was deliberately avoided.
Bring existing code up to standard
Point XppAtlas at code someone else already wrote — a custom class, a batch job, a form — and it finds where a standard X++ / D365 pattern fits and proposes the change. Not generic best-practices from a blog: the patterns are drawn from how your own codebase and the standard actually do it, so the result matches the house style. Nothing is mutated blindly — changes are proposed, symbols verified, and applied through a review gate.
Idiomatic to your base
Proposes the pattern your codebase and the standard actually use — and cites where it's already used — so a reviewer recognizes it and it merges.
Upgrade-safe by construction
Overlayers become Chain-of-Command extensions; row-by-row loops become set-based; hooks land where Microsoft intended.
Grounded, not guessed
Every target symbol is verified to exist, and the analysis never leaves the developer's machine.
You don't have to be a developer to ask
Ask in plain language how a function or process works — in the standard or in your current project — and get a plain-language answer, grounded in the real code. Or describe a customization you're planning and ask the questions that decide a project: is it even possible, how hard is it, and is there a better way? The layer for consultants, analysts and leads — not just developers.
Understand it in plain language
"How does credit checking work when we post an invoice — and what did we change here?" Answered in business terms, from the real standard and your project, with no X++ in the reply.
Sanity-check before it's a ticket
Describe a planned change and get a grounded verdict: feasible or not, roughly how hard, and which paths touch nothing risky — before anyone estimates it.
Better options surface
When a standard, upgrade-safe path exists — often no custom code at all — the tool proposes it instead of the first idea.
FAQ
Common questions teams ask.
Is my code uploaded anywhere?
No. Standard, ISV, and custom models are all indexed and queried on the developer's machine — the index is built from your own PackagesLocalDirectory and never leaves it. Your custom and ISV code is embedded with a local model that runs on CPU; cloud embedding APIs are disabled by default and never required for core search. Everything runs offline after install — for fully air-gapped boxes, pre-stage the local embedding model (~400 MB), which otherwise downloads once on first use.
Does it build and fix, or just search?
Both. Search and symbol verification are the foundation, but a grounded agent takes a task end to end: from an FDD or change request it builds the customization, verifies every symbol, compiles and best-practice-lints it, and produces a release folder you review and import. Given a bug — even a vague, intermittent one with no stack trace — it traces the cause across your custom, ISV, and standard layers and proposes a grounded fix. Nothing is written to your models automatically; you review and apply through a gate.
Which IDEs and AI agents does it work with?
XppAtlas is a standard MCP server. Claude Code and GitHub Copilot in Visual Studio 2022 and VS Code ship with ready-made registration templates; any other MCP-capable agent connects the same way. There's no proprietary IDE plugin — you keep your existing setup and add XppAtlas as an MCP server in the agent's configuration.
Does it understand our customizations?
Yes. Your custom and ISV models are indexed from your local PackagesLocalDirectory the same way standard code is: full-text, semantic, and cross-reference. The agent searches across all layers in one query — for example, tracing a posting flow from your extension through an ISV class down into standard code.
How does it stay current with our D365 version?
The index is built from your own PackagesLocalDirectory, so it reflects the exact build you have installed. After a Microsoft update or a new deployment, re-index — incremental re-indexing only reprocesses what changed — and the agent is grounded in the new source.
What does setup require?
Python 3.11 or newer on the developer's machine and read access to your PackagesLocalDirectory. One pip install (~3 minutes), then indexing your custom models runs 5–10 minutes, once. XppAtlas reads metadata XML and X++ source from disk — no AOS access, no database access, and no changes to your D365 environments.