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
The four ways people manage household money aren’t just personal finance patterns. They’re organizational patterns. They show up at every scale: corner stores, venture-backed startups, mid-market manufacturers, Fortune 500 companies.
The stakes are just higher. And the failure modes are more public.
Here’s the same progression, mapped to real business behavior, and what each system actually produces in terms of profitability, resilience, and growth.
System One: The Checkbook Business
The question they ask:Is there money in the account right now?
Small businesses live here more often than most owners would admit. The restaurant owner who checks the register at the end of service. The contractor who pays suppliers when a client check clears. The freelancer who looks at the bank balance before agreeing to take on a new expense.
This isn’t incompetence. Early-stage businesses often have no choice: the margin for error is so thin that real-time cash position is genuinely the most important number. Survival runs on today’s balance.
The problem is what gets invisible.
A checkbook business knows whether it can pay this bill. It does not know whether it will be profitable this month. It does not know whether the good month it just had covered the overhead it carries, or whether it was just an unusually large receivable that finally cleared. It cannot distinguish between a solvent business having a cash-tight week and an insolvent business having a deceptively comfortable one.
The profitability trap: Many checkbook businesses are profitable on paper and bankrupt in practice. This is one of the most common ways small businesses die: not from lack of customers, not from lack of revenue, but from a sixty-day receivables gap that the owner couldn’t see coming because the system only showed today.
The technical term for this is cash flow insolvency: you have more assets than liabilities, which means you’re profitable, but you cannot pay your current obligations because the money is in the wrong place at the wrong time.
The balance looks fine until it doesn’t. And when it doesn’t, there’s no warning, because the system wasn’t designed to give one.
Real-world fingerprint: A profitable small business that always feels financially precarious. Owners who carry stress about money even in good months. Occasional crises (a big client pays late, a quarterly tax bill lands) that feel like catastrophes but are actually predictable, because they happen every year.
System Two: The Forecasting Business That Misses
The question they ask:What will revenue be this quarter?
This is where most growth-stage companies live, and where a remarkable number of them stay, stuck in a cycle of projections that don’t land.
The forecasting business has graduated from “what’s in the account” to “what are we expecting.” It runs pipeline reviews. It builds revenue projections. It presents a three-month outlook to leadership or investors. This is meaningful progress. Time is in the model now.
But the forecasts are almost always optimistic.
Sales teams project the pipeline as if every deal in the funnel will close, and close on schedule. Revenue gets projected; costs get underestimated. The plan says the new sales hire will be productive by month three; reality says month five. The contract that was “90% likely to close in Q2” pushed to Q3. The expense that was “one-time” recurs.
Month after month, the forecast is confident. Month after month, actuals come in below it.
The profitability trap: When forecasts are systematically optimistic, companies make commitments they shouldn’t. They hire ahead of revenue. They sign leases based on projected growth. They make promises to investors that require a growth rate the business can’t sustain. The result isn’t one bad quarter; it’s a structural gap between the business as it exists and the business as it was planned, and every decision made on the plan is now wrong.
The deeper problem is that optimistic forecasting hides whether the business model actually works. If you’re perpetually revising down, you can’t tell whether you’re a fundamentally profitable company having execution problems, or an unprofitable company whose numbers only look promising in the forecast.
Some of the most spectacular business failures in recent decades followed this pattern exactly. Companies with enormous revenue, strong unit economics in certain segments, and explosive growth, that were never actually profitable because the forecast kept promising that profitability was one more growth push away. The forecast became the operating reality, and the actual operating reality was never examined.
Real-world fingerprint: The company that’s always “on track for a great Q4.” Leadership that explains misses as timing issues, not model issues. Investors who hear “we’re accelerating into profitability” for six consecutive quarters. Employees who can’t quite tell whether the business is doing well or not, because the answer seems to depend on which version of the plan you’re comparing against.
System Three: The Budgeting Business
The question they ask:How did we do against the plan?
This is where professional management begins to look like professional management.
The budgeting business sets an operating plan at the start of the year: revenue targets broken down by product line, cost of goods, gross margin, departmental operating expenses, EBITDA target. Every month, actual results are compared to the plan. Variances are explained. Significant deviations trigger action.
This changes everything.
When you track budget versus actual with discipline, a few things happen that don’t happen in lower-order systems. First, you know quickly when something is wrong: not when the bank account empties, but when the variance shows up in the data. Second, the business develops institutional knowledge about how it actually operates versus how it thought it operated. Third, accountability becomes real: the sales leader can’t wave at the pipeline anymore, because the numbers are compared to a commitment.
Most importantly: a business running a real budget almost always generates more consistent, predictable profit than an equivalent business that doesn’t, because the act of planning and measuring drives better decisions.
The profitability mechanism: Budget discipline reduces the two most common causes of unexpected losses: untracked cost creep and unchecked optimism on revenue. When every department knows what it’s allocated and every shortfall gets explained, the business develops cost awareness that’s nearly impossible to maintain without the structure. Gross margins stabilize. Operating leverage improves. The business starts to compound.
This is why investors, acquirers, and lenders ask for budget-versus-actual comparisons. Not because they’re curious about the plan, but because the discipline of building and tracking a plan is itself predictive of management quality. A company that can build a realistic plan and execute close to it is a fundamentally different risk profile than one that can’t.
Real-world fingerprint: Quarterly business reviews with actual variance analysis. A CFO who knows, from memory, the gross margin by product line. A sales team that has monthly targets, not just an annual number. Financial reporting that comes out within a week of month-end, because the systems are set up to produce it. Debt covenants that get met because the business knew three months out whether it was on track.
System Four: The Capital-Planning Business
The question they ask:Where does this dollar earn the best return over time?
This is where great businesses separate from good ones.
The capital-planning business does everything the budgeting business does, and adds a layer of long-term, deliberate resource allocation. It doesn’t just ask whether this quarter’s expenses are on plan. It asks: what should this company invest in over the next three to five years to build durable profitability? Where should retained earnings go? Which capital expenditures earn above the cost of capital? Where are we building a competitive advantage, and where are we just spending?
This is the language of capital allocation, arguably the most important skill in running a business, and the one most frequently treated as secondary to sales, product, or operations.
The mechanism is thinking in returns, not just costs. A budget asks: are we spending what we planned? Capital planning asks: is the spending generating the return we need? The first question is about control. The second is about strategy.
The profitability mechanism: Businesses that allocate capital well build compounding advantages. The investment in equipment that reduces unit cost. The product development spend that expands addressable market. The customer acquisition that generates ten-year lifetime value. The acquisition that adds capability the business couldn’t build faster internally.
Done well, capital planning means that profitability doesn’t just persist; it grows. The business today is structurally more profitable than the business three years ago, because the intervening years of deliberate investment built something that competitors can’t easily replicate.
Berkshire Hathaway is the canonical example of this system at scale. Buffett has described his job, fundamentally, as capital allocation: deciding where each dollar of retained earnings earns the best long-term return. The operating businesses run their budgets. His job is to decide where the cumulative profitability of those businesses gets reinvested.
Most businesses never get here because they’re still solving earlier problems. But the ones that do, the ones that develop a real framework for evaluating long-term capital deployment against expected return, tend to generate profitability that compounds rather than flatlines.
Real-world fingerprint: A CFO who can articulate the company’s return on invested capital (ROIC) and compare it to the weighted average cost of capital (WACC). Capital expenditure proposals that include payback period analysis. A board conversation about portfolio allocation: which business lines to invest in, which to harvest, which to exit. Retained earnings that are deployed deliberately, not just accumulated. A five-year financial model that gets updated quarterly and actually informs decisions.
The Profitability Table
System
Business Type
Profit Pattern
Most Common Failure
Checkbook
Early-stage, survival-mode
Unpredictable; solvent on paper, crisis-prone in practice
Cash flow insolvency; profitable businesses going under
Never actually achieving the “next quarter” profitability
Budgeting
Mature operating business
Consistent, predictable, improvable
Profitable but not compounding; running in place
Capital Planning
High-performance, long-horizon
Compounding; structural improvement over time
None. This is the goal.
Why Businesses Get Stuck
The natural question is: why doesn’t every business just run capital planning? If it’s the best system, why doesn’t everyone use it?
The same reason people don’t run household budgets.
Budgeting requires discipline in the present to prevent pain in the future. Capital planning requires thinking clearly about the future while managing the present. Both require honest accounting, which means accepting bad news as data rather than explaining it away. All of this is harder than it sounds when you’re dealing with payroll, customers, competition, and a thousand daily decisions that feel more urgent than next year’s plan.
The businesses that move up the ladder are the ones where someone (usually a founder who lived through a cash flow crisis, or a CFO who’s seen what variance blindness costs) made the deliberate decision that the current system wasn’t good enough. That better information was worth the work required to have it.
The irony is that the work gets easier as the system improves. A business with a real budget closes its books faster, makes decisions more confidently, and recovers from setbacks more cleanly than one running on balance checks and optimistic forecasts. The discipline creates capacity, not just control.
The Household Connection
This is exactly why the household and the business are the same problem at different scales.
The person who checks their bank balance every Friday morning is running the same system as the small business owner who checks the register. The family that talks about “making it to the next paycheck” is experiencing the same structural problem as the startup that talks about “making it to the next funding round.”
The mental models transfer completely. The vocabulary is different. The amounts are different. The underlying structure (how money is tracked, what questions get asked, how far ahead the thinking extends) is identical.
Which means the upgrade path is also identical.
You don’t have to be a business to benefit from running like one. You don’t have to have investors or a board or a CFO to ask better questions about where your money goes and what return it’s generating.
The four systems aren’t corporate tools. They’re ways of thinking. The businesses that use the most sophisticated version aren’t more rigorous because they’re businesses; they’re more rigorous because they decided better information was worth the effort to have it.
That decision is available to anyone.
This post is part of the Home ERP series, exploring how enterprise resource planning concepts apply to the households we all already run.
Want to go deeper?Running a Home Like a Business walks through the complete system (budgets, cash flow, capital planning, and more) through the story of one family that runs their household with the discipline of a well-managed company.
The world of trade does not belong to Faerûn alone. Commerce has always found its way to the edges of known charts, into harbors where no guild charter holds authority and no lord’s tax collector dares to venture. It is in those contested waters that the Black Tide Trading Company has made its name, and it is through that company’s operations that a new chapter in the Advanced Dungeons and Dynamics 365 series now opens.
This article introduces the Black Tide Trading Company, the pirate-genre companion to the Waterdeep Trading Company. It is a different world, a different currency, and a different set of trade pressures, but the underlying disciplines of accounts receivable, inventory management, procurement, and payroll apply just as surely on the deck of a Caribbean trader as they do in the vaults of Waterdeep’s merchant lords.
A Different Stage, The Same Discipline
The base Advanced Dungeons and Dynamics 365 guides use the Waterdeep Trading Company as the example organization. Every legal entity, every customer account, every vendor relationship, and every fiscal period is configured around that company and its operations across Faerûn.
The Black Tide Trading Company supplement works differently. It is a genre overlay, a companion document that sits alongside each base guide and provides alternative configuration values for readers who want to work through the same ERP concepts in a maritime trading environment. Where the base guide says Waterdeep, the supplement says Tortuga. Where the base guide specifies Waterdeep Gold, the supplement specifies the Piece of Eight.
The concepts taught are identical. The setting is entirely its own.
The Setting: The Caribbean, 1718
The year is 1718. The Caribbean is divided among the competing ambitions of four colonial powers. Spain controls Havana and the silver trade routes running north and east. Britain holds Port Royal and commands the Atlantic passage. The Dutch East India Company operates out of Batavia with a near-total monopoly on Asian spices. The French maintain interests in the Windward Islands, with sugar and colonial supply contracts moving through their own networks.
Into this contested maritime world sails the Black Tide Trading Company. It is not a pirate outfit in the theatrical sense. It flies no Jolly Roger and raids no merchant vessels. Instead, it occupies the profitable grey zone between licensed privateer and licensed trading house, moving cargo across jurisdictional lines that more cautious merchants refuse to cross. Its competitors are not other pirates. They are over-regulated colonial trading houses that cannot react quickly when a pepper crop fails or a Dutch spice convoy arrives six weeks ahead of schedule.
The company operates out of Tortuga, headquartered at the Black Tide Counting House on Saint-Nicolas Bay, and maintains agents and accounts across six ports.
The Fleet: Three Ships, Six Ports
Every voyage the BTTC undertakes is a logistics puzzle. Cargo must be procured months in advance in Batavia, transported across two oceans, and sold into Caribbean markets where prices shift with colonial politics, weather, and supply disruptions. The company’s three ships are its primary inventory-holding units, functioning in the ERP configuration as mobile warehouses.
The following table describes the three vessels that form the backbone of BTTC operations.
Cargo is loaded at one port and unloaded at another, with each port configured as a separate site in the ERP structure. The six operating ports below represent the geographic scope of BTTC trade.
The People: Who Runs the Black Tide
Five individuals make most of the financial decisions that the BTTC configuration guides ask learners to work through. Understanding who they are and what they are responsible for helps place the configuration tasks in their proper operational context.
The following table summarizes the key personnel and their roles within the company.
The company employs sixty workers in total, organized across three ship crews, a Tortuga shore team, and a network of five port agents stationed at each operating location.
The Currency: Trading Across Jurisdictions
One of the most distinctive aspects of BTTC operations is the multi-currency environment. Where the Waterdeep Trading Company operates primarily in Waterdeep Gold, the BTTC moves goods across four colonial currency zones and maintains six additional internal and specialty currencies for crew wages, prize cargo, and luxury trade.
The Piece of Eight is the company’s base currency and serves as the interoperability unit across all accounts. Exchange rates are expressed as POE cross-rates.
The following table shows the core and colonial currencies configured for BTTC operations.
The Products: What the BTTC Trades
The company carries twenty commodity products spanning Asian spices sourced in Batavia, Caribbean spirits and agricultural goods from Port Royal, Bridgetown, and Havana, and operational supplies that keep the fleet moving. Products are grouped by trade route logic rather than product type, with spices, spirits, dry goods, raw materials, and operational supplies each managed as distinct item groups.
Black pepper is the company’s highest-volume product and the commodity at the center of the primary adventure scenario. It drives the best margins when markets are stable, and it represents the company’s most significant financial exposure when supply and demand fall out of alignment.
The following table shows a selection of key products and their base pricing.
The Adventure: A Planning Failure at Sea
The primary adventure scenario built around the BTTC configuration data is the Spice Route Commodity Run of 1718. The Black Horizon departs Tortuga in March, sails to Batavia, loads a full hold of black pepper and mixed spices, and returns to the Caribbean by September.
The scenario is designed around a demand planning failure. The BTTC loaded more pepper than the market could absorb at the expected sale price. A Dutch spice convoy arrived ahead of schedule, flooding Port Royal and Bridgetown with cheaper pepper, and the company’s revenue projections collapsed below the approved voyage budget.
The sample voyage budget below shows what Lord Cromwell approved before departure, and what Clerk Marsh was left to reconcile upon return.
This is the configuration that learners analyze when they complete the adventure. The variance between planned and actual, and the systems that should have flagged the risk earlier, are the practical lessons that the BTTC scenario is built to teach.
How to Use the Supplement
The Black Tide Trading Company supplement is structured to work alongside the base AD&D365 configuration guides, not to replace them. Each guide in the supplement mirrors its corresponding base guide and provides BTTC-specific values for every field that learners are asked to configure.
The approach is straightforward. Open the base guide in one window and the supplement in another. When the base guide asks for a company name, currency code, fiscal calendar, or customer record, find the matching BTTC value in the supplement and enter that instead. The same configuration steps apply. Only the data changes.
This design means that readers who work through the base guides using the Waterdeep Trading Company can return to the same guides and complete a second pass with the BTTC, reinforcing every concept in a different operational context.
Final Thoughts
The Black Tide Trading Company is a different kind of organization from the Waterdeep Trading Company. It operates in a harder world with fewer protections, more currency exposure, a crew that expects a share of every profit, and a voyage budget that can unravel when the Dutch arrive early. But the disciplines it relies on, well-configured accounts, accurate inventory tracking, defensible procurement records, and a payroll system that can calculate voyage shares to the last Piece of Eight, are the same disciplines that any well-run trading operation depends on.
Whether the ledger is kept in Waterdeep Gold or Pieces of Eight, good accounting keeps the ship afloat.
Support the AD&D365 Project on Patreon. To grow this world, we’ve launched an official Patreon page where supporters can access exclusive content, tools, and training labs, and even influence the project’s future. Your support fuels more than just development; it expands the guildhall, forges new scrolls, and empowers the next generation of configuration wizards. Begin your journey: https://www.patreon.com/adnd365/
A Grateful Salute to Our Patrons. To all those who stand behind the vision, thank you for helping bring this world to life. Our Benefactors, Andre Breillatt and Eryndor Fiscairn‡, your boundless generosity fuels the arcane core of this project. Without your magic, the weave would falter. Our Apprentices, the spell engines turn, and the training labs thrive thanks to our current Apprentices: Michael Ramirez and Andreth Bael’Rathyn‡. Special thanks to our past Apprentices, whose contributions helped us get here: Ralf Weber, Wendy Rijners, Shashi Mahesh, Julia Tejera, Ben Ekokobe, Tiago Xavier, Naveen Boyinapelli, Marcos Tadeu Wolf, Kathryn Greene, Jason Brown, Mark Christy, and Ashish Singh.Our Initiates, Jesper Livbjerg, Peter Lorre, Gregory Brigden, and Martin Grahm, your commitment marks the start of the deeper path, stepping beyond mere observation into the active shaping of this realm. Our Followers, your steady presence along the journey is a beacon of encouragement: Rusty Cavalier,Eric Shuss, Sunil Panchal, Sarah D. Morgan, Nick Ramchandani, Daniel Kjærsgaard, and Tomasz Pałys. And our Voyeurs, Harry Burgh, Abdelrahman Nabil, and Basil Quarrell, ever watching from the shadows, clearly intrigued… but not enough to part with a single gold piece. Your silent curiosity is noted and mildly judged.
Want to design your own economic models in Faerûn? Get your own AD&D365 Environment and guides at adnd365.com/start, and request access to the public view of the current database at https://public.adnd365.com – Login npc@adnd365.com, Password N0nPl@yC#822!
