An Advanced Dungeons & Dynamics 365 session. Episode 2 of 14.
Previously on:Episode 1, The Summons at Waterdeep Docks, the party arrived at Contoso Coffee Roasterie to find a missing scope document, a go live date that had quietly moved up by six weeks, and a whiteboard asking a question nobody could answer: where is the margin going.
Every implementation has an official system of record. And every implementation, if it’s been running long enough, has an unofficial one too. Usually a spreadsheet. Usually built by someone who got tired of waiting for the real numbers to be right.
That’s where episode two picks up.
The Session
GM: In the war room you meet three Contoso stakeholders: the CFO, the head of Ops, and a woman named Priya who nobody introduces by title.
Sable:(casting Data Mapping) I’m getting margin data. It’s coming from… this isn’t the ERP. This is a workbook.
Priya: That’s mine. I’ve been tracking real margin since the system doesn’t roll up freight variance correctly.
Marge: How long has this shadow ledger existed?
Priya: Since the first go live attempt. Fourteen months.
Thorne:(rolling a Perception check) The workbook total and the GL total are six figures apart.
Vex: Which one’s right?
Priya: I don’t know anymore. I leave for vacation tomorrow.
Ai. Cassiopeia: I would like it noted that I offered to reconcile this in October. The ticket was closed as “won’t fix, not urgent.”
The CFO leans over Thorne’s shoulder to look at the variance number. He goes pale in a way that has nothing to do with the lighting.
CFO: That number is bigger than our reported profit.
Nobody says anything for a moment. Priya starts quietly packing her laptop bag, the way someone packs when they’ve decided this is no longer their problem to solve, whether or not that’s actually true.
Priya:(standing) My flight’s at six tomorrow morning. I really am sorry.
Why the spreadsheet always wins
Every consultant who has done this work long enough has met a Priya. Somebody who didn’t set out to build a shadow system, they just needed the numbers to be right for a meeting, and the ERP wasn’t giving them right numbers fast enough. So they built a workaround. Then the workaround became a habit. Then the habit became fourteen months of institutional memory that lives entirely on one person’s laptop, reconciled by hand, understood by nobody else in the building.
This isn’t a story about a bad employee cutting corners. It’s what happens when a system doesn’t earn trust fast enough, and a business still has to make decisions in the meantime. Priya’s spreadsheet isn’t the failure. It’s evidence of a failure that happened somewhere upstream, probably long before she ever opened Excel.
The dangerous part isn’t that the spreadsheet exists. It’s that nobody in the room can currently say which number, the workbook or the GL, is actually correct. Six figures of ambiguity, and the person who understands the discrepancy best is getting on a plane in twelve hours.
That’s not a data problem anymore. That’s a continuity problem. And it’s the kind of gap that a proficiency system is supposed to catch long before it turns into a war room moment.
What happens next
Priya is gone by morning, and the shadow ledger goes with her, at least in terms of anyone who can explain it. The party has six figures of unexplained variance, a CFO who now can’t unsee the number, and a chart of accounts they haven’t even looked at yet. In the next episode, they go looking for where the discrepancy actually lives, and find a financial dimension that’s been quietly absorbing thousands of postings that were never supposed to exist.
Next episode: Episode 3, The Labyrinth of Financial Dimensions (coming soon)
A quick gut check for anyone running their own ERP: is there a shadow spreadsheet keeping your business honest right now? Gamifying the Enterprise: Game Mechanics for Continuous Proficiency digs into exactly why that happens, and how to design proficiency systems so it stops. Available on Amazon: https://www.amazon.com/dp/B0GY3VWLVX
And if you want the actual configuration playbook behind scenes like this one, start here: adnd365.com/start
Cause of death: the feature that closed the deal was never actually in the room.
Somewhere around minute forty of the demo, the presenter hits a gap. The thing you actually asked about, the reason you took the meeting, doesn’t quite exist yet. What happens next is the tell. The slide doesn’t say “we don’t do that.” It says “coming in the next release,” said in exactly the same tone of voice as everything that already works, with exactly the same confident click-through pacing, so that by the time the meeting ends, the feature that doesn’t exist has fully merged in your memory with the fifteen features that do.
Nobody lied. That’s what makes this one interesting to cut open. The roadmap slide was real. The quarter listed on it might even be accurate, as of the day the deck was built. And yet the effect on the room is functionally identical to a lie, because a promise wearing a product demo’s clothing gets evaluated with a product demo’s scrutiny, which is to say, almost none.
What actually happened
Every roadmap item in a sales deck starts life as an engineering estimate, gets filtered through a product manager’s optimism, gets filtered again through a sales engineer who needs this quarter’s number, and arrives in front of you as a single, confident bullet point that has shed every unit of uncertainty it was born with. “Q3” meant “Q3, if the two prerequisite features land on time and nothing gets reprioritized” back at the whiteboard where it was written. By the time it’s read aloud in your conference room, it just means Q3.
The demo compounds this by never distinguishing, in pacing or tone, between the click that shows something real and the click that shows a mockup of something planned. Both get the same enthusiasm. Both get the same “and here’s where you’d.” The interface doing the showing doesn’t have a font for “this is a Figma file with a database connection painted on.”
You are, in effect, being shown two different products stitched into one seamless walkthrough: the one that ships today, and the one that exists only as a commitment on a slide, and you’re being asked to make one buying decision that covers both.
Why it works on smart people
Buyers are trained, correctly, to evaluate a vendor’s direction and not just their current state. Nobody wants to buy a system that solves today’s problem and ignores next year’s. So a roadmap conversation is a legitimate, necessary part of due diligence. The trick isn’t the existence of the roadmap. It’s the demo borrowing the roadmap’s credibility and lending it back to itself.
There’s also a timing problem working against you. The roadmap feature is almost always introduced as the answer to the exact gap you just identified in the product, which means it lands at the precise moment you’re feeling a little disappointed and looking for a reason not to be. “Coming in Q3” isn’t just information at that point. It’s relief, and relief is a bad state to be evaluating claims in.
The actual damage
This is the one that shows up on a signed contract with a footnote nobody reads until it matters. Somewhere a business case got built with the roadmap item load-bearing in it, sized as though it were a current-state capability, because in the meeting it felt like one. The actual purchase decision, the one with budget and a signature attached, priced in a feature that was, at signing, a Jira ticket with a target quarter next to it.
Q3 arrives. The feature either doesn’t ship, ships in a reduced form that solves half the original problem, or ships correctly but a year later, after a reprioritization nobody outside the engineering org heard about. Your business case, however, was built on the version of the feature that existed only in the demo room, and now someone has to explain to their own leadership why the thing everyone signed off on isn’t the thing they got.
The vendor isn’t necessarily acting in bad faith here. Roadmaps genuinely slip, for genuinely defensible reasons. But “the vendor wasn’t lying” is cold comfort to the person holding a business case that assumed a delivery date as fact.
The fix, if you’re the one presenting
Change the font, literally or figuratively, the instant you cross from shipped to planned. A different slide background, a verbal flag, a pause, anything that makes the seam audible. Say the confidence level out loud: “this is committed and in QA,” versus “this is prioritized but not yet started,” versus “this is directionally where we’re headed and I wouldn’t bet a contract on the date.” Those are three different products. Let the buyer evaluate them as three different products.
It costs you a little bit of momentum in the room. It buys you a customer who signs with accurate expectations, which is the only kind of customer who’s still happy with you eighteen months later.
The roadmap wasn’t the lie. The seamlessness was.
I’ve argued elsewhere that no self-respecting architect leaves the scaffolding up once the building is done. A roadmap slide is the one place I’d argue for the opposite: leave the scaffolding very visible, since half of what’s on screen hasn’t been built yet.
Cause of death: nobody asked what the prompt actually did.
The setup is always the same. The presenter opens a chat panel next to the application. Types a sentence, something like “create a purchase order for our top vendor and route it for approval.” Hits enter. Three seconds later, a purchase order exists, fully populated, correctly routed, and the room exhales the specific kind of gasp that sales decks are built around.
Nobody in the room asks the only question that matters: what happened between the sentence and the purchase order.
That’s the autopsy. Not whether the AI worked. It worked. The patient died of the room’s collective decision not to look inside the box.
What actually happened
There are, broadly, three things that could have occurred in those three seconds, and they have wildly different implications for what you’re buying.
The prompt could have triggered a genuinely flexible model reasoning over your live data and your actual configuration, in which case, remarkable, and worth every follow-up question you can throw at it. Or it could have matched against a narrow, pre-built intent, one of a finite list the vendor trained and tested specifically for this demo, in which case the “AI” is doing roughly what a well-labeled button would do, dressed in a chat window. Or, and this is the quietly common one, it could have worked because the demo environment was built so there was exactly one top vendor, exactly one approval path, and exactly one plausible interpretation of the sentence, which means the model didn’t have to be smart. It had nothing to be confused by.
You cannot tell these three apart from the audience seat. That’s not an accident. It’s the format working as intended.
Why it works on smart people
Chat interfaces borrow credibility from every other chat interface you’ve ever used. You already know how to type a sentence and get a reasonable response, because you do it daily with a general-purpose assistant that genuinely is flexible. The demo imports that trust wholesale and applies it to a narrow, scripted intent recognizer that shares none of the underlying capability.
There’s a second layer, too. Asking “what exactly did the model do” mid-demo feels like a strange thing to interrupt with, technical in a way that makes you look like you’re missing the point of the show. So the room lets it go, same as it lets the Golden Path Demo’s pristine data go. The social cost of asking is higher than the informational value anyone expects to get from asking, so nobody does, and the vendor never has to answer a question nobody asked.
The actual damage
This is the one that costs real money, because “AI does it for you” gets sized into the business case. Someone in procurement multiplies the demo by the number of purchase orders your company cuts in a year and arrives at a headcount reduction that made it into a slide before a single production prompt had been run against a real vendor master with your actual data quality problems in it.
Then go-live happens, and the model that flawlessly handled “our top vendor” in the demo turns out to need a disambiguation step for the fourteen vendors named some variant of “Smith Industries” in your real vendor table, and the “flexible AI agent” turns out to be a narrow intent match against six pre-built scenarios, and scenario seven is where your actual business lives.
The gap between what was promised and what shipped doesn’t show up as a bug. It shows up as a quiet, expensive redefinition of what “handled by AI” meant, discovered by whoever now has to explain the missed headcount number.
The fix, if you’re the one presenting
Show your work, on purpose, before anyone has to ask. After the prompt returns its clean result, pull back the curtain for ten seconds: here’s the intent it matched, here’s the data it pulled from, here’s what happens if the vendor name is ambiguous. If the honest answer is “the model reasoned over live data,” say that, and let it be more impressive for being specific. If the honest answer is “this is a pre-built scenario for the categories we support today,” say that too. A buyer who knows exactly what they bought doesn’t come back angry in month four. A buyer who assumed general intelligence and got a narrow, well-executed lookup does, and they remember whose demo sold it to them.
The trick was never the model. It was the silence right after it worked.
If the “narrow intent versus genuine reasoning” distinction sounds familiar, it’s the same fault line I dug into in Is Headless ERP Enough, or Just a Step in the Right Direction?, on what it would actually take for AI to be the architecture instead of a coat of paint on top of it.
An Advanced Dungeons & Dynamics 365 session. Episode 1 of 14.
Every consulting engagement has an origin story. Most of them start with a kickoff call, a signed SOW, and someone on the client side saying “we’re really excited to get started” in a tone that suggests they are not.
This one starts at the docks, at dawn, with a folder that’s still warm from the printer.
Welcome to the Contoso Convergence. This is the campaign we’re running here on the blog: a full Advanced Dungeons & Dynamics 365 session, told in fourteen episodes, following a five person party sent to rescue a D365 Finance & Operations go live that has already failed twice. If you’ve ever lived through a stalled implementation, you’ll recognize the dungeon. We’ve just given it a party and some dice.
Here’s the party, for reference:
Thorne Ledgerkeep, Paladin (Functional Consultant, Finance). Cannot tell a lie about a trial balance. Weak against scope creep.
Vex Nullpointer, Rogue/Artificer (Technical Consultant). Picks locks on legacy integrations. Allergic to undocumented customizations.
Sable Query, Wizard (Solution Architect). Casts Data Mapping at range. Vulnerable to “just one more report” requests.
Captain Marge Dunwell, Fighter (Project Manager). Frontline tank. Immune to fear, mostly immune to steering committees.
Ai. Cassiopeia, grey collar party member, an AI agent bound to the Wayfinder’s Network. Casts Copilot Suggestion. Cannot be blamed in the retro, which everyone resents.
They work for the Waterdeep Trading Company. Their assignment: Contoso Coffee Roasterie, a mid market roaster whose D365 go live has now stalled twice, and whose current state can be summarized by one line on a whiteboard that nobody has erased.
Let’s begin.
The Session
GM (Dessa, dispatching the party): Contoso Coffee Roasterie. Third go live attempt. The first two consultants who touched this engagement now work in agriculture. You leave at dawn.
Thorne: What’s the scope?
GM: That’s the thing. Here’s the SOW. It’s forty one pages. Page seventeen is missing.
Vex:(flipping pages) Page seventeen is always the page with the integration list on it. Always.
Sable: I’ll cast Data Mapping when we arrive. Can’t do it blind.
Marge: Team, standard rules. We document the golden path, we do not perform the golden path. If Contoso’s demo deck has a slide that says “and then the order just flows through,” that slide is lying to us.
Ai. Cassiopeia: I have ingested the prior two consultants’ status reports. Both end mid sentence.
The party arrives at Contoso’s gates. The receptionist hands Thorne a folder. It is warm, as though recently printed in a panic.
Receptionist: They’re expecting you in the war room. Also, go live is in six weeks.
Thorne: The SOW says twelve.
Receptionist: That was the old go live date.
The party is led down a hallway that smells faintly of burnt coffee and cold pizza. Someone, at some point, taped a printed banner to the wall that reads “WE ARE ALMOST THERE.” Someone else has crossed out “ALMOST” and written “NOT” above it in marker.
The war room door creaks open. Inside, a whiteboard covered in red ink reads only:
“WHERE IS THE MARGIN GOING.”
No question mark. Nobody in the room has energy left for punctuation.
Why this scene, why first
Every stalled implementation has a version of this moment: the point where a new team walks in and the first thing they learn is that the paperwork doesn’t match the reality on the ground. A missing page seventeen. A go live date that’s moved without anyone updating the SOW. A room that’s been living inside the same unanswered question for months.
None of that is dysfunction, exactly. It’s what happens when a project runs long enough that the documentation stops keeping pace with the truth. The SOW says twelve weeks because that’s when someone last had time to update it. The scope says one thing because rewriting it would mean admitting how much has drifted. Nobody’s lying. Everybody’s just too busy surviving the current sprint to fix the paper trail.
Marge’s line matters here, and it’s the whole thesis of this campaign: document the golden path, don’t perform it. A demo that only shows the happy path teaches the team nothing about the exceptions they’ll actually live in. That’s not a throwaway rule for a fictional party. That’s the difference between a go live that holds and a third failed attempt.
We’ll come back to that idea more than once over the next thirteen episodes.
What happens next
The party has a whiteboard, an unanswered question, and a go live date that just got six weeks shorter. In the next episode, they meet the Contoso stakeholders, including a woman named Priya who nobody introduces by title, and the party learns that somebody has been quietly running the real numbers in a spreadsheet the entire time.
Next episode: Episode 2, The Shadow Ledger (coming soon)
If any of this feels familiar, that’s on purpose. This campaign is built on the same framework behind Gamifying the Enterprise: Game Mechanics for Continuous Proficiency, available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX
And if you want to run something like this for your own team, not the dragons, the actual configuration, the AD&D365 guides are the place to start: adnd365.com/start
Nobody has ever finished a day of data entry in an ERP system and felt like they’d been playing a game. That’s the problem gamification tries to solve, and after years of poking at enterprise systems, I’ve become convinced it’s one of the more underrated levers for actually getting people to use the software correctly.
The pitch
Gamification means borrowing the mechanics that make games compelling: points, badges, levels, progress bars, leaderboards, and bolting them onto tasks nobody would otherwise choose to do carefully. In an ERP context, that might mean a purchasing clerk earning a badge for zero-error PO entry for a month, a warehouse team seeing a live leaderboard of pick accuracy, or a new hire working through a “level up” onboarding path instead of a 40-tab training binder.
It’s not a gimmick dreamed up by a UX consultant with too much time on their hands. There’s real academic backing here. A well-cited study built a gamification prototype on top of SAP ERP and tested it with 112 users using the standard technology acceptance model; enjoyment, flow, and perceived ease of use all improved meaningfully. Another case study found that adding game mechanics to SAP increased user “telepresence” (basically, how engaged people felt while using the system) by nearly 30%. The underlying research consistently shows gamified ERP leads to better data entry and fewer errors, which, if you’ve ever had to clean up a mangled inventory count, is not a small thing.
Why now
The gamification market broadly is expected to roughly double by the early 2030s, and enterprise software is a big part of that growth. What’s changed recently is the mechanism. The old playbook was static: points, badges, a leaderboard bolted onto the sidebar, forget about it. The new playbook is AI-driven, with personalized nudges, dynamic feedback loops, and coaching that adapts to what an individual user is struggling with rather than a one-size-fits-all reward ladder. Microsoft’s Power Apps approach is a good example of the direction things are heading, embedding game-like mechanics directly into workflows rather than treating gamification as a bolt-on layer, which cuts rollout time from months to weeks.
HR and training modules are seeing the fastest uptake, which makes sense. That’s the part of ERP most people already expect to feel like a course rather than a chore, so it’s the easiest wedge for game mechanics to get in the door.
The catch
Here’s the part worth sitting with before you get excited and start slapping badges on every screen: a huge share of gamification efforts flop. The research puts the failure rate at around 80% when organizations default to generic points and leaderboards without actually designing for the behavior they want to change. A leaderboard that just measures raw transaction volume will train people to enter data fast and sloppy, not accurately. Badges nobody respects become wallpaper. And gaming mechanics don’t land the same way with every personality; some people are motivated by competition, some by mastery, some find the whole thing patronizing. The smart implementations keep traditional training and recognition paths alongside the gamified ones rather than replacing them outright.
Legacy systems are also a real drag here. If you’re still running SAP ECC or an older on-prem instance, bolting gamification on top usually means custom middleware, which stretches timelines and adds a maintenance burden nobody budgeted for. It’s a much easier build on modern cloud ERP with decent APIs.
The tinkerer’s takeaway
If I were experimenting with this on a real system today, I’d start narrow. Pick one painful, error-prone workflow, define the specific behavior I actually want to reinforce (not just “more activity”), and build a small feedback loop around that: a progress indicator, a streak counter, something visible and honest. Skip the company-wide leaderboard until you’ve proven the mechanic works on a small team that won’t quietly resent it.
ERP software has a reputation for being where enthusiasm goes to die. Gamification isn’t going to fix bad process design or a system nobody wanted in the first place, but done with a little more thought than “add badges,” it’s a genuinely useful tool for making the boring but important parts of enterprise software a little more bearable.
If you want help thinking through where gamification actually fits in your own ERP rollout, that’s exactly the kind of thing I help people work through. Get in touch at adnd365.com/start.
I’ve been building and implementing ERP systems for a long time. Most of them share the same skeleton underneath: a monolithic database that owns the authoritative state, application code layered on top to enforce business rules, and a UI wrapped around the whole thing so humans can interact with it.
That pattern has served enterprise operations well for thirty years. It’s proven, stable, and deeply integrated into how organizations run.
Headless ERP Is Real Progress – and a Useful Stepping Stone
The industry’s shift toward headless ERP is a genuine improvement. The pitch is compelling: decompose the monolith, expose business capabilities as APIs, and let any interface – web, mobile, AI copilot – consume them. This breaks the tight coupling between the UI and the data, which creates real flexibility.
But it’s worth being clear about what headless ERP changes and what it doesn’t.
The database is still the authoritative system of record. The business logic is still baked into the same application layer. What’s changed is that the user interface abstraction has moved one level up the stack. An AI agent now calls the same procedure that a form used to call. The underlying state management, the write model, and the integrity model are largely the same.
That’s a meaningful evolution. It’s just not the same thing as rethinking the architecture from the ground up. The major ERP vendors are building AI agents, tool APIs, and conversational interfaces as fast as they can – and those capabilities are genuinely valuable. But in most cases, the mutable relational database remains the authoritative core. AI is a new interaction layer, not a new architecture.
What Would a Truly AI-Native ERP Look Like?
That raises a useful design question: if we weren’t constrained by the existing architecture, what would we actually need an ERP to do?
An ERP needs to:
Record that business events happened and cannot be undone
Derive current state from those records
Enforce rules about which events are permitted
Report on any slice of history or current state
Coordinate with other parties and nodes
Notice that “store mutable rows in a relational schema” is not in that list. That’s an implementation choice that has become a deeply embedded assumption – but it isn’t the only one available.
What if the ledger was the database?
Not a blockchain. Not distributed consensus. Not tokens. Just immutable, append-only, typed records – structured text that any human or machine can read, that hashes itself into a verifiable chain, and that never requires a rollback because facts don’t change, only new facts get added.
I’ve been building exactly this. The prototype uses plain Markdown files as the authoritative store. Every business posting – a journal entry, an inventory movement, a document – is a Markdown file containing machine-canonical JSON and human-readable context. There is no database. Current state is a projection, rebuilt from the ledger on startup and kept live in memory. The only write is an atomic append.
Fifty-seven passing tests cover balanced accounting, inventory authority, immutable document chains, verified replication, disconnected-node convergence, and same-origin fork rejection. The balance sheet balances. The inventory reconciles. Two disconnected nodes post independent transactions and converge without conflicts – without any consensus protocol.
AI Becomes the Only Interface
Here’s where the architecture shift becomes genuinely interesting.
In a ledger-first, text-native ERP, there is no form to fill out. There is no screen to navigate. There’s a typed command interface and a set of hard invariants. An AI agent – or a human typing natural language – submits an intent. The system validates it against policy, checks the invariants, and either appends an immutable record or returns a precise rejection.
The UI doesn’t exist until it needs to exist. When a warehouse manager asks “what’s on hand at site B?”, the answer is a live projection query. When a CFO asks “show me the aging receivables by customer segment”, that’s a reporting query – constructed dynamically against the ledger, not a pre-built report someone maintained for years. When a purchasing agent says “draft a PO for the coffee beans I bought last quarter at the same price,” the AI reads the ledger history, constructs the command, and submits it for approval.
There’s no screen configuration. There’s no report builder. There’s no workflow designer. The AI is the interface, the report, and the workflow – and the ledger makes sure it can’t lie about the numbers.
Policies Are the Contracts, Not Code
The hardest part of any ERP implementation isn’t the software. It’s the rules: approval thresholds, posting profiles, accounting mappings, regulatory requirements, credit limits. In traditional ERP these are baked into configuration tables, workflow definitions, and custom code – all of which require IT to change and none of which an AI can inspect or reason about directly.
In a ledger-first design, policy is a first-class ledger record.
An approved policy revision is itself immutable, effective-dated, and hash-linked. It says: “For purchase orders above $10,000, two approvals are required, and the expense must post to account 6100.” That policy record is readable by both the enforcement engine and an AI agent explaining a rejection. When the CFO updates the threshold, a new policy revision is posted to the ledger – the old one doesn’t disappear, it simply becomes historical. You can audit every rule change the same way you audit every financial transaction.
The objects – products, customers, accounts, locations – are extensible definition records, not schema columns. Adding a new attribute to a product doesn’t require a database migration. It’s a new field in the next definition revision. The schema is the business model; the ledger stores the evolution of the business model alongside the business events.
A Different Starting Point
This model raises questions worth sitting with, especially for architects and business leaders thinking about long-term platform choices.
If the authoritative store is a text ledger that any AI can read directly, the relationship between data and the systems that manage it changes. If policy is data rather than embedded configuration, it becomes inspectable and auditable in ways that configuration screens aren’t. If the UI is assembled dynamically rather than maintained as a static artifact, the cost of adapting to change drops.
Existing ERP platforms are adding AI agents, tool APIs, and conversational interfaces at a rapid pace – and those are genuine improvements on top of proven foundations. The question this architecture raises isn’t whether those platforms have value. They clearly do. It’s whether the database-first foundation is the only viable path, or whether there are scenarios where a ledger-first approach offers distinct advantages.
What I’m describing is a different starting point – not a replacement for everything an ERP does today, but an exploration of whether the database-first model is the permanent default or one point on a longer architectural trajectory.
What This Isn’t
To be direct about what I’m not claiming:
This is a prototype. It has 57 passing tests, not 57,000 customers. It doesn’t have digital signatures, authenticated transport, encryption, crash recovery, or performance benchmarks at scale. The hard work of production ERP – currencies, taxes, period close, consolidation, regulatory certification – hasn’t been done.
I’m also not claiming that organizations should abandon well-functioning ERP implementations. For continuously connected operations under one administrative authority, a traditional ERP database remains a strong and well-understood answer.
But for organizations that need:
Independent nodes that operate offline and converge later
AI governance with a hard execution boundary and auditable decisions
Extensible business objects without vendor schema lock-in
Deterministic history reconstruction – what was true on day one through today
Policies as auditable data – not configuration only IT can change
…the ledger-first, AI-native model deserves serious evaluation. It’s not a theoretical construct. The balance sheet balances. The inventory reconciles. The tests pass.
The Question Worth Asking
The ERP industry’s investment in AI capabilities is accelerating. In most implementations today, those capabilities are built as interfaces to the existing architecture. The database is still authoritative, and AI is the new interaction layer.
What if the AI wasn’t the client – what if the ledger was, and the AI was one more authorized agent submitting typed, policy-governed commands alongside the humans?
That’s not headless ERP. That’s a different architecture.
I’m writing this as someone who has implemented ERP systems commercially and is now prototyping an alternative architecture – not to sell a product, but to test whether the assumptions we’ve been building on are as permanent as we’ve treated them.
The source code, architecture specification, and worked scenarios are in an active research project. Happy to dig into specifics in the comments below.
For years, expertise was measured by how much you knew.
The best ERP consultants could recite configuration settings from memory. They knew which parameters to enable, where to find the obscure options, and how one setting quietly broke another three modules over. Experience meant accumulating answers.
AI changes that.
Today, the answer is often seconds away. Ask an AI how to configure inventory dimensions, build a procurement workflow, design a chart of accounts, or set up a security role, and you’ll get a reasonable starting point. Often it will just generate the configuration itself.
So does that make years of ERP experience less valuable?
Quite the opposite.
The Skill Has Shifted
The value was never really in typing values into a form. It’s in knowing what the business actually needs, translating that into the right request, catching it when AI makes the wrong assumption, and steering it back to the correct solution.
Think of AI as the world’s fastest configuration specialist. Tell it exactly what you want, and it will produce an impressive amount of work in very little time. Give it a vague or incomplete request, or one built on a misread of the business, and it will build the wrong thing just as fast. Faster, in fact, than any consultant ever could.
The consultant’s role hasn’t disappeared. It has moved up a level.
Instead of asking “How do I configure this?” we’re asking “What should this business process look like?”
Instead of worrying which checkbox to select, we’re deciding why that checkbox should exist in the first place.
That’s a much harder problem.
A Procurement Example
Take Dynamics 365 Finance & Supply Chain. Suppose a company wants to automate purchasing.
A few years ago, a consultant would spend hours clicking through forms: building workflows, defining approval hierarchies, configuring procurement policies, testing every scenario by hand. Today, AI can generate much of that scaffolding.
But someone still has to answer:
Should approvals run by department, cost center, project, or spending threshold?
Which purchases should bypass approval entirely?
How are emergency purchases handled?
What happens when an approver is out on vacation?
Which controls satisfy audit requirements without slowing the business down?
Those aren’t configuration questions. They’re business questions. And business questions have always been where experienced consultants create the most value.
The Pattern Is Everywhere
Developers spend less time writing boilerplate and more time describing the architecture they want. Data analysts spend less time writing SQL and more time deciding which questions are worth asking. Architects spend less time drawing every line and more time defining the building.
Doctors increasingly have AI helping interpret medical images, but the physician still decides which tests to order, how to read the results in context, and what treatment actually fits the patient.
The profession doesn’t disappear. The center of gravity moves.
Prompting Is Requirements Gathering, Rebranded
This is why prompt writing gets misunderstood. People treat it as clever wording. It isn’t.
Good prompts are evidence of good thinking. A well-written prompt reflects a clear grasp of the business objective, the constraints, the desired outcome, and the tradeoffs involved. The better you understand the problem, the better your prompt becomes.
In many ways, prompting is just the modern version of requirements gathering. The consultant who asks twenty thoughtful questions before asking AI a single one will consistently outperform the consultant who jumps straight to generating configurations.
Where This Leaves the Next ERP Expert
The future ERP expert will spend less time configuring systems and more time shaping solutions. That means curiosity beats memorization. Business knowledge beats navigation skills. Judgment beats mechanics.
AI is making execution cheaper. It’s making thinking more valuable.
The companies that win won’t just have access to better AI. They’ll have people who know what to ask, why they’re asking it, how to challenge the results, and when to change direction.
The next generation of ERP consultants won’t be measured by how fast they can configure a system. They’ll be measured by how well they can define the problem AI is being asked to solve.
Because in the age of AI, the competitive advantage isn’t having all the answers. It’s asking the questions that lead to the right ones.
In 1899, the Norwegian mathematician Niels Henrik Abel complained about Carl Friedrich Gauss’s papers. Gauss’s proofs were airtight but gave no hint of how he’d gotten there. Abel said Gauss was “like the fox, who effaces his tracks in the sand with his tail.” Gauss’s reply has outlived the complaint: “No self-respecting architect leaves the scaffolding in place after completing the building.”
He wasn’t being cagey. Gauss ran through dozens of false starts for every theorem he published, and he thought showing that mess would do the reader a disservice. A finished proof is not a transcript of how the proof was found. It’s a clean path from A to B, built after the fact, once you already know where B is.
This is exactly what happens in a good product demo, and it’s why demos so often feel like a kind of dishonesty even when every word in them is true.
The gap between finding and showing
When you’re building something hard, most of the time is spent wrong. You try an approach, it breaks in a way you didn’t expect, you try another. Six weeks in, you’ve got a whiteboard full of dead ends and one narrow path that actually works. Then you build the demo, and the demo only shows the narrow path. Someone watches it and sees three clicks. They have no way of seeing the six weeks.
That’s not a flaw in the demo. A demo that included the six weeks would be unwatchable, and it would also be the wrong artifact. Nobody wants the scaffolding. They want the building.
But it does create a predictable failure mode: the audience underestimates what it took, and then either assumes it must have been easy (so why did it take so long) or assumes it must be fragile (since nothing that clean survives contact with reality). Both reactions come from the same place: they’re reacting to the absence of visible effort, not to the actual state of the work.
Related shapes of the same idea
This tension shows up everywhere people do hard work and then have to present it simply:
Einstein’s Zurich Notebook, from 1912–13, is page after page of failed derivations. He got within a hair of general relativity, talked himself out of it for the wrong reasons, and lost three years before arriving at the fifteen or so symbols that appear in the final field equations. Nobody reads the field equations and sees the three lost years.
There’s an old story, probably apocryphal, about the engineer Charles Steinmetz, called in to fix a broken generator no one else could diagnose. He listened to it, made one chalk mark on the housing, and told them to replace that part. His bill was ten thousand dollars, itemized: “making the mark, one dollar; knowing where to put it, nine thousand nine hundred ninety-nine dollars.” The mark is the demo. The knowing is the scaffolding.
And there’s the duck on the pond: gliding, apparently motionless, paddling hard just under the surface where no one’s looking. It’s a cliché precisely because it describes something true about most visible competence.
What to do with this, if you’re the one giving the demo
You’re not obligated to show your work, and you shouldn’t try to cram it in. But it’s worth occasionally naming that it exists, even in one sentence: “this took longer than it looks like it should have” or “we tried three other approaches before this one.” Not as a boast, and not as an apology. Just as a way of telling the audience that the gap they’re sensing is real, so they don’t have to fill it in themselves with a worse story, like it must have been trivial, or it must be held together with tape.
Gauss removed his scaffolding because he trusted the building to stand on its own. That’s usually the right call. The failure isn’t leaving the scaffolding down. It’s letting people assume there was never any scaffolding at all.
I recently heard a story that captures one of the biggest misunderstandings about AI today.
A colleague was speaking with a mentor about artificial intelligence. The mentor said something like:
“You’re not really an AI maker. You’re just a user, because you build agents instead of training foundation models.”
That statement misses what has always driven innovation.
It’s a bit like saying Picasso wasn’t a painter because he didn’t manufacture his own paint. No one would seriously make that argument.
Painters don’t mine minerals, mix pigments, stretch their own canvas, or build their own brushes. They use the best tools available to create something new. We judge the artist by what they create, not by whether they manufactured every tool in the process.
The same is true for architects.
No one looks at a skyscraper and says, “The architect didn’t really build this. They didn’t smelt the steel, fire the bricks, manufacture the glass, or pour the concrete.”
Of course they didn’t.
An architect’s value isn’t in creating raw materials. It’s in understanding the client’s needs, balancing thousands of tradeoffs, coordinating experts, and bringing together countless components into something that has never existed before.
Without the architect, the steel is just steel. The concrete is just concrete. The glass is just glass.
The design is what turns materials into a building.
AI works the same way
Foundation model companies are creating incredible materials. They are building the engines that power modern AI, and that work deserves enormous respect.
But an engine isn’t a business solution.
Someone still has to understand the problem, design the process, connect enterprise systems, define the rules, manage security, handle exceptions, and create an experience that people can actually use.
That’s where AI builders come in.
Creating AI agents isn’t simply writing prompts. It’s designing systems.
An effective AI solution may include multiple agents with different responsibilities, access to business applications, memory, planning, approval workflows, governance, monitoring, and human oversight. Each piece must work together toward a common goal.
That is architecture.
Software has always worked this way
Developers don’t build their own processors. They don’t write operating systems from scratch. They don’t create every programming language or every library they use.
They assemble proven components into solutions that create value.
No one calls them “just users.”
Why should AI be any different?
In fact, many AI builders face a challenge similar to architects. The technology is often the easy part. The hard part is understanding people, business processes, regulations, risk, and change management. Success depends on making hundreds of good design decisions that never appear in a benchmark.
Training a better model is an incredible achievement.
Building an AI system that changes how a hospital treats patients, how a manufacturer runs its supply chain, or how a business serves its customers is also an incredible achievement.
These aren’t competing roles. They are different layers of the same profession.
Foundation model researchers create the materials. Infrastructure companies build the tools. AI architects design the systems. AI engineers assemble the solution. Organizations create value from the finished product.
Every layer matters.
History has shown this over and over
The printing press didn’t diminish authors. Cameras didn’t eliminate photographers. CAD software didn’t make engineers less legitimate. Excel didn’t make accountants “spreadsheet users.”
Technology changes the tools. It doesn’t change what it means to create.
The AI builders who will shape the next decade may never train a trillion-parameter model. Instead, they will design intelligent systems that help businesses make better decisions, automate work, improve healthcare, transform education, and solve problems that once seemed impossible.
The foundation model is the raw material. The agent is the structure. The finished business solution is the building.
And just like no one questions whether an architect created a skyscraper because they didn’t manufacture the steel, we shouldn’t question whether someone is an AI maker simply because they didn’t train the model.
The measure of a maker has never been whether they created every component. It’s whether they created something that mattered.
In Waterdeep, a good scoop can sell as quickly as a healing draught before a dungeon run. The Waterdeep Trading Company already has the store traffic, warehouse discipline, and trade network to support a new frozen goods venture. The next step is to treat ice cream not as a novelty, but as a managed product line with ingredients, batch control, storage rules, shop service, and delivery routes.
Frostmantle Creamery will operate as a shop within the Waterdeep Trading Company, using the Waterdeep site and warehouse structure already defined for inventory operations. The existing supply chain guide establishes product setup, units of measure, storage dimensions, tracking dimensions, warehouses, purchasing, sales orders, sales pricing, sales charges, and returns as core operating areas for the company. The Waterdeep site and store warehouse pattern also provides the foundation for assigning stock to a physical location.
The business goal is simple. Produce high quality ice cream in controlled batches, store it safely, sell it by scoop and tub, and deliver sealed product to taverns, inns, guild halls, and festival stands without losing quality.
This expanded edition carries the original operating model further. It adds flavor portfolio governance, staffing structure, equipment upkeep, yield variance analysis, a shop level profit and loss statement, multi site expansion planning, festival marketing, and risk management. Together these sections turn Frostmantle Creamery from a single shop concept into a repeatable business unit that the Waterdeep Trading Company can carry into other cities.
What It Is
Frostmantle Creamery is a cold goods operation that produces small batch ice cream using dairy, fruit, sugar, flavorings, and stabilizing frost runes. The shop sells finished product in three main forms.
Scoops served at the counter.
Pints sold for take away.
Three gallon tubs sold to taverns, inns, guild halls, and event sellers.
From an AD&D365 point of view, this is a mixed production and retail model. The finished ice cream is manufactured using a BOM and route. The tubs and pints are stocked in inventory. Scoops are sold as a retail service item that consumes inventory from an open tub.
Why It Matters
Ice cream has very different controls than cloaks, boots, rope, or scroll cases. It melts, expires, absorbs odors, and depends on batch quality. That means the Waterdeep Trading Company must manage more than price and quantity. It must manage freshness, storage condition, batch trace, serving yield, and delivery timing.
If the company does this well, Frostmantle Creamery becomes more than a sweet shop. It becomes a repeatable business model for frozen goods across Waterdeep, Baldur’s Gate, Neverwinter, and Silverymoon.
Product Setup
The product setup defines what the company buys, makes, stores, and sells. This table shows the core items needed before the shop opens.
Bill Of Materials
The BOM defines the ingredients and packaging needed to make one standard three gallon tub of Frostberry Ice Cream. This batch size supports both wholesale tubs and counter service. A three gallon tub, 384 ounces, yields 48 scoops at 8 ounces each, or 64 scoops at 6 ounces each, or 24 sixteen ounce take away pints.
Production Route
The route defines the work steps required to produce the ice cream. For Frostmantle Creamery, the route is built around controlled receiving, dairy preparation, churn time, hardening, and final quality review.
Cost Rollup
The cost rollup combines material, labor, and overhead into the final standard cost. The supply chain setup guide includes costing versions and item cost calculation as part of inventory setup, which supports this type of finished goods costing.
Suggested Sales Model
The sales model should separate retail counter sales from wholesale tub sales. Counter sales carry higher margin because the shop adds service, location value, and immediate consumption. Wholesale tubs carry lower margin but support tavern and inn volume.
Storage Plan
The storage plan protects product quality and supports batch trace. The supply chain guide uses storage dimension groups to define how products are tracked by site, warehouse, and location. It also defines tracking dimensions for batch and serial control. For ice cream, batch control is required for dairy, fruit puree, finished tubs, and finished pints.
Batch And Quality Rules
Ice cream needs tighter trace than most shelf stable goods. Batch numbers should connect the finished tub to cream, milk, egg base, fruit puree, production date, work center, and quality result.
Flavor Portfolio Management
A single flavor is a good way to open the shop, but Frostmantle Creamery cannot stay competitive on Frostberry alone. Once the base process is stable, the company should manage flavors as a formal portfolio, with each flavor treated as its own item under the same production model. This keeps costing accurate and prevents recipe drift at the churn.
Every new flavor should pass through three gates before it reaches the counter. First, a small batch trial in the Mixing Table to confirm taste and texture. Second, a costing review to confirm the new BOM does not quietly erode margin. Third, a shelf trial to confirm the flavor holds its quality through the full 30 day best by window.
Seasonal flavors should be planned at least one production cycle ahead so that fruit, spice, and packaging can be procured on schedule. Limited release flavors like Shadowberry Midnight should be capped by production order so the shop does not overcommit rare fruit stock to counter sales at the expense of festival contracts.
Staffing And Roles
Frostmantle Creamery cannot run on a single counter clerk. The shop needs distinct roles across production, service, and quality, each with clear responsibility so that batch discipline does not depend on any one person’s memory.
The Quality Warden should never be the same person who ran the churn on that batch. Separating production from final review keeps the quality hold honest and protects the shop from the temptation to wave through a marginal batch during a busy festival week.
Equipment And Arcane Upkeep
The Frost Churn and Hardening Cabinet are the two pieces of equipment most likely to cause a shutdown if neglected. Both combine mechanical parts with an arcane component, so maintenance covers both craft and enchantment.
A recharge of the Hardening Cabinet’s frost rune matrix is a planned overhead cost, not a surprise expense. It should be scheduled on the production calendar the same way a caravan books a departure date, so a batch is never left waiting on an uncharged cabinet.
Waste, Spoilage, And Yield Variance
Standard costing assumes a three gallon tub yields exactly 48 scoops at 8 ounces or 64 scoops at 6 ounces. In practice, actual yield will vary due to melt loss during scooping, over pour by new counter staff, or a batch that hardens slightly under or over target. Frostmantle Creamery should track this as a yield variance, the same discipline the company already applies to other production variance analysis.
A variance of four scoops on one tub may look small, but at scale across a full festival weekend it becomes a meaningful drain on margin. The Quality Warden should record actual yield on every tub closed at the counter, and any variance above five percent should trigger a review of scoop size, melt handling, or staff training rather than being written off as ordinary spillage.
Procurement Requirements
The shop cannot rely on chance market buying. Dairy, fruit, packaging, and frost runes must be sourced from approved vendors. The supply chain guide includes procurement categories, purchase orders, vendor pricing, and purchase order approval as core setup areas.
Distribution Requirements
Distribution must be split into local service, local delivery, and regional wholesale. Scoops are sold only at the counter. Pints can be sold at the counter or delivered locally. Tubs can be delivered to inns, taverns, guild halls, and festival stalls.
The transportation articles for Waterdeep Trading Company describe route guides, hub types, carrier services, transit distances, scheduled routes, and multi segment freight planning for moving goods across Faerûn. Those same controls apply here, but with stricter timing because frozen goods cannot sit on a warm cart while a driver stops for lunch and a bard show.
Local Delivery Operating Rules
Local deliveries should leave from the finished goods freezer only after the sales order is picked, checked, packed, and sealed. The sales order flow in the supply chain guide includes creating sales orders, confirming orders, picking and shipping, invoicing, and reviewing sales invoice vouchers.
Regional Distribution Rules
Regional shipments should be limited to sealed tubs until the company has tested longer routes for pints. Ice cream shipped beyond Waterdeep should move through scheduled freight lanes with known carriers.
Returns And Credit Rules
Frozen products are risky returns. The shop should not restock returned ice cream unless it never left company control and the cold seal remained intact.
Shop Level Profit And Loss
Once Frostmantle Creamery is producing multiple flavors and running both counter and wholesale channels, ownership will want a simple monthly profit and loss view rather than only a per tub cost rollup. This gives Greta Ironfist a single page to judge whether the shop is pulling its weight within the wider Waterdeep Trading Company.
Tracking yield variance loss and maintenance cost as their own lines, rather than folding them quietly into cost of goods sold, gives the Quality Warden and the Batch Alchemist a direct incentive to protect margin at the churn and the counter.
Marketing And Festival Circuit Model
Frostmantle Creamery benefits from Waterdeep’s calendar of festivals, fairs, and public gatherings. Rather than treating festival sales as a bonus, the shop should plan its production calendar around known festival dates, since these events can move a meaningful share of monthly tub volume in a single weekend.
Festival contracts should be confirmed and production booked before counter demand for the same period is estimated, since a festival stand cannot go back for more stock mid event the way a local tavern can place a same day order.
Multi Site Expansion Considerations
Once Frostmantle Creamery is stable in Waterdeep, the same model can be extended to Baldur’s Gate or Neverwinter as a second production site rather than only a wholesale destination. This avoids the 12 to 15 day freight lead time that currently limits regional tub sales and lets each site serve its own counter and local delivery customers directly.
Keeping the BOM and route identical across sites, and only adjusting the cost inputs for local pricing, preserves the ability to compare site performance directly rather than comparing two different recipes.
Risk And Insurance Considerations
The frost rune seal is the single point of failure most likely to threaten an entire batch or delivery run, since a weak seal can spoil product before anyone notices. The shop should treat this as a named risk with its own mitigation steps rather than an assumed background cost.
Faerûn Aware Considerations
The Waterdeep Trading Company should treat ice cream as both food and magic supported inventory. The dairy supply is mundane. The frost rune seal is magical. The route is production. The counter sale is retail. The delivery model is transport. The full process touches purchasing, inventory, production, sales, and quality.
A few operating points matter most.
Do not produce more than the freezer can hold.
Do not sell open tubs into wholesale orders.
Do not deliver without a frost stone or cold seal slip.
Do not accept returns into saleable stock.
Do not let flavor variety outrun batch control.
Do record scoop yield by tub, because waste and over serving can quietly eat the profit.
Do book festival production ahead of counter estimates, since a festival stand cannot restock mid event.
Worked Example
Greta Ironfist approves a production run of 10 tubs of Frostberry Ice Cream for a Midsummer market push.
The production team creates 10 production orders or one batch order for 10 tubs. The BOM consumes cream, milk, sugar, egg base, frostberry puree, stabilizer, frost rune seals, tubs, and labels. The route records labor and overhead from receiving through final quality review.
The 6 ounce scoop creates more serving opportunities and a stronger margin, while the 8 ounce scoop feels more generous and may be better for premium festival pricing. The company can use both, but the serving size should be locked by item, price, and counter policy.
Final Thoughts
Frostmantle Creamery is a strong fit for the Waterdeep Trading Company because it uses skills the company already has. It buys from guild suppliers, manages controlled inventory, tracks batches, serves retail customers, and ships to trade partners.
The difference is discipline. Ice cream punishes weak storage, loose batch control, and slow delivery. With a clear BOM, defined route, strict storage plan, well managed distribution rules, a governed flavor portfolio, honest yield tracking, and a shop level profit and loss view, the company can turn a simple frozen treat into a profitable, expandable Waterdeep product line.
For step by step configuration guides covering production orders, BOMs, routes, and inventory setup, see the Advanced Dungeons and Dynamics 365 Bare Bones Configuration Guides, a 7 book series available at https://www.amazon.com/dp/B0GYLPFKCF
CALL TO ACTION
Get your own AD&D365 Environment and guides at adnd365.com/start
A Tinkerers Notebook 