Two crafts, one blog: why I write about AI and Business Central

I do two jobs, and for a while I thought they were unrelated. They are not. They are colliding — and the collision is the most interesting place I have worked in a long time.

The first job: years inside Microsoft Dynamics 365 Business Central — writing AL, fighting AppSource validation, integrating ERP with the rest of the world. The second, like a lot of people, I picked up over the last couple of years: building with large language models — prompts, evals, gateways, the whole unglamorous stack underneath the demo.

Two pillars, not one niche

I want to be precise about scope, because it is easy to get this wrong. This blog is not only “AI in Business Central.” That framing is too small — it would quietly throw away half of what I do. So there are three kinds of posts here, and I care about all three:

• Business Central / AL engineering. The craft on its own. AppSource realities, per-tenant extensions, the AL gotchas that cost a day, integration patterns. No AI required.
• Applied AI engineering. Building with LLMs as software, not magic. Gateways, structured output, treating model responses as untrusted input, the operational stuff nobody screenshots.
• The seam. Where the two meet — Copilot extensions, document understanding, service-to-service AI from inside an ERP. This is the newest and hardest, and it inherits the failure modes of both worlds.

If you only care about one pillar, the tags will let you stay in your lane. The Business Central and AI tags are good entry points.

The order matters, by the way. I lead with Business Central because that is where I have the scars — years of AL, AppSource submissions, and integrations that had to survive a Monday morning close. The AI is newer, but it is not a hobby grafted on the side; it is the thing that keeps changing what “a good ERP feature” even means. Writing about both, in one place, is the only honest way to describe the job I actually do.

Why publish it

Two honest reasons.

The selfish one: writing a thing down forces me to actually understand it. I have lost count of the times I thought I understood a fix until I tried to explain it and found the hole. Publishing is a debugger for your own mental model.

The less selfish one: the BC community taught me most of what I know through blog posts exactly like the ones I want to write back. And the AI engineering community is, right now, unusually generous with hard-won detail. I would like to add to both, especially at the seam where there is still very little written down that survives contact with production.

What “high signal” means here

A rule I am holding myself to: every post should leave you able to solve not just the exact problem I hit, but the next variant of it on your own. That means showing the diagnosis, not just the fix — the bisection that found the real failure point, the mental model that generalizes. If a post is just “here is a config value, paste it,” I have failed.

I will write long when something deserves it, and short notes when a single gotcha is worth saving and nothing more.

That is the whole plan. The RSS feed and LinkedIn are the two ways to follow along. First real posts are already in the queue — one from each pillar.