AI in the Enterprise

Every process in your company has a documented path and an actual path. The documented one is in the training deck and the configuration. The actual one sits in the heads of the people who have run it for years, and it is the one producing the result.

A model gets the first and not the second. It is therefore right on the routine case, which is already the cheap one, and confidently wrong on the exception, where the money is.

What actually happened

Polymath’s founder was chief operating and strategy officer of an enterprise data and AI platform company and general manager of its AI applications business: product strategy, the roadmap, delivery of the prebuilt applications, their P&L, and the go-to-market beneath them. Before that he ran enterprise data, analytics and AI strategy across three commercial segments of a private consumer packaged goods business of roughly $2–3 billion in revenue that had since gone public on the TSX.

A prebuilt application is a bet that a process is standard enough to arrive with its logic already inside it. Ship enough of them and you learn exactly where that bet holds. It holds on the documented path. It stops at the first case the documentation does not cover, which in Order-to-Cash is the disputed line, the credit hold, the account trading on terms nobody can produce.

The pattern repeated, and it was never an engineering pattern. The application performed. Then it reached a decision requiring knowledge of which exception this customer permitted, which approval was genuinely required rather than nominally listed, and which of two systems governed when they disagreed. Nobody could answer — not because the answers did not exist, but because they sat with three people and had never been written down. That question was the longest item on every plan.

It changed how the applications business packaged and sequenced the work. A plan assuming the context existed was a plan that missed its date, so it had to be named, scoped and owned before anything went near production. That is not a caveat you enjoy putting to a buyer who has just watched a demonstration.

He had seen the same shape from the other side of the table. Running data and insights for a chief executive, the team automated demand planning. The forecast was good, and it was overridden constantly, by planners who were usually right. A retailer had moved a shelf reset. A launch had slipped and the marketing weight moved with it. None of it was concealed; it had never been asked for in writing. The integrations taught it again. When two systems disagreed on an effective date there was a right answer, everybody knew it, and it was written nowhere.

Two chairs on opposite sides of the same table. Nothing he has watched stall was stalled by the model.

Clients bring Polymath in to name and scope that judgment before anything goes near production, which is the part of an AI programme that has never once been the model.

Why it happens

The documented path is written for the case the process was designed around. Reality supplies cases it was not, and somebody decides what to do with each. That deciding is the gap between the two paths, and it is judgment, not error.

It has a consistent shape. Almost every instance reduces to three questions: which exception is acceptable, which approval is really required, which of two sources wins when they disagree.

People acquire the answers by working beside somebody who already has them, then apply them without noticing. Ask an experienced person to describe the job and you get the documented path back, because that is the version with words attached. The other has never been contested, so it has never had to be articulated — not evasion, but what expertise feels like from the inside.

Configured systems ran only on the documented path, and that was tolerable because the boundary was explicit. A workflow handles a bounded transaction and routes anything unusual to a person by design. The exception had someone on it because the system could not pretend otherwise.

Hand a model the process and you hand it the exceptions too, and it answers all of it.

A rules engine fails visibly at the edge of its rules. A model fails plausibly, on exactly the case nobody wrote down. The economics run against you. The documented case is cheap because it is routine, and routine because it was standardized years ago and probably automated then. The cost sits in the exceptions: the disputed invoice, the non-standard term, the country that files differently. That is where cycle time, margin leakage and control risk live. The pilot performs, production disappoints, and the shortfall is read as a capability problem.

What is in short supply is written judgment, built by hand, one process at a time, by asking the people who hold it. That sounds like an argument for not starting. It is the opposite: the output is not consumed by whatever reads it. A written actual path serves the next system, the next redesign, the next audit, the next joiner.

The strongest objection

The obvious objection: models keep getting better, and this constraint dissolves on its own.

Half of it is right, and it is the half executives underestimate. Capability improves faster than enterprise planning cycles assume, and a limitation that justified waiting last year rarely justifies it now.

But capability is not the missing input. No amount of reasoning tells a model that your approval threshold applies to committed value rather than invoiced value, or that when two records disagree in one country the payroll source governs the filing and the HR source governs the reporting. Those are not facts about the world that training captures. They are decisions your company took, often without recording that a decision had been taken. Improvement makes a model better at using context; it cannot manufacture context that does not exist.

The stronger objection: it can watch our systems and infer the actual path from what people did. Partly true; the logs hold something. But a log records the outcome, not the reason. You can see an exception was approved. You cannot see it was approved because the account sat inside a renewal window, and the reason is the only part that generalizes. Observation gives you the frequency of a decision, not the rule.

The method

We run six steps, in this order. Two and three are where we do the work; the rest are what make it compound.

1. We choose processes by where the exceptions cost you, not by where the volume is. We rank your candidates by the cost carried in their non-standard cases: rework, delay, dispute, write-off, control findings. The trade-off we accept: routine high-volume work makes a better demonstration and is easier to fund, so we are choosing the harder story deliberately. Skip it and you automate the half that was already cheap and learn nothing about the half that is not.
2. We write the actual path by interview, starting with whoever handles what goes wrong. Not the process owner, not the training material. The person everyone rings when it is odd. We ask what they did the last three times, and why. The trade-off we accept: it is slow work, and it consumes the time of exactly the people you can least spare from the line. Skip it and you have encoded the operating procedure, which everybody already had and nothing was failing on.
3. We put the three questions to every step until we get a specific answer. Which exceptions are acceptable and on whose authority. Which approval is genuinely required rather than nominally listed. Which source governs when two disagree, and for what. The trade-off we accept: we surface disagreements the current vagueness keeps quiet, and a few need an executive to settle rather than a workshop. Skip it and you have written a longer procedure.
4. We treat the written path as an owned asset, not as a prompt. We version it, and we name an owner on your side who updates it on the same cycle that changes the process. The trade-off we accept: a maintenance obligation nobody volunteers for, and a stale actual path is worse than none, because it will be believed. Skip it and it degrades into the deck it came from, and the next team pays full price again.
5. We keep a person on the exception path and record where they disagreed. We route exceptions to a person and capture where they decided differently, and why. That disagreement log is the only source of judgment our interviews missed. The trade-off we accept: it caps the near-term saving, because the exceptions are the expensive part and we have kept somebody on them. Skip it and you never find the cases nobody remembered.
6. We prove reuse on a second process before extending anywhere else. We pick a second process on adjacent ground, and we measure how much of the first written path it takes unchanged: approval logic, authoritative sources, exception categories. The trade-off we accept: it gets chosen for adjacency rather than for whoever asks loudest, a political cost we pay early. Skip it and you accumulate pilots that each carry their own context cost and never compound.

Notice which kind of work this is. It is not analytics and it is not a platform choice. AI doesn’t just need data. It needs context — and the context we write is specific and unglamorous: who initiates, who may approve what, which exception is permitted, which source governs, where the handoff goes. That is what a role record holds once we extend it past job, family, level and skills into decision rights, controls and system access. Step six is where the economics turn: the second process on the same ground should cost materially less than the first.

Evidence and measures

One process, written twice. The right-hand column exists nowhere:

Five measures worth tracking over ninety days. None of them requires a new system:

— For one process, the share of transactions completing the documented path with no deviation. Expect a number that is uncomfortable to circulate.

— How many steps produce two different answers when two experienced people are asked which source governs.

— Of last quarter’s exceptions, how many carry a recorded reason rather than only an outcome.

— How long a capable new joiner takes before deciding an exception without checking with a colleague. That interval is the size of the undocumented path.

— Of the written path for your second process, the share taken unchanged from the first.

If those move, you are accumulating something that holds value. If only the pilot count moved, you are renting capability one process at a time.

How Polymath solves this

We start where your deployment stalls rather than at a use-case workshop, and we run it as AI Enablement. In the first weeks we take one process — the exception path in Order-to-Cash — and for every decision an application or an agent would take we write down four answers: which exceptions are permitted and on whose authority, which approval is real, which source governs when two systems disagree, and what may proceed without a person. We take those answers from the role record, extended past job, family, level and skills into decision rights, controls and system access. That is Job Architecture 2.0, and it is where an agent’s permissions come from.

We build the context rather than advise on it. Our people have shipped AI applications into enterprises and run the processes on the receiving side, and we write the answers into your workflow, identity and platform configuration with the people who handle your exceptions and the owner who will keep the written path current, then test them on live exceptions. After that they run it and we step back.

What compounds is that this layer is independent of whatever runs on top of it. Applications and models get replaced; a written account of who may decide what, under which control, at which threshold, does not. Your second process inherits the approval logic and sources of the first, and each new agent draws its permissions from definitions your enterprise already holds. That is why the second process costs less than the first, and the one after it costs less again.

What it costs to do nothing

The running cost is already being paid. Exceptions consume your most experienced people on work that is context-heavy rather than difficult: senior capacity spent on the past rather than on what lies ahead. The second cost is that every attempt stalls at the same boundary. An initiative reaches the exceptions, stops, and is written off as a limitation of the technology. The next starts from zero and pays the same context cost again, because the first wrote nothing down.

The third is concentration risk with a notice period attached. An exception path living only in one person’s judgment leaves when they do, and cannot be recovered by asking their replacement. The functions with the deepest tacit knowledge have the longest-tenured people.

Whatever you run on top of the process will be replaced. A written account of how your company actually decides will not, which makes it the only part of this worth owning — and writing it, on one process, is where we start with you.