A deterministic home for probabilistic actors

Your firm, compiled.

Start with one decision. Build the firm from there.

AI will only transform the enterprise when it can safely take on the network of decisions that runs it every day. The AI labs are now realizing it. Decision engines are arriving from every direction, but management remains accountable for every decision they make on the firm's behalf. Pansophia turns your policies, contracts and regulations into Sophias: the rules every decision agent must work within. Each Sophia is useful on its own, and each one becomes part of one model of your firm.

Start with one decision Read the white papers
Invoice Payment Sophia · v3✓ Signed by Controller

Can invoice #4471 be paid?

Kestrel Industrial Supply · $38,200.00

BlockedBank details changed 3 days ago and haven't been confirmed by phone.
  • Three-way match
  • Vendor active
  • W-9 on file
  • Bank change confirmed
RuleAP Policy v4 §6.2 Bank changes within 10 days need callback verification.
NextRecord the callback. Then it goes to the Controller to approve.
ExampleSame facts, same rules, same answer
The inversion

When agents run the firm, speed is the weapon. There is no time left for review.

Agents decide in milliseconds, around the clock, and hand their work straight to the next agent. The firm that moves fastest quotes first, ships first, and pays and gets paid first. For forty years the control was a person reviewing the work: the approval queue, the second signature, the month-end check. At machine speed that review is the bottleneck. Keep it and you lose the race. Drop it with nothing in its place and you lose control. So the order flips: the firm's rules move out of individual applications and into one core that every agent decides through, in one place and as complete as possible, checking every action before it happens. You can build on top of the systems you already run, or build new applications from scratch on the rules. Either way, every agent decides through them.

Why review can't keep up

Speed is the weapon. Review is the brake.

People reviewwaiting for review: hours to daysAgents + rulesevery decision checked in milliseconds, 24x7decide · actreviewrules check

Every step that waits for a person becomes the slowest link in a chain that otherwise runs in milliseconds. Competitors who remove it will win the customer, the price and the inventory. So management's job changes: take what the reviewers check and codify it into rules the software applies in milliseconds. Every review you codify is speed you gain. The rules have to live in one place to keep up: a payment released at 2 a.m. changes the cash available at 2:01, and one agent's output has to be a trusted input to the next, with no one checking in between.

What replaces review

Every rule that binds the decision, checked every time, down to the law.

Contractsset with customers, suppliers, lenders
Firm policiesset by your managers
Industry standardsset by standard-setters
Laws and regulationscoded once, shared by every firm

With no person in the loop, the rules are the only control left, so they have to be complete. A rule left in a binder or in someone's head is a rule an agent will break, a thousand times an hour. A Sophia stacks every layer that applies and cites the source of each rule. Laws and regulations sit at the base, coded once and versioned by jurisdiction and effective date. People still decide the exceptions; the rules route them there.

Build on top of what you have

Sophias sit above the systems you already run. Your ERP and other applications keep the records and keep executing; agents check every action against the Sophias before it happens. Nothing is ripped out.

Build from scratch

New agents and applications are built on the Sophias from day one. They inherit the rules instead of re-implementing them, so a rule changed once changes everywhere.

The firms that win will be the ones that can let their agents run. Complete rules, in one place, are what let you go fast.

Read: Software for the Speed of Agents →
The building block

What is a Sophia?

A Sophia holds every rule that binds a decision: your policies and contracts, plus the rules, regulations and laws of each jurisdiction where you operate. It is compiled from those sources with every rule cited, signed by the person who owns the decision, and callable by any agent or application. Inside, the engine can be rules, a language model, a forecast or an optimizer. Outside, every Sophia speaks the same language, and every answer comes back as decided, needs data, or escalate, with the rule behind it.

AP Policy v4 §4.1 · §6.2 DoA Matrix rows 1–4 Vendor MSAs §9 payment terms OFAC sanctions 31 CFR Part 501 Invoice Payment Sophia v3 · signed: Controller LINEAGE §6.2 → rule R-07 → v3, signed 12 Sep replaces v2 (7-day window) · changed by AP Policy v4 RULESQUESTIONSESCALATIONRECORDANSWERS 12 constraints, from policy, contracts and law can_pay(invoice) · who_approves(amount) waiver → Controller, logged with the payment every decision, its outcome, every version decided needs data escalate asks · answer + ruleasks · answer + rulereads,clarifies AI agentApplicationDecision owner via MCPvia APIin plain English
Policies, authority matrices, contracts and regulations compile into one Sophia, with citations. Every rule keeps its lineage, from the clause it came from to the version someone signed. Agents and apps ask the same rules and get one of three answers; the decision owner reads them and clarifies anything unclear.
When the rules are unclear or missing, the Sophia asks

A conversation with the decision owner, not a guess.

Policies are full of words like "timely", "material" and "reasonable". A Sophia doesn't let a model guess at them. It asks the decision owner in plain English, shows what each answer would have meant for past decisions, and compiles the reply into the rule's lineage, so nobody has to ask again. It also flags what the documents leave out, such as a legal requirement your policy never mentions.

Invoice Payment Sophia · clarificationto: Controller
SOPHIAThe Supplier Code says strategic suppliers get "timely payment," but never defines it. Supplier Code §2
SOPHIALast quarter, 38 invoices to strategic suppliers were paid after 30 days but within their contract terms. Should those count as timely?
CONTROLLERYes. Timely means within the contract's payment terms. If a contract has no terms, use 30 days.
SOPHIAUnderstood. Rule R‑12: pay strategic suppliers within contract terms, or 30 days if none are set. Nothing past changes status. Add it to v3 for your signature?
CONTROLLERYes, add it.
SOPHIAOne gap in the other direction. The AP Policy never mentions sanctions screening, but federal sanctions rules apply to every payment you make. 31 CFR Part 501
SOPHIAThe shared regulation layer already has it coded. Rule R‑13: no payment is released to a party on the sanctions list, and a possible match goes to Compliance. Add it to v3 as well?
CONTROLLERYes. That should have been in the policy all along.
✓ compiled · R-12 · Supplier Code §2 → Controller ruling, 30 Sep · R-13 · 31 CFR Part 501, shared regulation · both in v3, pending signature

Single or compound

Some decisions are one question. Others are a plan that many parts of the firm feed into. A compound Sophia brings those parts together: rules set the limits, forecasts and models supply the judgment, and an optimizer finds the best plan inside what the rules allow. You get one answer, with the reason from every part.

SINGLE Invoice Payment Can this invoice be paid? one answer …and it also feeds the payment run → COMPOUND Weekly Payment Run one Sophia · five components feed one optimization Invoice PaymentSophiawhat may be paidRULEeligible setCash Forecastcash, next 10 daysFORECASTinputSupplier Riskwho is criticalMODELinputTreasury Policykeep $5M minimumRULEconstraintApproval &Authorityover $2M: CFORULEconstraint OPTIMIZER · payment run Maximize early-payment discounts, protect critical suppliers Subject to eligible set · cash buffer · authority limits Plan: pay 412 invoices, $3.8M · captures $61k in discounts critical suppliers paid on time · $5.4M left above the buffer escalate over $2M, so the plan waits for the CFO · every input and limit is cited
Five components, built by different teams, feed one optimization. Rules set the limits, a forecast and a model supply the inputs, and the optimizer finds the best plan the rules allow. Change any one of them, and the plan changes with it. Illustrative.
The path

Every Sophia is useful on its own. Every one also becomes part of the model of your firm.

You don't have to buy the whole vision on day one. Govern one decision and get value from it this quarter. Each decision you add reuses what came before, until the firm's rules exist as one model that people and AI both work from.

1 · PRODUCT A Sophia one decision, governed 2 · VALUE Immediate value control and a record for that decision 3 · EXPANSION Compound Sophias whole processes, step by step 4 · NETWORK EFFECT Shared definitions reused across every team 5 · PLATFORM Pansophia compiler one model of the firm 6 · END STATE The Compiled Firm the firm runs on explicit rules COMMON LAYER · SHARED BY EVERY FIRM Laws, regulations and rules, by jurisdiction US federal · each state · EU · UK · and more coded once, versioned by effective date, under every Sophia START HERE
Each step pays for itself, and each one makes the next cheaper. The first Sophia is a product; the sum of them is the platform. Under every step sits one common layer: the laws and regulations of each jurisdiction, coded once and shared, so no firm builds that part alone.
AI for serious business

Management delegates decisions every day. AI should work the same way.

When a CFO gives someone authority to approve payments, it comes with limits, a clear owner, a reason for each decision and a path to escalate. Leaders stay accountable when AI decides on the firm's behalf, so they need the same controls. Sophias provide them. Security tools decide what an agent can touch. A Sophia decides what it may decide, and keeps the record to prove it.

Who allowed the AI to do this, and under which rule?THE QUESTION EVERY BOARD WILL ASK

The agent's workbench

Every agent gets a workbench, and a job description.

An AI agent works at a workbench: the context it can see, the tools it can reach and the compute that runs its judgment. Sophias govern that workbench the way an employment contract governs a person's working time: what it may decide, what it may change, and when it must escalate. The agent stays accountable. The workbench is what the rules constrain.

INPUTS OUTPUTS SOPHIAS · THE WORKBENCH'S JOB DESCRIPTION what it may decide · what it may change · when to escalate governs Task or requestfrom a person or an agentFacts and statefrom ERP, CRM, dataDocumentscontracts, invoices, emailJudgmentsdecision models, forecastsAction committedto the system of recordHandoffto the next agent, trustedEscalationto the person with authorityRecordattributed, rule cited WORKBENCH · AP AGENT the agent stays accountable ContextToolsCompute facts, each citedonly those allowedruns the judgment DECISION · Can invoice #4471 be paid? ALLOWED NOW request callback hold escalate NOT ON THE MENU release payment bank details changed, unconfirmed result: needs data · AP Policy v4 §6.2 Actions are attributed to the agent. Every change lands on the record with the rule behind it. Agent = who is accountable · Workbench = what the rules constrain · Sophias = the rules
Illustrative. A person's working time is governed by an employment contract; an AI agent's workbench is governed by Sophias. The agent never has to remember the rules, because an action the rules don't allow is never on its menu.
Approved in plain English

Managers approve the rules, not the code.

The person who owns a decision reviews its Sophia the way they'd review a policy memo: every rule written in plain English, each one linked to the clause it came from. Where the source documents are vague or disagree, the Sophia asks them to decide rather than guessing.

When they approve, their name and the date go on that version. What they read is generated from the compiled rules themselves, so what they approve is exactly what the agents enforce. No translation layer, no engineer's interpretation in between.

Discount Authority Sophiav1 · awaiting CFO approval
✓

Sales reps can discount up to 10% without approval.Pricing Policy v2 §3.1

✓

Discounts from 10% to 20% need the regional sales director. Above 20%, the CFO.Delegation of Authority, rows 7–8

✓

No discount can take a deal's gross margin below 35%, whoever approves it.Pricing Policy v2 §4.2

NEEDS YOUR DECISION

The Pricing Policy says strategic accounts get "additional flexibility" on price, but never says how much. How should the Sophia read it?

Up to 5 extra pointsSame limits; CFO can grant exceptionsLeave undefined
3 rules · 1 decision made · sources: 2 documentsApprove & sign, v1

Built for your risk committee

Works alongside your ERP

Pansophia reads from the systems you already run, through exports and APIs. Nothing is ripped out and your ERP stays the system of record. Your ERP keeps the records; Sophias hold the rules that every agent and new application decides by.

Deterministic and reproducible

Outcomes decided by rule are deterministic. The same facts under the same signed rules always give the same answer, and any past decision can be reproduced exactly as it was made.

A permanent record

Every decision, rule version, sign-off, waiver and outcome is kept. You can show an auditor which rules were in force on any date, who approved them, and what they decided.

The Compiled Firm · built bottom-up, compiled top-down

Let every team build. Still end up with one model of the firm.

The energy for AI is in the teams. AP, procurement and sales ops will each build an agent this quarter. Lock that down and nothing ships; leave it alone and the firm ends up with fifty agents holding fifty versions of its rules. With Sophias, each team compiles its own decisions on its own timeline, and the Pansophia compiler makes sure every one uses the same definitions, the same approval limits and the same record.

The same happens across systems. Your ERP, HR and CRM vendors are each adding agents that govern only their own system, and the decisions that cross between systems belong to none of them. Sophias sit above every system, so those decisions have one owner and one set of rules.

Without a compiler AP agentProcurementSales agent own promptsagent · own rulesown guardrails VENDORVENDORVENDOR APPROVAL LIMITAPPROVAL LIMITAPPROVAL LIMIT TOLERANCETOLERANCEDISCOUNT CAP ERP vendor idDUNS numberaccount name $25,000$50,000none set 5%2%15% ≠≠ ≠≠ ≠ conflicts found in production, by accident
Three teams, three private copies of the firm. The AP agent and procurement agent disagree about what a vendor is and who can approve $40,000.
With the Pansophia compiler One world model on shared laws & regulations PANSOPHIA COMPILER one ontology · one authority model 1 conflict flagged Invoice PaymentSupplier EligibilityDiscount Authority built by APbuilt by Procurementbuilt by Sales Ops VendorAuthorityCustomer OrderContract
Three teams, one firm. Each Sophia plugs into the same Vendor, Authority and Contract. When two policies disagree, the compiler stops and names it.
What a compile-time conflict looks like
Compile report · AP + Procurement1 conflict · blocks publish
CONFLICT · THREE-WAY MATCH TOLERANCE

Two sources set different limits for the same check. Both can't be enforced.

AP Policy v4 §4.1 · written policyWithin 2% or $500, whichever is less.
ERP configuration · AP match ruleWithin 5%.

Replayed on last quarter: 214 invoices fell between 2% and 5%. Under the written policy they would have waited for review; under the ERP setting they were paid automatically, totaling $1.9M. Illustrative.

OWNER: CONTROLLER · CHOOSE ONE
Adopt the policy (2%)Adopt the ERP setting (5%)Amend the policy
Nothing publishes until this is resolved. The ruling is recorded with both sources.Send to Controller

See where your Sophias connect

Because every Sophia compiles into the same model, Pansophia can show where they meet: the vendors, contracts and customers that more than one decision depends on. Those links answer questions no single decision can, and they point to the next Sophia worth building.

Invoice Payment built by AP Supplier Eligibility built by Procurement Discount Authority built by Sales Ops Credit Exposure suggested next Vendor Contract Customer Order 1 2 3 solid: Sophias in use · dashed: a link Pansophia suggests
1

Shared vendor. Invoice Payment and Supplier Eligibility both know Kestrel Industrial Supply. Linked, you can ask: are we paying early to suppliers who deliver late?

2

Shared contract. Supplier terms and customer discounts meet in the same contracts. Linked, you can see whether discounts granted in sales are covered by the margins negotiated in procurement.

3

Suggested next. A Credit Exposure Sophia would reuse the Customer and Order already modeled by existing Sophias, so most of the work is done before you start.

Conflicts surface before they reach production. When two teams' policies disagree, the compiler names the contradiction, cites both sources and sends it to someone who can settle it.

Each Sophia is cheaper than the last. Vendors, contracts and approval chains are modeled once and reused, so the work shifts from building the model to adding decisions to it.

Each Sophia is cheaper than the last Invoice PaymentSupplier EligibilityDiscount AuthorityTreasury Release 6 new2 new1 new1 new already in the model built new entities per Sophia · illustrative
The first Sophia models the vendor, the contract and the authority chain. Every later one reuses them, so the work shifts from building the model to adding decisions to it.
Where decision engines are going

Decide, predict, optimize. Composed into one system.

Decision engines are arriving in layers, from many vendors, built on different methods: rules, decision models, statistical models, language models, mathematical optimization. Each is useful alone. The harder question is how they understand one another when one engine's output becomes another's input.

Decide

Choose an action

Given a situation, pick from a fixed set of options.

approve · reject · escalate · route
Predict

Forecast an outcome

Given a situation, estimate what happens next.

churn · demand · failure · conversion
Optimize

Find the best plan

Given resources, constraints and objectives, find the best feasible configuration.

inventory · truck routes · capacity
Sequence

Decide over time

Make a series of decisions where each one changes the state for the next.

replenishment · dynamic pricing
state→constraints→objectives→decision→resulting state

The common interface isn't the algorithm inside. It's this relationship. Every Sophia expresses its decision this way, against the same model of the firm, so any engine can plug in and every engine can see what the others changed.

One order, four engines
ORDER FULFILLMENT SOPHIA · ONE PROGRAM GOVERNS ALL FOUR sets the limits every engine works within: who may expedite, margin floor, Controller's approval limit, customer commitments limitslimitslimitslimits 1 · DECISION Expedite order #5530? 2 · OPTIMIZATION Best fulfillment plan 3 · DECISION Accept the margin tradeoff? 4 · OPTIMIZATION Reallocate remaining capacity reads commitments sets a service promise consumes 40 pallets of trailer capacity checks margin floor and Controller limit uses what is left for the next orders ONE SHARED MODEL OF THE FIRM Inventory Trailer capacity Customer commitments Margin Approval authority
One compound Sophia governs the whole chain: it sets the limits every engine works within, so no engine can promise, spend or approve past what the firm allows. A decision triggers an optimization, which changes the state of the business, which triggers the next decision. Because every step reads and writes the same model, nothing is out of sync. Illustrative.

What one consumes, the next can't use. Trailer capacity booked to expedite one order is gone when the reallocation runs.

What one promises, the others must honor. A delivery commitment made by one decision becomes a constraint on every plan after it.

What one decides, reshapes the next. An optimization's result feeds a decision, and a decision can change the feasible region of the next optimization.

How it works

Start with the decision. Every decision has two sides.

Many AI pilots stall before they touch the P&L because they automate activity rather than outcomes. The unit worth automating is a decision the business makes over and over: approve this payment, route this order, price this quote, pay this claim.

Why decisions are the right place to start

They're bounded. A fixed set of outcomes, so you can say exactly what the automation may do.

They're measurable. Each has a result you can check: the payment cleared, the claim held up.

They repeat. A decision made ten thousand times a month pays back quickly.

They're owned. Someone already answers for it, so someone can sign off on the rules.

Probabilistic and deterministic

One side of a decision is probabilistic: reading the situation. What did the customer change in this contract? Which supplier will deliver on time? Decision models are good at this.

The other side is deterministic: what the firm has committed to. Who can sign this deal? Does the contract allow this price? These are rules, and a model guessing at them is a liability.

Trading floors solved this decades ago with a deterministic shell of risk limits around probabilistic strategies. Sophias are that shell for the rest of the enterprise.

decision Sign the customer's redlined master agreement? (3 years, $1.2M)
sidequestionanswered byanswer
probabilisticDid the redline change the liability cap?decision modelyes, 0.94
probabilisticIs the new indemnity clause unusual for this kind of customer?decision modelunusual, 0.71
deterministicA liability cap above 2× annual fees needs Legal: does this one?Contracting Policy §5.1yes, cap is 3×
deterministicWho must sign a 3-year, $1.2M deal?DoA Matrix row 9CRO and CFO
ESCALATE to the General Counsel for the liability cap, then to the CRO and CFO to sign.
note The model spots what changed in the redline. The rule decides who has to approve it.
How decisions are found

Most firms can't state their own rules. Pansophia makes them explicit.

A company's real decision logic is scattered: half-written in policy PDFs, half-coded in ERP approval chains, and the rest carried by people who know that "we never pay a new vendor over $25k without calling them." Pansophia finds those decisions, names them, and shows you where each one came from.

01 · READ

What's written down

The extraction engine reads policies, delegation matrices, contracts, tariffs and regulations, and pulls out every obligation, threshold, authority and exception, each tied to the clause it came from.

AP Policy v4 · DoA Matrix · MSAs · SOX narratives
02 · TRACE

What's coded into apps

Approval chains, validation rules and routing logic exported from the systems you run. Decisions a vendor hard-coded years ago become visible, and often turn out to disagree with the written policy.

ERP workflows · approval routes · app config
03 · OBSERVE

What people actually do

Past decisions are replayed against the draft rules in shadow mode. Where people consistently decided differently, there's an unwritten rule, a stale policy, or a habit worth questioning.

approval history · overrides · exception emails
04 · SURFACE

What doesn't add up

Ambiguous terms, contradictions between documents, rules nobody can source, decisions with no owner. Each goes to the person who can settle it, and their answer is compiled in.

conflicts · gaps · orphan rules
decision inventory Accounts Payable · sources read 7 documents, 1 regulation, 2 systems, 14 months of approvals
decisionfound instatus
Who can approve a payment, by amountDoA Matrix rows 1–4 · ERP routecompiled
Three-way match toleranceAP Policy §4.1 says 2%; ERP config says 5%conflict
Callback on bank-detail changesAP Policy §6.2compiled
"Timely payment" to strategic suppliersSupplier Code §2, term undefinedambiguous
Sanctions screening before any payment31 CFR Part 501 · shared regulation, coded oncecompiled
New vendors over $25k need a callno document; 41 of 41 past approvals followed itunwritten
next 2 items routed to the Controller for a ruling. Illustrative example.
Decision routing

The decision decides what kind of engine should make it. Results decide which one.

Decision engines are coming from every direction: the labs themselves, the software you already license, and your own data science teams. Decision models, forecasters, optimizers and LLM agents, with more every quarter. A decision model needs a question and a fixed set of allowed answers. A Sophia supplies both, from your policies, contracts and regulations, then checks every answer against the rules.

Most firms pick an AI and point it at everything. A Sophia starts from the decision instead. Its profile says what kind of engine should make it. Then the engines of that kind compete on your own history and outcomes, and the best one takes the traffic. When a better engine ships, it earns its place by proving itself on your data.

Decision profileread from the Sophia's rules · the profile is rules, not another AI choosing
DecisionWhat its profile showsMade by
Waive the callback on a changed bank account?Needs an exception to a signed rulePersonnamed by the escalation path
Allocate trailer capacity across this week's ordersClear objective, structured data, thousands of possible plansOptimizer
Is this invoice a duplicate?A fixed set of answers, a judgment call, high volumeDecision model
What did the customer change in this redline?Unstructured documents, open-ended, needs to gather contextLLM agentin shadow until proven
Decisions graduate
LLM agent→Decision model→Rule

A new kind of decision starts with an agent, in shadow. As its record builds and the pattern holds, it moves to a faster, cheaper decision model, and the parts that never vary become rules the owner signs. Over time, more of the firm is compiled and less is left to judgment.

Decision request invoice #4471 Sophia rules deterministic12 constraintsevery clause cited commitments Decided by rule no model consulted judgment Router routing table live shadow Engine A LIVE Engine B shadow Engine E shadow Outcomes paid · disputed · late arrive later Record engine + answerconfidencerule appliedfull stateoutcome history Replay & simulate score every engine on your outcomes promote best engine per decision type
Rules go first: commitments are decided without a model. Judgment questions go to the kind of engine the decision's profile calls for, and among those, to whichever is currently winning, while challengers answer the same questions in shadow. Outcomes come back, history is replayed, and the routing table updates. When a better engine ships, it earns traffic on your data.
Simulate before you commit

See what a change would have done before it does anything.

Every decision a Sophia makes is recorded with the facts it saw, the rule it applied and what happened next. That record lets you test a change against your own history before it reaches a customer, a supplier or your books.

1

Before you sign a rule. Replay last quarter under the draft version. See which decisions would have changed, which ones later went wrong, and what it would have cost or saved.

2

Before an engine goes live. Run it against your past decisions and synthetic edge cases built from your own rules, then in shadow next to the current engine. It takes live traffic only once it wins.

3

Forecasts feed decisions. They don't make them. A demand or risk forecast becomes an input the Sophia weighs inside its rules. The record keeps which forecast was used, its version, and what actually happened, so forecasts get graded too.

What-if · Approval & Authoritydraft v5 vs signed v4
Proposed change

Payments the Controller can approve without the CFO: up to $50,000 $75,000.

Replayed on Jul–Sep · 9,412 payment decisions · same facts, new rule
Decisions that would change212
CFO review hours saved≈ 70
Of those 212, later disputed or reversed3 · $410k
Linked Sophias affectedTreasury · Budget
Forecast used

Q4 payment volume +18% (forecast v7). At that volume, the CFO queue clears in 1 day instead of 3.

Illustrative. Nothing changes until the CFO signs v5.Send to CFO
Report card

Supplier Eligibility Sophia · engine scorecard

simulation: 1,842 real orders (Jun–Aug) + 300 synthetic edge cases · graded at three levels: the decision, the function and the firm
What was gradedEngine ADecision modelEngine BDecision modelEngine CLLM agentEngine DOptimizerEngine EStatistical model, in-house
Level 3 · the decision
Picked the supplier that delivered on timeA 91%A 92%B 86%A 90%B 88%
Confidence matched realityABCn/aA
Stayed inside the rulesA 0 triesA 0 triesC 14 tries, blockedA 0 triesA 0 tries
Escalated when it should haveBBAC never escalatesC
Held firm on "the owner approved this"BBCA ignores textA
Speed and costA 410 msA 180 msC 6.2 sB 1.2 sA 15 ms
Level 2 · the function
Met procurement's cost and service targetsBBCAA cost only
Level 1 · the firm
Effect on other functions (expediting, margin)BBCA plans across functionsC $1.1M expediting
Net effect on the firm, replayed+$0.2M+$0.1M−$0.3M+$0.3M−$0.7M
ROUTED Engine A ranks suppliers for each order. Engine D sets the supplier mix across routes, because it scored best for the whole firm. Engine E hit procurement's cost target but cost the firm $0.7M, so it no longer makes this decision. Illustrative figures.
Why Pansophia

Anyone can rent the intelligence. No one can rent your rules.

Comenius called it pansophia: the whole of knowledge, made explicit and ordered. A dream at the scale of civilization; an engineering project at the scale of a firm.

For a century, firms were built around the limits of human attention: departments, hierarchies and policies, each a simplified version of the business. AI lifts that limit. When every competitor can rent the same intelligence, what sets a firm apart is what it has made explicit: its commitments, its authorities, its judgment.

Read The Compiled Firm →
White papers

The thinking behind Pansophia

New · October 2026

Software for the Speed of Agents

Agents will run the firm at machine speed. No one will have time to check their work. The rules will have to.

Business software was built for people, who carried the rules it left out and checked the work at every handoff. When agents take over, speed becomes the weapon and there is no time left for review. The paper argues that the firm's rules must move into one core that every agent decides through, in one place and complete down to the law, so agents can run at full speed.

Read the white paper
July 2026

The Compiled Firm

How bounded cognition shaped the modern firm, and what happens when the constraint lifts.

The essay traces how departments, hierarchies and enterprise software grew up to coordinate bounded human minds. It argues that the firm's own representation, authored by humans and executed by machines, becomes the primary object of management.

Read the white paper
Get started

Start with one decision.

Send us one policy: a delegation matrix, an AP policy, an exclusions schedule. We'll return a Sophia your managers can read and sign, with the regulations that apply where you operate already built in, and show you how it would have decided on your last quarter of approvals.

Launch Sophia

Approval & Authority

Your delegation matrix, compiled. Who can approve what, up to how much, and what happens above that line.

  • Spend and payment limits
  • Contract signature authority
  • Waivers recorded, never assumed
Sophia

Budget & Planning

Spend against budget, reallocation limits, and who can commit the firm to what.

  • Budget line checks
  • Transfer thresholds
  • Commitment authority
Sophia

Treasury

Payment release, counterparty limits, and the bank-detail changes that fraud depends on.

  • Release conditions
  • Callback verification
  • Counterparty exposure
Launching soon

Be first to know when Pansophia launches.

Leave your email and we'll send one note when we open.

We'll only use your email to tell you about the launch.