The short version
Business software was built for people. It enforced the share of the company's rules that were easy to code. The rest lived in people: in their training and judgment, in the policy manual, in the habit of checking with legal before signing. The software never had to be complete, because a person was always there to fill the gap.
AI agents remove that person. Whatever the software doesn't contain, the agent doesn't know. And the new decision models, which answer typed questions in a fraction of a second, supply judgment, not authority. They can say what is likely. They cannot say what the firm has committed to.
The central finding of this paper: for agents to take over the work, the firm's ruleset must be built into the core of the software, not added on afterward. Not scattered across code, manuals and people's heads, and not bolted on as prompts or monitors.
Speed is why. Agents run the firm at machine speed: decisions in milliseconds, around the clock, each agent handing its work straight to the next. Speed becomes the competitive weapon, and there is no time left for a person to review the work. For forty years that review was the control. Keep it and you lose the race; drop it with nothing in its place and you lose control. Only one shared, live and complete set of rules, from the firm's contracts and policies down to the laws it must obey, can check every action before it happens. Complete rules, in one place, are what let a firm go fast.
Software was built for people
For forty years, business software has been designed for a person at a screen, doing one task at a time:
- Screens and forms show each person the slice of information the task needs.
- Workflows walk them through the steps and hand the work on at each approval.
- Roles and permissions mirror the org chart: who can see what, approve what, and must not do both.
- Reports compress the business into something a manager can absorb in minutes.
- Training and manuals cover what the software doesn't say: when to escalate, which customers get exceptions, what the contract really allows.
This was not a mistake. People can only hold so much in their heads, so software, like the organization itself, broke the work into pieces small enough for one mind.
What matters is what it left out. The software enforced the rules that were easy to code: a $10,000 approval limit, a required field, a credit check. Judgment calls, contract terms and exceptions it left to people, who handled them with an email, a phone call or a note in the file.
The human user was the real rulebook, and the real control. The software's gaps stayed invisible because people quietly closed them every day.
Agents remove the person who held the rest of the rules
Companies are now rebuilding their software for AI agents: APIs instead of screens, and agents that read records, call systems, send messages and move money.
But when the agent replaces the person, it also replaces the rulebook that person carried. An agent doesn't know that this customer always gets net-60 terms, that the credit agreement caps this kind of payment, or that claims after a flood need a second look. If those rules aren't in the software, the agent doesn't have them.
And it fails at scale. A clerk who misreads a policy makes a few mistakes before someone notices. An agent repeats the misreading on every transaction it touches, around the clock, with no quiet hour in which a supervisor reviews the day's work.
In the old design, applications held the data and people held the decisions. The applications are the ore. The decisions are the gold.
The arrival of decision AI
In September 2026 a new category of model appeared: decision AI. These models don't write text. They take a situation and a typed question, and return a typed answer with a probability: a choice among named options, a score, or the likelihood that a statement is true. Within weeks one of the largest AI labs launched its own, and the category was established.
They are fast and cheap enough to be called on every invoice, ticket or claim. More important, they prove that a decision can be lifted out of an application and served on its own. For forty years the decision was buried inside the app. Now it is a component.
But they return judgment, not authority: this claim most likely involves flood damage; this refund is probably appropriate. They can't say which rule applies, who may approve, or what the contract permits. They hold no memory of the firm, and the text they are given can sway them. Early practitioner guidance already pairs them with a hard rule, so the model can raise a risk level but never push it below a fixed floor. That is this paper's finding in miniature: probabilistic judgment needs a deterministic frame around it.
Every automated decision has three parts, and decision AI covers only the first:
- Judgment: what is likely true, and which option looks best.
- Admissibility: which actions the firm's commitments, policies and authorities allow.
- Execution: whether the chosen action can be committed against the business as it stands right now, without colliding with anything else.
Decision AI makes judgment callable. A shared model of the firm makes decisions composable. A controlled runtime makes their execution safe. Decision AI doesn't remove the need for the firm's rules. It makes that need urgent.
Why bolting the rules on doesn't work
The first instinct is to add the missing rules on top of existing software. Every version falls short:
- Rules in a prompt. Answers drift with the model and the wording, and nobody can prove which rule was applied.
- Monitors and guardrails. They catch problems after they happen. By then the payment has gone out.
- Each app adds its own rules. Billing, claims and sales each encode their own version, and the copies disagree.
- Consultants hand-code the rules. The result is a portrait of a living company, out of date the day it's finished.
- Decision AI on its own. Judgment without authority. The firm's commitments still live nowhere the model can see.
All of these treat the rules as an add-on to software designed for people. That is the mistake.
The finding: build the rules into the core
Agents can only take over the work if the firm's rules sit at the center of the software, not around its edges. We call that center the Enterprise World Model: the firm's commitments, authorities, constraints and current state, written down once, owned by the company, and consulted by every application, agent and decision model before anything happens. This reverses how software has been built. The rules come first, and applications, screens, agents and decision models are built on top of them.
That doesn't mean rebuilding everything. A firm can put the rules over the systems it already runs, which keep the records and keep executing, or build new applications on the rules from scratch. Either way, "at the core" means four things:
- The rules are objects, not code. Each limit, authority, contract term or exclusion is written once, with its source and its owner, in a form both machines and people can read.
- Software is built from them. When the credit agreement changes, the rule changes, and every application follows.
- Agents act inside them. An action the rules don't allow is never on the menu.
- Decision AI works within them. The rules frame the question, the model supplies the judgment, and the rules check the answer.
Consider an insurance claim filed after heavy rain, where the adjuster's note says water came in from the river. A decision model judges, with high confidence, that the cause is flood. The policy excludes flood, so "approve" is not an available action; "deny" and "pay partial" remain. Had the model's confidence been low, the claim would have gone to an adjuster rather than be guessed. Paying anyway is an exception: it routes to a person with the authority to grant it, and it is recorded. Every step names the rule it followed.
Why the rules must live in one place: speed
The firm that decides fastest quotes first, ships first, and pays and gets paid first. Agents make that possible, and human review can't keep up: the approval queue, the second signature and the month-end check become the slowest links in the chain. Something has to replace them at the same speed as the agents. That is the rules, checked against every action before it happens, and it only works if every agent sees the same rules at the same moment.
Agents also never stop. The human organization quietly relied on its pauses: the shift handover, the morning approval queue and the month-end close were each a checkpoint where someone applied the rules nobody had coded. In a 24x7 operation there is no "later" in which to check, and the ground keeps moving. A payment released at 2 a.m. changes the cash available for the one at 2:01. A limit changed at 3 p.m. has to govern every agent at 3:01, not after a memo is read on Monday. Only one live, central set of rules, holding the current state of every commitment, can keep up with a business that never closes.
The real power of agents is chaining: one agent's output becoming the next one's input, so that a whole process, from quote to cash or from purchase request to payment, runs end to end. In the old design, people were the links, and every handoff was a check. Chain agents without that, and each carries its own copy of the rules. The sales agent quotes a discount the credit agent would never allow; the payment agent releases cash the treasury agent already committed. And every decision changes the ground for the next: an approval uses up budget, a signed contract creates obligations. Only a shared ruleset can tell the fifth agent in a chain what the first four have already done to its options.
Checking alone isn't enough. Two agents can each check the same budget, each find enough left, and both spend it. Both checks passed, and the firm is still overspent. So the core has to coordinate the actions themselves: reserve what a decision will consume, commit it in one step, and check again if the facts change before it executes. The rules say what is valid. The runtime keeps it valid while everything moves.
The most valuable chains also cross systems. The ERP, the HR system, the quality system and the CRM are each adding agents that govern only their own box. A product release that reads a batch record in one system, checks a quality decision in another and triggers shipment in a third belongs to none of them. Orchestration platforms can route that work, but they enforce against a definition of what is valid that they don't hold. Coordination without a shared rulebook is traffic control without a map of the roads.
A shared ruleset also shows where a chain can run on its own. Most steps only add facts or apply rules that already exist, so they can run in parallel with no one watching, because they never contradict one another. A few moves, such as relaxing a rule, granting an exception or overriding a limit, take something away from what was settled, and they genuinely need someone with authority. This can be shown formally, not just asserted. The chain runs unattended wherever it safely can, and stops for a person only where it must. A central ruleset is what makes one agent's output a trusted input to the next.
Why the rules must be complete
With no one reviewing the work, the rules are the only control left. A rule left in a binder or in someone's head is a rule broken a thousand times an hour. Complete means every layer that binds a decision: the contracts the firm has signed, its own policies and authorities, the standards of its industry, and the laws and regulations it must obey.
Complete has a practical meaning. For each decision the firm hands to agents, the core either holds every rule that applies, the facts it needs and the authority to act, or it knows that it doesn't, and stops. That is also the honest limit of "impossible": within what has been modeled, an invalid action can't be committed; outside it, nothing proceeds on a guess.
Contracts show the problem most clearly. Today a signed contract sits in a document system until something goes wrong, and then a lawyer interprets a clause written five years ago by people who have since moved on. That cannot work when agents are pricing, shipping and paying against the contract a thousand times a day. Every commitment has to be turned into rules and checked before every action, from the day it is signed.
Policies have the same problem on a yearly clock. A regulation changes in March, and the policy catches up at the next annual review while people quietly adjust in practice. Agents won't adjust. When the law layer is coded and versioned, a regulatory change immediately shows which rules it affects, and the gap closes the day the law takes effect.
That bottom layer is also shared. A sanctions, tax or privacy rule is the same for every firm it applies to. Coded once, versioned by jurisdiction and effective date, and referenced by every firm, it makes completeness achievable rather than a burden each firm carries alone. Not every legal provision reduces to a rule. Where one needs interpretation, the core marks it and sends it to a person instead of guessing.
That one change leads to six others.
Take the rules out of the programs
Put the company's rules in one place, the Enterprise World Model, owned by the company. Every app, screen, agent and decision model reads from it. When a rule changes, it changes once, everywhere, instead of in the thirty places it was coded.
Make wrong actions impossible, not just forbidden
Today's software checks an action after someone proposes it. The new software works out in advance which actions are allowed at all. An agent can't overpay an invoice, because overpaying is never one of its options: a vending machine that won't accept a bad coin, rather than a sign asking you not to use one.
Let AI judge and the rules decide
AI can be probabilistic because the check is not. Each decision goes one of three ways:
- The rules settle it: decided automatically, the same way every time.
- Judgment is needed: a decision model or an agent chooses among the allowed options, and the choice is checked.
- It's unclear, or someone wants an exception: it goes to a person with the authority to decide, and the exception is recorded with who granted it and why.
Write the rules so their owners can read them
The CFO, the compliance officer and the claims manager should be able to read the rules in plain English and sign them. Every decision should show which rule and which version applied, so an auditor can see why without reading code.
Pansophia calls each of these a Sophia: one decision, compiled from your policy documents, readable in English and callable by any agent or decision model. Where a decision model answers what is likely, a Sophia answers what is permitted, and why.
Build one picture of the company, one decision at a time
Don't map the whole company first; that is where past enterprise modeling projects stalled. Start with one decision, such as approving payments, and get value from it. Then add the next. Decisions share customers, contracts and accounts, so they connect, and conflicts between rules surface before an agent trips over them. The company ends up with one working model of how it operates, built as a by-product of decisions it needed anyway.
Test it quietly, then keep score
Run the new system alongside today's process and compare its answers with what people actually did. Each difference is a rule nobody wrote down, or a written rule nobody follows. Past decisions aren't automatically right, so the decision's owner settles each difference rather than the system copying what people did. Switch each decision on once it has proven itself.
Testing doesn't stop at launch. A decision model forgets each answer; a central ruleset remembers. Every decision is recorded with the rule that governed it, the engine that judged it and its confidence, and the outcome is attached when it arrives. That record makes three things possible:
- Replay a rule change before signing it. Rerun last quarter under a higher approval limit and see what would have changed, what later went wrong, and what it would have cost or saved.
- Grade every decision engine on your own results, including what no benchmark can: whether it tried to act outside the rules, escalated when it should have, and held firm when a case claimed "the owner already approved this."
- Use forecasts as inputs, not decisions. The record keeps which forecast was used and what happened, so forecasts get graded too.
The record also shows where the rules need to change. But no agent can change the rules it runs under. Changes are proposed, replayed, approved by their owner, and only then put into force.
What happens to code
Most business software code is the company's rules written in a programming language. Once the rules live in one place, most of that code is no longer needed. Code is still generated on demand, such as a screen for one job, a connection to a bank or a quick analysis, then used, thrown away, and checked against the rules before it runs. Maintenance has always been most of what software costs, so that cost falls sharply.
Start with one decision
None of this requires rebuilding the firm at once. Pick one decision that matters, such as releasing payments, put its rules at the core, and let agents run it at full speed. Then add the next. Each decision makes the next one easier, because the contracts, policies and laws it rests on are already there.
From one firm to many
The same logic eventually chains agents between firms. Today, when a buyer's agent negotiates with a supplier's, each side brings its own private rules, and people must confirm that the terms match. That is the seam problem again, at the boundary of the company. Once firms hold their rules in machine-readable form, two agents can check a transaction against both sets of commitments before it happens, without either firm exposing the rest of its model. Model the firm once, transact anywhere.
The precedent is the internet. Networking protocols didn't make any one computer faster; they made communication between computers possible at scale. A shared way to express and check business commitments could do the same for agent action across the economy. That is decades of work, but it starts with the step every firm can take now: write its own rules down, in one place, at the core.
The bottom line
For forty years, people carried the rules software left out, and caught mistakes at every handoff and in every pause. Agents remove both. The rules have to move into the core of the software: in one place, complete down to the law, and checked before every action.
The question every board will ask is simple: who allowed the AI to do this, and under which rule? Software built on the firm's rules can answer it. Software built for human users can't.
It used to be a tool for people who knew the rules.
Now it has to know the rules itself.