Your AI Coworker Should Explain the Numbers, Not Invent Them

The AI Coworker Should Not Be Your Calculator

On October 13, Oracle described a new division of labor in its Fusion Claw announcement: AI reasons about a goal and adjusts the plan; deterministic computation handles calculations, reconciliations, and simulations across many records. Oracle says its Release 26D introduces 25 Claw-powered applications across areas including finance and supply chain. The announcement is about an enterprise product, not evidence that every business can deploy these workflows today. But the design choice applies just as much to a company with a spreadsheet, an accounting system, and one operations lead.

An AI coworker can read a supplier's explanation, spot the exception in a stock report, and ask whether the owner wants to accelerate a purchase. It should not quietly become the authoritative calculator for available units, tax, margin, or payroll. Those numbers belong to reproducible rules tied to current records. The distinction is not that AI is incapable of arithmetic. It is that the business needs the same inputs and rules to produce the same answer tomorrow, with a trail showing why an action was taken.

That is the practical lesson in Oracle's split between reasoning and computation. You do not need Oracle to adopt it. You need to assign each part of a decision to the component that can be checked, corrected, and held accountable. Otherwise a convincing explanation can hide an incorrect subtotal, a stale inventory count, or a rule that changed halfway through the conversation.

For small businesses, this is an operating-model question before it is a software purchase. The first test is simple: when an AI coworker recommends a consequential action, can someone independently reproduce the underlying number? If not, the coworker is being asked to supply both the judgment and its own evidence.

Give Judgment to the Coworker and Arithmetic to the System of Record

The boundary is not between clever work and boring work. It is between work that benefits from interpreting context and work whose correctness is defined by an explicit rule. An AI coworker can compare a supplier's email with the purchasing policy, identify an unusual delivery pattern, and prepare options in ordinary language. A database query or tested function should calculate open purchase quantities, reorder points, contract prices, and total committed spend.

Take a neighborhood food distributor with stock spread across a warehouse, an online storefront, and orders not yet fulfilled. A customer asks whether 120 cases can arrive by Friday. The AI coworker can interpret the urgency, gather relevant purchase orders, and identify the need to contact a second supplier. The available-to-promise quantity, however, should come from defined inventory fields: on-hand minus allocated plus eligible incoming stock, subject to a cutoff and a known definition of "eligible." If the coworker improvises that formula in prose, the answer may sound plausible while double-counting an inbound shipment that has already been allocated.

Oracle's explanation of its runtime makes the distinction explicit: reasoning is used to understand objectives and evaluate alternatives, while deterministic computation performs repetitive calculations at scale. Database Trends and Applications' report also describes the separation as a potential economic advantage, not a measured saving every customer will achieve. The immediate small-business benefit is more basic: fewer numbers that exist only because a model stated them.

What bad looks like: a polished answer with no replay path

An owner asks an AI coworker to review slow-moving products and suggest markdowns. The coworker exports a CSV, reads three vendor messages, calculates margins in its response, and recommends 15% off a product line. Its answer has a confident table and a clear explanation. But it has treated shipping as a fixed cost for some items and ignored returns on others. Nobody can tell which version of the catalog it used. A reviewer sees the final percentage, not the input rows or formula.

The problem is not merely the risk of a math error. Even if the number happens to be correct, the owner cannot tell whether the recommendation still holds after a supplier raises prices. The next run may use different assumptions. The coworker has become an unversioned calculator and an unrecorded policy author at once.

What good looks like: a recommendation with a reproducible base

The same coworker asks a governed query for current stock, committed orders, unit cost, returns, and approved pricing rules. A deterministic function calculates contribution margin under several proposed discounts and rejects options below a floor set by the owner. The coworker explains the tradeoffs: which items free shelf space fastest, which ones would lose money, and which supplier agreement needs checking. It links the recommendation to the input snapshot and calculation version. A human approves any price change before the storefront is updated.

That workflow still gives the coworker meaningful work. It investigates, frames choices, communicates, and follows up. The calculation engine does not decide whether to run a promotion; the coworker does not get to change the definition of margin mid-run. This is seam design in operational terms: each transition between interpretation, computation, approval, and execution has an identifiable owner.

Make the Computation Boundary Visible

Many teams think they already have a clean split because their AI coworker can call a spreadsheet or a database. A connector is not a boundary by itself. The business must decide which calculations are authoritative, when their inputs are fresh enough, and which component is allowed to write a result back to a system of record. A tool call to an old export is still a stale answer, only with a technical wrapper around it.

Start with a metric contract for each high-impact number. Define the name, source, formula, time window, unit, exclusions, freshness expectation, and owner. "Revenue" might mean invoices issued, cash collected, or net recognized sales. "Available inventory" might include incoming stock only after a confirmed delivery date. A coworker can explain those meanings to a user, but it should not invent a new definition in response to a question. The earlier guide to AI-connected financial data explores why access to a finance system still requires clear authority and review.

Next, create a stable computation interface. That may be a saved accounting report, a database view, a spreadsheet formula with protected cells, or a small service with tests. Do not assume a custom software project is necessary. For a shop with 200 SKUs, a carefully owned spreadsheet can be a better first control than an elaborate platform. The important properties are named inputs, a versioned calculation, and a result that a person can reproduce.

Give the AI coworker access to the result and enough provenance to explain it: report timestamp, input period, formula identifier, and any exclusions. Avoid handing it unrestricted access to edit the underlying formulas simply because it can read the worksheet. Reading a metric, proposing a change to its definition, and changing the production definition are three separate permissions. The same separation should apply if the coworker uses a finance API rather than a spreadsheet.

Finally, define what happens when the boundary fails. If the report is unavailable, the inputs disagree, or the formula returns no result, the coworker should say that the figure cannot be verified. It can collect evidence and prepare a question for the metric owner. It should not backfill a missing accounting total by guessing from a customer email. Oracle's announcement pairs its reasoning/computation split with an operating envelope, enforced permissions, and an outcome receipt. Those are product-specific terms, but the underlying operational requirement is portable: show what authority was used, which evidence was considered, and what actually changed.

This boundary matters especially when different tools disagree. A sales dashboard may show today's gross orders while an accounting report shows posted net revenue through yesterday. Neither number is inherently false. The coworker's job is to identify the mismatch and ask which definition the decision requires, not to average them into a confident-looking compromise. The system's job is to calculate each approved definition consistently.

A Seven-Step Plan for a Small Business

You can test this pattern on one recurring decision before changing your whole operation. Choose a task where the numbers matter, but where a person can still review the final action. Inventory replenishment, invoice exception review, staffing coverage, and campaign budget allocation are candidates. Avoid beginning with payroll disbursement or an irreversible external payment.

1. Name one decision and its owner. Write down the question in the owner's language: "Should we reorder these parts before next Thursday?" Identify who decides when the answer is ambiguous and who can authorize a purchase. Do not start with the vague instruction "manage inventory."

2. List the numbers the decision needs. For each number, record its system of record, update frequency, definition, and known gaps. Mark any figure that currently comes from a manually copied report. If two systems disagree, do not grant the coworker authority to choose the more convenient one.

3. Freeze and test the calculations. Put reorder thresholds, tax, unit economics, and spend limits into owned formulas or queries. Use a few known historical cases to compare results with human-approved outcomes. Document exceptions such as partial shipments and returns. A test that only covers the normal order is not enough.

4. Define the coworker's judgment scope. It may investigate late deliveries, summarize a supplier's explanation, compare the computed options, and draft a recommendation. It must disclose uncertainty about data quality and surface relevant policy constraints. It must not silently rewrite the calculation to reach a desired answer.

5. Separate recommendation, authorization, and execution. A recommendation is not a purchase order. Require a named reviewer for actions above the agreed threshold, and use a scoped credential for any permitted write. Capture the exact proposed item, quantity, supplier, and total at the approval point; a later change to the cart requires a new review. The guide to AI coworkers spending money explains why spend authority must be more specific than a generic "approved" flag.

6. Keep a compact decision record. Save the input snapshot or query reference, calculation version, coworker's reasoning, reviewer decision, and transaction ID if something was changed. Do not copy entire customer or employee records into the log. The record should let someone answer both "why did we do this?" and "what did we actually do?"

7. Run a disagreement drill. Change a test input or simulate a stale report. Confirm the coworker stops relying on the old result, names the conflicting source, and routes the case to the owner. Then test a normal case to ensure the controls have not made routine work impossible. Review the first several real outcomes weekly before widening authority.

The sequence is deliberately modest. It produces evidence that the role is safe and useful before automation gets more authority. It also keeps the math and the judgment portable: if the model provider changes, the metric contract and calculation remain the same, while the coworker's explanation can be evaluated against the same cases.

The Real Boundary Is Who Can Change the Rules

Separating computation from reasoning is necessary, but it is not sufficient if the coworker can change the function it later calls. A discount floor in a protected sheet is meaningful only if the same identity cannot unprotect the cell and approve the resulting price. A spending threshold in a prompt is not an enforced threshold. The business must place authority to revise a rule with an accountable person and put the rule where execution can check it.

This is why Oracle's October announcement is more interesting than another claim that AI can do a longer task. Its public description links the planning layer to deterministic execution and a distinct authority layer, while also describing receipts for the completed outcome. That does not mean its product solves every integration or governance problem for every customer. It does show the direction mature systems are taking: intelligence can propose a plan, but it should not grant itself new permissions or declare its own arithmetic correct.

A small business can implement the same principle with fewer moving parts. Let the coworker read governed results, investigate exceptions, and propose next steps. Let a named owner maintain definitions and thresholds. Let tested calculations supply the numbers. Let scoped systems carry out approved actions and write down what happened. That structure makes a coworker more useful, not less autonomous: it can concentrate on interpreting the messy parts of work without pretending that a fluent answer is a ledger.

The practical question for your next deployment is not "How much can the AI do?" It is "Which parts must be reproducible when someone questions the result?" Answer that first, and you can expand the coworker's role without turning every recommendation into an unverifiable bet.

FAQ

Q: Can an AI coworker ever calculate a number itself?

A: It can do rough, low-stakes estimates in conversation if they are labeled as estimates. For a price, payroll amount, tax figure, stock commitment, or other consequential number, use an owned calculation tied to current inputs and let the coworker explain the result.

Q: Do I need a separate computation service?

A: No. A protected spreadsheet, saved report, or tested database query can establish the boundary. Use the simplest component that gives you stable definitions, access control, and a way to replay the result.

Q: What if the accounting and sales systems show different totals?

A: Preserve both with their definitions and timestamps. Identify which one governs the decision, or pause for the metric owner. The coworker should explain the discrepancy, not blend incompatible figures into a new number.

Q: Is a human approval enough to catch bad calculations?

A: Not by itself. Reviewers often see a polished recommendation without the underlying formula or source data. Give them a reproducible result and the specific action they are authorizing; reserve approval for judgment, not manual reconstruction of hidden math.

Q: Does this make AI coworkers less valuable than automation software?

A: No. The coworker handles context, exceptions, communication, and continuity across a task. Deterministic software handles repeatable rules. A useful AI coworker knows when to use each, and when to ask a person to decide.

If you're ready to give AI coworkers real responsibilities without making their answers the only source of truth, explore Associates AI Teammates and choose a plan. Build the roles, Skills, and approval boundaries your team needs on a persistent, model-agnostic platform.