The Specialist Knows Its Job. The Generalist Knows Your System.

By
September 4, 2026
Uncategorized
Leave a comment

Enterprise software has spent forty years arguing about the same question in different clothes. Should a function do one thing correctly, or should a tool be given enough authority to figure things out on its own. Agentic AI has not settled that argument. It has just given it a new vocabulary.

Look at the two ends of what is shipping right now. SAP’s Joule agents, and most of the enterprise agent catalog around them, are built narrow. Each one has a defined job, a defined sequence, and a defined set of systems it is allowed to touch. An invoice reconciliation agent reconciles invoices. It does not decide to also check vendor master data for anomalies unless that step was explicitly wired into its process. Microsoft’s Cowork points at the opposite pole. It is handed a single broad tool, effectively full reach into a Dynamics 365 Finance and Operations environment, and told to figure out how to get a stated outcome done. Nobody hand built a sequence for it. It builds its own.

Both are called agents. They are not the same kind of thing, and the difference matters more than the marketing suggests.

What a specialized agent actually is

A specialized agent is closer to a very well automated macro than it is to a colleague. It has a fixed task, a fixed order of operations, and a boundary around what data and systems it can reach. This is not a limitation bolted on as an afterthought. It is the entire design philosophy. You get predictability in exchange for narrowness. When the invoice reconciliation agent runs, you know what steps it took, in what order, against what data, because those steps were specified in advance. If it fails, it fails in a way you can trace to a specific step that did not resolve.

That traceability is not incidental in a finance system. It is the whole point. An auditor does not want to hear that an agent figured out how to close the period. They want a sequence of steps that can be replayed, checked, and defended.

What a generalized agent actually is

A generalized agent like Cowork inverts that trade. Instead of many narrow tools each doing one job, it gets one wide tool and the discretion to decide, at run time, what sequence of actions gets it from the stated goal to a finished result. Ask it to reconcile a vendor’s account for the quarter and it will decide for itself which records to pull, which discrepancies are worth flagging, and in what order to check them. Two runs against the same request, on the same data, are not guaranteed to take the same path to get there.

That is not a bug in the current generation of these tools. It is the feature being sold. A generalized agent does not need someone to have anticipated every scenario in advance and built a process for it. It reasons its way through situations nobody wrote a workflow for. The cost of that flexibility is that the path it takes on any given run is not fully knowable ahead of time, and reproducing it exactly on demand is harder than reproducing a fixed sequence.

The real axis underneath the label

Specialized versus generalized describes the shape of the agent. It does not describe the thing that actually matters to a finance or operations leader deciding whether to trust one of these near a ledger. That deeper axis is deterministic versus probabilistic.

A deterministic process, whether run by a person, a script, or a narrow agent, produces the same output from the same input every time. A three way match either passes or it does not, based on rules that do not change between Tuesday and Thursday. A probabilistic process, which is what a large language model doing open ended reasoning actually is underneath the interface, produces an output that is likely to be correct given the input, not guaranteed to be correct. Run it twice and you may get two answers that are both individually defensible and are not identical.

Specialized agents tend to sit closer to the deterministic end, because their designers constrained the decision space in advance and left little room for the model to improvise. Generalized agents tend to sit closer to the probabilistic end, because improvisation across an open ended tool is the entire value proposition. But the two axes are not the same axis wearing different names, and conflating them is where a lot of the current enterprise anxiety about agents actually comes from. A specialized agent can still make a probabilistic judgment call inside one of its fixed steps, such as classifying a transaction description as likely fraudulent. A generalized agent can still land on a fully deterministic sub task, such as pulling a specific ledger balance, where there is only one correct answer and no room to improvise.

Why D365 F&O is the place this gets tested for real

Dynamics 365 Finance and Operations is a useful proving ground precisely because it already lives with both philosophies side by side. Its native controls, workflow approvals, posting rules, three way match, are deterministic by construction. They were built that way before anyone was talking about agents, because a ledger that produces a different answer on a re-run is not a ledger anyone can close a period against.

Layer Copilot style features and Cowork on top of that and you get a system where the system of record stays deterministic while the layer working on top of it is free to reason probabilistically about what needs attention. That is not a contradiction. It is the correct division of labor. The ledger should never guess. The agent looking for the discrepancy that the ledger’s own rules were not written to catch is allowed to guess, because guessing well is precisely what it is there to do.

The mistake worth watching for is treating a generalized, probabilistic agent as if it were a specialized, deterministic one because it happens to be plugged into the same system. Giving Cowork the same blind trust you would give a fixed three way match rule is a category error. One was built to never deviate. The other was built to deviate on purpose, whenever deviating produces a better answer.

Where this actually lands

Neither shape is the correct answer in general. A specialized agent is the right tool when the process is well understood, the stakes of an unreviewed error are high, and an auditor will eventually ask for the sequence of steps. A generalized agent is the right tool when the problem is not well understood in advance, when the value comes from adapting to a situation nobody scripted for, and when a human is still positioned to review the output before it becomes a transaction that cannot be undone.

The organizations getting this right are not the ones picking a side. They are the ones that have stopped asking whether an agent is good, and started asking where on both axes, specialized to generalized and deterministic to probabilistic, a given task actually belongs. Get that placement wrong in either direction and you either waste a general reasoning tool on a task a five line business rule already solved, or you hand a fixed script a problem it was never built to handle and call the resulting failure a bug instead of what it actually is, a design mismatch.

The Contoso Convergence, Episode 14: Go Live Weekend

By
September 4, 2026
Uncategorized
Leave a comment

An Advanced Dungeons & Dynamics 365 session. Episode 14 of 14. Season finale.

Previously on: Episode 13, The Audit Trail, the party disclosed the tax overcorrection to Feld immediately rather than waiting, and Feld pulled in audit and legal, then asked the party what go live actually needed from him personally.

Fourteen episodes. A shadow ledger, a silent integration, a rebate accrual eighteen months out of date, a chart of accounts stitched together by three different consultants, a demo that was finally allowed to break, and a tax override that outlived the bug it was built to fix. Every one of those problems is either resolved or being actively managed in the open. This is the weekend all of it gets tested at once.

The Session

GM: Cutover weekend. Every system down, every fix live, every character sheet about to be tested for real.

Marge: Status check. Thorne?

Thorne: Ledger’s clean. Rebate automation posted its first real accrual an hour ago. Correct, to the cent.

Sable: Chart of accounts holds. TEMP_DO_NOT_USE is finally retired, we mapped every report around it first.

Vex: Tax override removed. Legal signed off on the disclosure. Integration retry logic held through a full order cycle.

Ai. Cassiopeia: Power user proficiency scores, current state: seven of eight above target. Denise is mentoring the eighth.

Marge: Feld?

Feld: Board’s aware. Audit’s engaged. For the first time in this whole project, there’s nothing left that we’re hiding from ourselves.

GM: Monday morning. The first live order comes through. Every person who ever touched this engagement is watching the same screen.

Thorne: It’s processing.

Sable: It’s processing clean.

Marge: Third time’s the go live.

The order posts. No exceptions. No shadow ledger. No suspense account. Somewhere, Priya, back from a very long vacation, gets a message with just one word in it: “Live.”

Vex: (watching the screen) Fourteen episodes for one clean transaction.

Sable: It’s never really been about the one transaction.

Ai. Cassiopeia: Correct. It is about the fact that the next one, and the one after that, will hold the same way, for reasons everyone in this room can now actually explain.

Thorne: (quietly) That’s the part I’ll remember. Not that it worked. That we know why it worked.

Marge: (to the room) Good work, everyone. Truly.

Feld: (standing at the back of the room, having watched the whole thing) I’ve sat through two go lives that felt like holding your breath and hoping. This one felt like watching something that was actually built to hold.

Oskar: (from near the door, smiling for the first time in fourteen episodes) It’s a good feeling.

What actually changed between attempt three and the first two

Nothing about Contoso’s underlying complexity got simpler over the course of this campaign. The chart of accounts is still layered with history. The rebate program is still complicated. International tax rules are still international tax rules. What changed wasn’t the difficulty of the problem. What changed was whether the people closest to each problem felt safe enough, and equipped enough, to name it clearly the moment they found it.

Every failure in this campaign, the shadow ledger, the silent integration, the eighteen month manual accrual, the two year old tax override, the training program measuring attendance instead of competence, shares the same shape underneath the technical details. Something wasn’t working, someone noticed, and the information didn’t travel to whoever needed it, either because there was no channel for it, or because the channel that existed had already taught people that raising it wasn’t worth the trouble. Priya’s spreadsheet, Oskar’s silence, Denise’s unheard flag in month two, Feld’s own two years of unspoken knowledge, all of it is the same failure wearing different clothes.

What actually got fixed on this go live wasn’t the ledger. It was that. A demo that was allowed to break. A sponsor who learned that honesty wouldn’t blow up the room. A frontline analyst who finally got asked a follow up question instead of being scored and moved past. None of that shows up on a go live checklist, and all of it is the actual reason the third attempt held when the first two didn’t.

The pattern isn’t over

Every dungeon in this campaign, the shadow ledger, the forgetting curve, the golden path demo, the burden rate blind spot, is a real failure mode from real ERP engagements, just given a party and some dice. If any of these fourteen episodes made you wince in recognition, that was always the point.

  • Read the framework this whole campaign is built on: Gamifying the Enterprise: Game Mechanics for Continuous Proficiency, available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX
  • Get the full AD&D365 configuration guides, the Bare Bones Configuration Guides, Fifth Edition, all seven volumes, and start turning your own team’s onboarding into something closer to episode eleven than episode one: adnd365.com/start

Thanks for following the Contoso Convergence from the docks of Waterdeep all the way to a clean Monday morning transaction. If there’s an appetite for it, there’s more than one way this world could keep going.

The Contoso Convergence, Episode 13: The Audit Trail

By
September 3, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 13 of 14.

Previously on: Episode 12, The Customization Nobody Remembers, Vex found a two year old tax override still running on top of a platform fix that made it unnecessary eighteen months ago, which meant international tax had likely been calculated twice for a very long time.

Two weeks to go live, and the party finally has to decide what to do with a discovery that’s bigger than a bug fix. This episode is about the moment a technical finding becomes an ethical one.

The Session

Vex: The override was patching a tax bug. The bug was fixed in a platform update eighteen months ago. Nobody removed the patch.

Sable: So for eighteen months, international tax has been calculated twice. Once correctly by the platform, once again by the leftover override.

Thorne: Every international order in that window needs review.

Ai. Cassiopeia: I can generate the affected transaction list. It is not small.

Marge: Feld needs to know today. Not after go live.

The party requests an unscheduled meeting. Feld reads the summary standing up, without sitting down first, which everyone in the room understands as a bad sign before he says a word.

Feld: (reading the list) This goes to audit and legal before it goes anywhere else.

Thorne: That’s the right call. It’s not a great one. But it’s the right one.

Feld: (setting the list down carefully) Two go live attempts failed because people were afraid to bring me news like this. You just did it anyway.

Marge: That’s the job.

Feld: I know it is. I’m still noticing that it happened.

Vex: There’s a smaller silver lining, if it helps. The overcorrection was consistent and directional. It should make the reconciliation methodical rather than exploratory. We know exactly what we’re looking for.

Ai. Cassiopeia: I concur. This is not a needle in a haystack. It is a known pattern applied against a known window.

Feld: (a short, tired exhale that’s almost a laugh) After everything else this project has thrown at me, “at least it’s a known pattern” is genuinely reassuring. That says something about the last four months.

Sable: It says the bar moved. Not that this is small.

Feld: Understood. Bring in whoever you need. What does the timeline look like with audit and legal both in the loop?

Feld authorizes disclosure, pulls in audit, and, for the first time in the engagement, asks the party what go live actually needs from him personally.

The moment disclosure stops being optional

Every episode up to this one has been about finding a problem and deciding how to fix it. This one is different, because the discovery crosses a line where “fix it quietly and move on” was never actually on the table. A tax miscalculation across a known window of international orders isn’t a configuration issue the team gets to resolve on its own judgment. It has legal and regulatory weight that belongs to people outside the war room, and pretending otherwise, even with good intentions, would have been a much bigger risk than the original bug.

What’s worth noticing is how unremarkable the decision to disclose actually was, once it got made. Marge’s line, “Feld needs to know today, not after go live,” isn’t dramatic. It’s the obvious, boring, correct call, and it’s only notable at all because of everything the party has learned about this project over twelve episodes: two prior go live attempts where the vague language of “data quality issues” let real problems go unnamed. Feld himself sitting through disclosures he could have made and didn’t. The default on this project, before this episode, was to let uncomfortable news dissolve into something softer before it reached the person who needed to hear it clearly.

Feld’s response is the real payoff of everything episode seven and eight built. He doesn’t get defensive. He doesn’t ask if it can wait. He reads the finding standing up, makes the harder call immediately, and then does something a lot of sponsors never manage: he notices out loud that the team told him the truth without being forced to, and says so, rather than treating honesty as the baseline he was owed all along.

What happens next

Audit and legal are engaged, the timeline is adjusted to account for it, and the party heads into the final stretch with every major fire from the last twelve episodes either resolved or actively being managed in the open. Cutover weekend arrives, and every fix built over the course of this campaign gets tested at once, live, in front of the whole company.

Next episode: Episode 14, Go Live Weekend, the campaign finale (coming soon)

If your team has ever found something that needed to go to legal or audit before it went anywhere else, you know exactly how heavy that meeting feels. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework built around surfacing findings like this one clearly and early, instead of letting them soften into something vaguer, start here: adnd365.com/start

The $286,000 Ghost on the Payroll: The Randstad Case

By
September 3, 2026
Uncategorized
Leave a comment

In 2009, a former branch manager at Randstad was sentenced to five years and one month in federal prison for wire fraud and aggravated identity theft. The scheme ran for three years before anyone caught it. The method behind it was almost boring, which is exactly why it worked.

What happened

Cynthia Whitehead used the real names of former Randstad employees, people who had already left the company, to generate wage payments through the payroll system. She then kept those “wages” for herself. From 2004 to 2007 she embezzled more than a quarter of a million dollars this way. She pleaded guilty on July 8, 2009, and was ordered to pay $286,388.37 in restitution on top of the prison sentence.

Nobody defeated a clever fraud control here. The scheme worked because a former employee’s identity remained valid and payable inside the system long after that person had stopped working there.

Why the gap existed

The failure point sits exactly at the boundary between two systems that were supposed to agree with each other: HR, which knew someone had left, and payroll, which kept generating payments as if they hadn’t. That boundary is where this kind of fraud always hides. It isn’t defeating a rule. It’s exploiting the fact that two systems of record were allowed to disagree for as long as nobody checked.

A termination event should be the kind of thing that instantly and automatically closes off every downstream ability to pay that person again. In practice, in a lot of ERP implementations, it’s a status field that gets updated in one module and trusted to eventually matter everywhere else. Three years of undetected fraud is what “eventually” costs.

Controls that would have caught it

The control here isn’t exotic. A payroll run should not be able to issue a payment to any employee ID with an active termination date, full stop, checked at the moment of disbursement rather than assumed from a status flag set once and never re-verified. In practice, this means the integration between the HR module and the payroll module needs to function as a hard gate on every pay run, not a background sync that payroll happens to respect most of the time.

The harder part isn’t designing that rule. It’s noticing that it needs to be designed at all, because on paper the termination process already “worked.” The employee’s status did get updated. Nobody had built the check that made that status update actually block a payment.

An AI prompt example for ERP fraud detection

This is a case where an AI-assisted review layer earns its keep, not by replacing the underlying control but by making it cheap enough to run constantly instead of only during an annual audit. Against the ERP’s HR and payroll data, a controller could run something like:

“List every payroll disbursement in the last three fiscal years paid to an employee ID with a termination date recorded prior to the pay period start date.”

A second, complementary query catches slower variants of the same pattern:

“Flag any employee ID that received a payment more than 30 days after their most recent termination or leave-of-absence date recorded in HR.”

Neither prompt requires new system functionality. Both require someone to think to ask the question on a recurring basis rather than only after a tip or an audit forces the issue. That is the actual lesson of this case. The rule that would have stopped it wasn’t complicated. It just wasn’t being asked.

The pattern for this series

This is the first case in a series looking at real, documented ERP fraud schemes: what happened, what shared assumption in the underlying system let it run, what a properly governed control looks like, and a concrete AI prompt that turns a periodic audit question into something that can run continuously. The goal is never to suggest AI replaces the governance. It’s to show what becomes possible once the governance exists and someone actually asks it the right question.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney’s Office for the Northern District of Georgia, a public government source. All facts, figures, and quotations describing the case are sourced from that release. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney’s Office, Northern District of Georgia. “Former Randstad Branch Manager Sentenced to Federal Prison for Embezzlement.” Press release, September 16, 2009. https://www.justice.gov/archive/usao/gan/press/2009/09-16-09c.pdf

Autopsy #13: The Competitive Bake-off Demo

By
September 3, 2026
Uncategorized
Leave a comment

Cause of death: the competitor being demoed against would not have recognized itself.

Midway through the pitch, the slide changes to a comparison. Two columns, sometimes three. Your product on one side, the competitor on the other, a row of checkmarks and X marks running down the middle. The competitor’s column is thinner than it should be. A feature they shipped eighteen months ago is marked absent. A limitation they fixed two releases back is presented as current. The pricing comparison uses the competitor’s list price against your negotiated discount. By the end of the slide, the choice looks obvious, because one column was built by a team with every incentive to make it look that way, and the other was built by nobody in the room.

Nobody in the room raises a hand and asks when this comparison was last verified. That’s the autopsy. A competitive comparison built entirely by one side, unchecked by the other, isn’t a comparison. It’s a résumé written by an opponent’s rival, and it gets read with the same scrutiny either way, which is to say, functionally none.

What actually happened

Every competitor’s product roadmap moves faster than any comparison sheet does. A gap that was accurate when a sales engineer built the deck eighteen months ago has, more often than the room assumes, already been closed, sometimes through a native feature, sometimes through a partner integration or a marketplace add-on that isn’t visible from the outside but is entirely visible to the competitor’s actual customers. The comparison sheet is a snapshot with no expiration date printed on it, presented as though it were current.

The pricing rows compound the distortion in a specific, predictable direction. List price for the competitor, negotiated or promotional price for the vendor doing the presenting, is close to the default comparison method, and it isn’t dishonest in the narrow sense, both numbers are real, but it compares two different stages of the same negotiation, one that hasn’t happened yet against one that has. A prospect who hasn’t negotiated with either vendor is looking at the least favorable version of one price and the most favorable version of the other.

Feature checkmarks suffer the same collapse the Security Theater Demo’s checklist suffered. “Supports multi-currency” or “has a mobile app” is either true or false on the slide, with no room to indicate that one vendor’s version is a fully native capability and the other’s is a third-party add-on with a separate contract, a separate support line, and a separate bill.

Why it works on smart people

A side-by-side comparison has the visual grammar of objectivity. Two columns, symmetric formatting, a neutral-looking checkmark or X, all of it borrows the credibility of a spec sheet or a lab test, something that feels like it was measured rather than argued. The room’s guard is lower here than almost anywhere else in the demo, precisely because the format looks like data rather than persuasion, even though the party assembling the data has an obvious and undisclosed conflict of interest in every cell.

There’s also a research-avoidance effect. Verifying even a handful of rows against the competitor’s actual current documentation, or a call with their team, takes real time that a sales cycle often doesn’t budget for, and the comparison slide offers a shortcut that feels like due diligence without requiring any. Accepting the slide as accurate is the path of least resistance, and it’s a path built specifically to be the easiest one to take.

The actual damage

This is the one that produces a decision built on a comparison that was already stale, sometimes badly, by the time the contract was signed. A capability marked absent for the competitor that had actually shipped means the losing vendor was disqualified on a false premise, and the winning vendor’s genuine advantages, whatever they actually were, never had to be defended on their own merits because the comparison did the work for them.

Once implementation starts, the gap between the comparison sheet and reality becomes the buyer’s problem, not the vendor’s. If the deciding factor was a feature gap that didn’t actually exist, the buyer is now living with a vendor selected on the wrong basis, discovering the real trade-offs only after the switching costs have become substantial.

The fix, if you’re the one presenting, or the one buying

If you’re presenting, date every comparison row and be specific about the source, and if there’s a real chance a competitor has closed a gap since, say so rather than let a stale advantage stand unchallenged. If you’re buying, treat any vendor-supplied comparison as a hypothesis to verify, not a finding to accept. Take the three or four rows that would actually change your decision and check them directly against the competitor’s current documentation or a live conversation with their team, rather than checking all thirty rows equally or none of them at all.

A comparison chart built by one side and verified by neither side is not a comparison. It’s an argument wearing a spreadsheet’s clothes, and it deserves exactly the scrutiny an argument gets, not the trust a measurement earns.

The Waterdeep Trading Company runs on the same principle at its literal gates. In Receiving Controls That Stop Bad Goods, nothing becomes sellable stock on the strength of a seal or a claimed count alone. It gets checked at the gate, every time, regardless of who’s vouching for it. A competitive comparison deserves the same standing policy: verify before it enters the decision, not after.

The Contoso Convergence, Episode 12: The Customization Nobody Remembers

By
August 31, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 12 of 14.

Previously on: Episode 11, Character Sheets, Denise’s caution turned out to be expertise nobody had asked about, and Vex offered to dig into the field she’d learned to distrust, the one that was wrong about one time in six.

Two weeks to go live. Everything on the ledger side finally looks green. This episode, that calm gets interrupted by something nobody was even looking for.

The Session

Vex: (deep in the code) Found something. There’s an override on tax calc. It only fires on international orders.

Thorne: Since when?

Vex: Git blame says two years ago. Author’s account is deactivated.

Sable: Do we know why it exists?

Vex: No comments. No ticket reference. Just a hardcoded exception for a specific country tax code.

Ai. Cassiopeia: I searched historical support tickets. There is a closed ticket from that period referencing an audit finding. No resolution notes attached.

Marge: Two weeks to go live and we’ve found a silent override to statutory tax logic with no documentation and no author.

Thorne: We can’t ship blind on tax. Not this close to the finish line, not this category.

Vex: I can reverse engineer what it’s compensating for. Give me two days.

Vex disappears into the code for the better part of the next two days, surfacing occasionally for coffee and increasingly specific questions.

Vex: (day one, afternoon) This override is doing something very deliberate. It’s not sloppy code. Whoever wrote this understood the tax engine at a level most consultants never bother to reach.

Sable: That’s not reassuring. That’s more unsettling.

Vex: (day two, morning) I think I found the audit finding it was responding to. There’s a gap between how the platform’s native tax engine handled a specific cross border scenario two years ago, and how the actual tax authority required it to be handled. Someone found that gap during an audit, panicked, and built this override to close it fast.

Thorne: Did it work?

Vex: (pulling up a comparison, going quiet) I need another hour before I answer that honestly.

Two days later, Vex has the answer, and it’s not what anyone expected.

Vex: The platform fixed the underlying bug in an update about eighteen months ago. This override is still running. On top of the fix.

The patch that outlived the problem it solved

An override built under audit pressure, with no documentation and a deactivated author, is exactly the kind of artifact that should terrify anyone doing a go live readiness review. But the actual failure here isn’t the override’s existence. Overrides built in a hurry, in response to a real and urgent finding, happen constantly, and they’re often the right call in the moment. The failure is that nobody built in a mechanism to revisit it once the underlying platform caught up.

That’s a subtly different problem than most of what the party has found so far. The shadow ledger, the TEMP dimension, the silent integration, all of those were things nobody built correctly the first time. This one was built correctly, for the moment it was built in, by someone who clearly understood the tax engine well enough to solve a genuinely hard problem under real pressure. The failure happened later, quietly, when the platform vendor shipped a fix and nothing in Contoso’s environment ever checked whether the original workaround was still needed.

This is the maintenance half of technical debt that almost nobody plans for. Everyone budgets for building the workaround. Almost nobody budgets for the moment, months or years later, when the reason for the workaround quietly disappears and the workaround itself doesn’t. A patch with no expiration date and no owner just keeps running, doing whatever it was built to do, whether or not that’s still the right thing to do.

What happens next

The platform fix and the old override are now both active, which means international tax has likely been calculated twice for a very long time. The party has two weeks to go live and a discovery that reaches back much further than two weeks, into territory that’s going to need more than an engineering fix.

Next episode: Episode 13, The Audit Trail (coming soon)

If your environment has a workaround built in response to a problem that might already be solved somewhere upstream, this episode is worth sitting with. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework built around giving every workaround an owner and an expiration date, start here: adnd365.com/start

Time and Tokens

By
August 31, 2026
Uncategorized
Leave a comment

There used to be a saying in the business world: everything can be done with time and Excel. Give a competent analyst enough hours and a blank spreadsheet, and there was no forecast, no reconciliation, no reporting problem that couldn’t eventually be solved. Excel wasn’t fast. It wasn’t elegant. But it was infinitely general purpose, and it always did exactly what you told it to do, cell by cell, every single time.

The saying is starting to change. People are now saying everything can be done with time and tokens.

It’s worth taking that seriously, because it’s not just a joke about AI hype. Something real shifted underneath it.

What Excel actually required

The old saying hid a dependency that everyone quietly understood. Excel could do anything, but only if a human already knew what “anything” looked like. Someone had to understand the business problem, decide what the model should compute, structure the formulas, and catch the errors when a dragged cell reference pointed at the wrong row. The tool was general. The thinking was not automated at all. Time, in that saying, mostly meant the time it took a skilled person to build and rebuild the model until it matched reality.

That is why “time and Excel” was a saying about human effort as much as it was about software. The spreadsheet was a canvas. The intelligence was still entirely yours.

What tokens change

A large language model flips part of that arrangement. You can now describe a vague, half formed problem in plain language and get something usable back without doing the structural thinking first. The model proposes the categories, drafts the formulas, writes the summary, or builds the first pass at a plan. Tokens, in the new saying, stand in for both the words you feed the model and the compute it burns iterating toward an answer.

This is a genuine capability shift, not just a rebrand of the old joke. With Excel, the bottleneck was almost always model construction. With a language model, the bottleneck moves toward specification and verification. You spend less time building the machine and more time describing what you want and checking whether what came back is actually right.

That is a real change in where human effort goes. It is not a small one.

Where the analogy breaks

It would be tidy to say tokens simply replaced Excel, but that’s not quite what’s happening, and the difference matters more the higher the stakes get.

Excel’s defining property was determinism. A formula produces the same output from the same inputs every time, and you can trace exactly why. That traceability is not a nice to have in finance, operations, or compliance work. It is the entire point. An auditor does not want to hear that the number is “probably right.” They want to see the formula.

Tokens do not offer that guarantee. A language model produces a plausible answer, and plausible is doing a lot of work in that sentence. Ask the same question twice and you may get two different, both reasonable sounding, results. For a first draft, a brainstorm, or a rough model, that is a feature. For a general ledger reconciliation, it is a liability.

So the honest version of the new saying is not that tokens replaced Excel. It is that tokens increasingly generate the Excel. The model drafts the formula, proposes the pivot, writes the first pass at the model, and a deterministic engine, spreadsheet or database or ERP calculation, still does the actual execution. The two are stacking, not swapping.

The bottleneck didn’t disappear, it moved

The old saying implied that with enough time, Excel could solve anything, and the effort lived in building the model correctly. The new saying implies that with enough tokens, a model can solve anything, and the effort lives somewhere else now: in asking the question well and in checking the answer carefully.

That is arguably a harder skill to teach than spreadsheet formulas ever were. A bad formula usually breaks visibly. A bad prompt often produces something that looks complete and confident and is wrong in a way that takes real domain knowledge to catch. The scarce resource used to be knowing how to build the model. Increasingly, the scarce resource is knowing enough about the problem to tell a good answer from a good sounding one.

Why this should sound familiar

Anyone who has sat through an ERP vendor demo has already seen a preview of this exact pattern. The demo always ends the same way: with the confident implication that the software understands your business and can just handle it, no configuration debt, no data cleanup, no edge cases. Excel never made that promise. It never pretended to understand your problem. It just calculated exactly what you told it to.

Tokens, by contrast, come wrapped in the same confident tone as the demo. The output reads fluently. It sounds like understanding. Whether it actually reflects your business, your chart of accounts, your specific edge case, is a separate question that the fluency does nothing to answer.

That is the real risk in the new saying, and it has nothing to do with the technology’s capability. It is the same trap the old vendor demos set: mistaking a confident answer for a correct one. Excel forced you to see your assumptions in the formula bar. Tokens can hide them in a paragraph that sounds like it already checked.

The updated version

Everything can still be done with time and Excel. That has not stopped being true. What’s changed is that tokens now do a lot of the early modeling work that used to eat the time. The saying isn’t wrong to update. It’s just missing a clause.

Everything can be done with time and tokens, as long as someone still knows enough to check the work.

Autopsy #12: The Executive Sponsor Cameo

By
August 28, 2026
Uncategorized
Leave a comment

Cause of death: confidence borrowed from someone who was never actually going to be there.

Ten minutes into the meeting, or sometimes ten minutes before the end of it, a calendar notification pulls someone senior into the call. A VP, sometimes higher. They say a few warm, general things about strategic partnership and long-term vision, take one or two softball questions, and leave for their next meeting. The room’s posture changes almost immediately. If someone at that level is personally invested enough to show up, even briefly, this must really matter to the vendor. The deal, whatever doubts existed five minutes earlier, now feels more serious.

Nobody asks what “personally invested” is actually going to mean six months from now, when the invoices are contested, the timeline slips, or the implementation team needs an escalation path that goes higher than the account manager. That’s the autopsy. The executive’s presence proved that a calendar invite got accepted. It proved nothing about what happens after the meeting ends.

What actually happened

An executive sponsor cameo is a highly efficient transfer of credibility from a person to a deal, and the transfer costs the vendor almost nothing to make. Ten minutes of a VP’s time is genuinely cheap relative to the deal size being discussed, and the effect on the room is entirely disproportionate to that cost, because the audience reads presence as commitment. It rarely is. In most organizations selling anything of this size, senior leaders make these appearances routinely, across many simultaneous deals, as a normal part of their job, not as a signal that this particular account has been elevated to a special tier of personal attention.

The deeper issue is that the thing actually being evaluated, whether the vendor will show up when the implementation gets hard, is not a property of any one person’s goodwill. It’s a property of organizational structures: escalation paths, contractual service levels, account team continuity, whether the people doing the actual implementation work have the authority and resources to fix problems without waiting on approval from someone three levels up. None of that gets tested by a cameo. A cameo tests whether an executive’s assistant could find a ten-minute gap in a calendar.

There’s also a durability problem the cameo doesn’t address. The VP who dropped in with warm words about the partnership may be gone, reorganized, or reassigned to a different portfolio before the implementation is even a third of the way done, which happens routinely in any organization above a certain size. The relationship the room felt reassured by was never actually contracted. It was a mood, generated in a room, that has no mechanism for surviving contact with an org chart six months later.

Why it works on smart people

Status carries information in most human interactions, and that heuristic is usually reasonable: when someone senior spends scarce time on something, it often does signal real priority. The problem is that the heuristic breaks down specifically in situations, like enterprise sales, where the cost of the senior person’s time has been deliberately minimized to make the signal cheap to send. A genuine ten-minute cameo and a fully commissioned, resourced executive sponsorship look identical for the ten minutes you can observe them. They diverge entirely in the six months you can’t.

There’s also a reciprocity dynamic at play. A senior person taking time to personally reassure you creates a mild social obligation to receive that reassurance graciously, not to interrogate it. Asking a VP who just delivered warm remarks about partnership to specify exactly what escalation authority they’re personally committing to feels confrontational in a way that asking the account manager the same question doesn’t, so the question quietly goes unasked at exactly the moment it would have been most useful to ask it.

The actual damage

This is the one that surfaces the first time something actually goes wrong during implementation and the buyer tries to use the relationship they thought they’d built. The champion emails the VP directly, the way the cameo implicitly invited them to, and gets a response from an assistant, or a redirect back to the account team, or silence, because the VP’s actual involvement was never structured to include personal escalation on operational issues. The confidence the room felt in that meeting has no contractual or organizational form. It was real in the room and evaporated the moment it needed to be load-bearing.

The buyer is left in a worse position than if the executive had never appeared at all, because the cameo specifically substituted for asking the harder, more useful questions about actual escalation paths and account team continuity, the answers to which would have held up regardless of who was in what job six months later.

The fix, if you’re the one presenting, or the one buying

If you’re presenting, don’t let the cameo stand in for structure. If an executive is genuinely sponsoring the account, say specifically what that means: a defined escalation path with their name attached, a commitment to a quarterly check-in that’s on a calendar rather than implied, actual authority to authorize resources if the implementation hits trouble. If none of that exists, the honest version of the cameo is shorter and less dramatic, a courtesy visit rather than a commitment, and it should be presented as exactly that.

If you’re buying, ask the question the warm remarks were designed to make feel unnecessary: what happens, specifically, and who do we call, when this goes wrong. The answer that matters is a name and a process that survives a reorg. The ten minutes in the room, however sincere, was never that.

Genuine organizational attention rarely looks like a scheduled cameo. In The Penguins Knew Before Your Steering Committee Did, the character who actually notices the iceberg melting and does something about it is an unremarkable penguin, not the colony’s formal leadership showing up to reassure everyone for ten minutes. The steering committee structure is the cameo. The attention that actually matters usually comes from somewhere quieter.

The Contoso Convergence, Episode 11: Character Sheets

By
August 28, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 11 of 14.

Previously on: Episode 10, The Wayfinder’s Gap, the party discovered that Contoso’s ninety four percent training completion rate measured attendance, not competence, and that six of eight power users couldn’t complete a basic order to cash cycle without help, three weeks before go live.

A readiness assessment tells you who’s struggling. It doesn’t always tell you why. This episode, the party finds out that the worst score in the room might be measuring exactly the wrong thing.

The Session

GM: The party builds character sheets for each of the eight power users: role, current XP, gaps, and a coordinate on the Wayfinder’s Network showing where they stand versus where they need to be.

Sable: Denise scored lowest on the readiness test. Struggled with three of five scenarios.

Ai. Cassiopeia: I pulled her transaction history for context, as requested. She has the lowest error rate of any user in AP. By a wide margin.

Marge: How does someone with the lowest error rate score lowest on a scenario test?

Vex: Because the test measures speed and screen navigation. It doesn’t measure judgment.

Thorne: She’s not undertrained. She’s over cautious, because she’s the one who’s been quietly catching everyone else’s mistakes and never gets asked how she knew to check.

Denise: (overhearing from the doorway) Nobody asked, so I didn’t say anything.

The room turns. Denise steps in, arms crossed, more defensive than embarrassed.

Marge: Denise, walk us through why you struggled on the partial shipment scenario.

Denise: I didn’t struggle. I stopped. There’s a field on that screen that’s populated wrong about one time in six, and if you don’t catch it before you post, it throws off freight allocation two steps downstream. The test wanted me to move fast. I’ve learned not to move fast on that screen.

Sable: (quietly) That’s not a training gap. That’s institutional knowledge nobody documented.

Denise: I mentioned it once, in month two. It didn’t go anywhere, so I stopped mentioning things.

Ai. Cassiopeia: I recommend her proficiency path include a mentor tier, not a remedial tier.

Vex: Denise, that field, the one that’s wrong one time in six. What’s actually causing it?

Denise: (pausing, surprised to be asked) I always assumed it was a timing issue with the freight feed. Nobody ever asked me to look closer.

Vex: I have some time this afternoon. Want to look closer together?

Denise: (a beat, then) Yeah. Actually, yeah.

The party rebuilds the plan. Denise goes from “at risk” to “quiet expert” in one conversation, and the readiness map shifts under everyone’s feet.

What a readiness score actually measures

Every assessment measures something specific, and it’s worth asking exactly what before you trust the score it produces. Contoso’s readiness test measured speed and screen navigation under time pressure. That’s a reasonable thing to measure, but it’s not the same thing as competence, and Denise is the proof. Her caution wasn’t a skill gap. It was a defensible, earned response to a system that had already burned her once, and the test penalized the exact behavior that was protecting the business every single month.

The more troubling detail isn’t the test design, though. It’s that Denise had already raised this issue once, in month two, and it went nowhere. That’s the part that should sting a little, because it means the information the party needed was sitting in the building the entire time, just not in a form anyone had built a channel to receive. Nobody was hiding it from her. There was simply no mechanism that treated a frontline observation from someone without formal standing as worth following up on.

This is the actual argument for a proficiency system that includes mentor tiers alongside remedial ones. A readiness score that only sorts people into “needs help” and “doesn’t need help” throws away the most valuable signal in the data: the person whose caution is actually expertise wearing an unflattering score. Vex asking Denise to look closer together, instead of just logging her workaround and moving on, is the moment this episode is actually about. Competence that never gets asked a follow up question stays invisible indefinitely, no matter how many times the person tries to mention it.

What happens next

Denise’s insight reshapes the readiness map and buys the team a genuine mentor for the seven days that remain. But rebuilding proficiency around real expertise instead of raw scores means someone finally has to go back into the system Denise flagged, and what Vex finds when he looks closer is worse than a timing issue with the freight feed.

Next episode: Episode 12, The Customization Nobody Remembers (coming soon)

If someone on your team has mentioned a workaround once and then quietly stopped bringing it up, this episode is for them. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a system built to actually catch signals like Denise’s instead of losing them in a scorecard, start here: adnd365.com/start

Is Vibe Coding the End of Standardized ERP?

By
August 27, 2026
Uncategorized
Leave a comment

I have heard rumours that some companies are starting to vibe code their own ERP systems. Is this the start of the decline of standardized ERP systems, and the start of company specific Business Operating Systems? If every business had its own OS, and an agentic framework, why is there any need to have standardized ERP systems?

It is a fair question, and one worth taking seriously instead of dismissing on reflex. But after digging into what is actually happening in the market, I do not think ERP is dying. I think something more interesting and more useful is happening at its edges.

What Companies Are Actually Vibe Coding

The companies experimenting with AI generated business software right now are almost entirely building at the periphery of ERP, not in its core. A Copilot Cowork style agent that reconciles a report. A custom approval workflow. A data cleanup script. A bolt on dashboard that nobody wanted to wait six weeks for IT to build. Very few organizations are vibe coding their general ledger, their costing engine, or their multi entity intercompany eliminations, and there is a good reason for that.

There is a real gap between “AI helped me build software” and “AI helped me build enterprise grade, auditable, multi user, transactionally consistent financial software.” That gap is where most of the current enthusiasm quietly runs out of road. One recent piece on the risks of vibe coding put it plainly: the danger is not that these tools fail to work. The software appears to work right up until the business reaches a level of complexity that exposes what was never built in the first place. Security, monitoring, compliance, and disaster recovery do not show up in a demo. They show up eighteen months later when something breaks and there is no vendor to call.

We Have Been Here Before

There is also a useful historical echo worth remembering. Standardized platforms like SAP, Oracle, PeopleSoft, and later NetSuite and Salesforce did not emerge in a vacuum. They emerged because “build your own” had already been tried extensively in the eighties and nineties, and the industry collectively decided that a professionally maintained, continuously improved, shared system was the better bargain. One system, supported by a vendor with thousands of customers absorbing the cost of getting tax law and audit controls right, beat a thousand bespoke systems each carrying that burden alone.

Vibe coding does not remove the reasons that decision was made three decades ago. It just lowers the upfront cost of relearning them the hard way.

Two Layers That Want Different Economics

The question of “why standardize if every business can have its own OS” collapses two layers of the business that actually want very different things.

The first layer is the system of record. This is the ledger, inventory, costing, tax, and consolidation logic. This layer wants low variance, not customization. Its value comes from being provably correct under audit, from producing the same math every quarter regardless of who is running the company, and from a vendor carrying the liability of getting VAT rules or SOX controls right across thousands of customers instead of one company carrying that risk alone. Agentic capability does not change the incentive to pool that risk and cost across an ecosystem. If anything it raises the stakes, because an agent posting a bad journal entry at two in the morning with no human review is a considerably scarier proposition than a person doing it.

The second layer is orchestration. This is how a specific company actually gets things done around that system of record. This is exactly where variance is valuable, and exactly where agentic frameworks and vibe coding are already winning, because it is low blast radius, fast changing, and does not need to survive a financial audit on its own merits.

The Composable Core, Not the Bespoke Empire

So the more likely outcome is not that every business ends up building its own ERP from scratch. It is something closer to a composable core: a thin, standardized, vendor maintained transactional spine, surrounded by a thick, company specific, largely agent authored layer of workflow, automation, and decision logic that talks to that spine through APIs. This is not a new architecture invented for the agentic era. It is basically the direction that platforms like Dynamics 365 Finance and Operations were already heading, with data entities and business events designed precisely so that logic could live outside the core without touching it.

The Business Operating System that gets discussed in these conversations is real. But it gets built on top of standardized ERP, not instead of it, because nobody actually wants to own tax engine liability, and no CFO wants to explain to auditors that the general ledger was vibe coded last quarter.

Where the Real Disruption Sits

If I had to point at where this trend genuinely threatens the standard ERP model, it would be three places.

The mid market and small business segment, where compliance and audit stakes are lower and the cost of a full ERP license and implementation is disproportionate to the size of the operation. This is where skipping a Tier 2 ERP entirely in favour of an agentic build of the operations layer is most economically rational.

Verticals with no good off the shelf fit, where companies already customize ERP into something barely recognizable compared to the base product. Vibe coding just makes that customization faster and cheaper. It is not a fundamentally new behaviour, it is an acceleration of an old one.

And the vendors themselves, who will not sit still and watch this happen. Expect Microsoft, SAP, and Oracle to lean hard into a “we are the trusted core, bring your own agents to the edges” positioning rather than fight the trend directly. Given where Copilot and Cowork are already headed inside the Microsoft ecosystem, this is not speculation. It is already the direction of travel.

The Verdict

Vibe coding is not the death of standardized ERP. It is the arrival of a cheap, fast way to build the layer of the business that ERP vendors were never well suited to build in the first place. The ledger stays boring, standardized, and vendor owned, because boring is exactly what you want from something an auditor has to sign off on. Everything wrapped around it just got a lot more interesting.