AI × Business Central
I work on two things that are colliding: Microsoft Dynamics 365 Business Central and applied AI. I write about AL and ERP engineering, about building with LLMs, and about the increasingly interesting place where they meet — always from what actually ships, not the demo.
Start here
Latest writing
All posts →-
Your Business Central MCP server should be read-only until it can't be
The Business Central MCP server is GA-adjacent and the pitch writes itself: connect Claude or Copilot Studio, read and write ERP data in natural language, no custom API. The connection is the boring part. You've just handed a promptable, nondeterministic actor a write path to your ledger — and the only thing standing between it and a posted document is how you configured it.
-
When NOT to use an AI agent in Business Central
The built-in agents are GA and every partner is asking 'can an agent do this?' That's the wrong question. For a large class of BC work, a deterministic codeunit beats an agent on cost, latency, and auditability — and picking the agent anyway is a downgrade dressed as innovation.
-
Your AI feature must run on a fresh tenant, or it doesn't run
The line between a demo and a product is whether it works on a clean Business Central environment with none of your developer setup. Five concrete things that separate 'works on my box' from 'a customer can actually use it'.
-
Shipping a Copilot feature in Business Central that survives real users
A PromptDialog demo takes an afternoon. A Copilot feature real users won't switch off takes the other 90%: scoping, grounding, the generate–review–accept loop, and treating the model's output as a proposal that never silently touches data.
-
The breaking changes you can't see coming (and how AppSourceCop saves you)
Renaming a field, hiding an action, deleting an unused procedure — harmless refactors in most codebases, all breaking changes in an AppSource extension. LC0034 catches them late. Here's the rule that keeps you clean.