AI pricing agents: keep the margin calculation in code

A freight quote can contain correct arithmetic and still use the wrong commercial rule. Suppose an AI assistant reads a carrier cost of $1,150 and a request for a 20% margin. It returns $1,380. That price adds 20% to cost, but its margin is about 16.67%. The operator needs a way to see which calculation ran before sending the quote.

This is a fictional pricing example. The charges and policy below are illustrative, not a client result or a recommendation for a particular trade lane. I would let the assistant identify relevant facts and explain exceptions, while a reviewed calculation function applies the business's chosen rule. The function needs explicit inputs and a version the team can inspect.

Write the pricing rule before choosing the model

In this example, margin means profit divided by selling price. Markup means profit divided by cost. If cost is C, price is P and target margin is m, then (P - C) / P = m, so P = C / (1 - m). A request to add a markup r instead uses P = C × (1 + r). Those definitions belong in the application contract; a conversational phrase such as 'add twenty percent' is too ambiguous to release a quote.

Agree what belongs in cost. Our hypothetical rule includes linehaul, fuel and handling, excludes tax, and uses USD throughout. Another business may treat pass-through charges differently. Currency conversion, minimum fees and customer agreements need their own approved rules. A decimal library cannot choose those policies for the team.

Carry the source facts into the calculation

Consider quote Q-501, version 7. The carrier record states USD 1,000 linehaul, USD 120 fuel and USD 30 handling. The customer pricing policy specifies a 20% margin. I would pass those separate charges, their source references and the policy version to the calculation tool, rather than accepting a model's combined total without provenance.

quote_id: Q-501
source_version: 7
currency: USD
linehaul: '1000.00'
fuel: '120.00'
handling: '30.00'
pricing_rule: margin-v3
target_margin: '0.20'
source_validity: confirmed

Now change one input: the email says 'handling included', while the rate sheet lists $30 separately. The assistant should show that conflict and hold the calculation for resolution. Substituting zero would silently select a commercial interpretation. Preserve both references and assign the question to the person who owns the rate.

Use decimal arithmetic with a stated rounding policy

Python's Decimal type supports decimal representation and configurable rounding. Constructing a Decimal from a float preserves that float's approximation; constructing it from a decimal string avoids introducing that conversion. The decimal documentation also explains quantize for rounding to a fixed number of places. Python: Decimal representation and rounding

from decimal import Decimal, ROUND_HALF_UP

charges = [Decimal(s) for s in ('1000.00', '120.00', '30.00')]
margin = Decimal('0.20')
assert all(x.is_finite() and x >= 0 for x in charges)
assert margin.is_finite() and 0 <= margin < 1

cost = sum(charges, Decimal('0'))
price = (cost / (1 - margin)).quantize(
    Decimal('0.01'), rounding=ROUND_HALF_UP
)
print(cost, price)  # 1150.00 1437.50

That snippet demonstrates the arithmetic only. A production tool must enforce its input schema, currency rules, amount limits and source validity, and handle invalid input without relying on Python assertions. It also needs the business's choice of rounding stage. Rounding each line before summing can differ from rounding a final total. Keep that choice in a tested policy version and show the operator how it affects the displayed amount.

Where programmatic tool calling helps

Claude's programmatic tool calling lets generated code invoke tools inside a code execution container. Intermediate results can be processed before the final output reaches the model context. It can suit a workflow that reads many candidate rates and returns a compact comparison. Small, strictly sequential jobs can gain little from the extra container and script work. Claude: programmatic tool calling and workload fit

For Q-501, I would expose a bounded read endpoint and a calculate_quote function implementing the reviewed margin rule. Generated code could organize the candidate reads, but it would call that function for the commercial calculation. An ad hoc script that writes its own formula has not gained policy correctness merely because it runs successfully.

The current Claude documentation warns that allowed_callers is guidance, not a hard security boundary. It also lists strict tools and MCP-connector tools as incompatible with programmatic calling. Check those constraints against the intended integration and validate tool inputs in the application. Claude: caller guidance and current limitations

Return an auditable result: input charge IDs, currency, cost, calculated price, formula version and unresolved fields. Keep the endpoint read-only during the pilot. The ability to calculate a quote should not also allow changing a customer agreement or sending an offer. Measure the complete workflow before enabling programmatic calling broadly; this article does not report a model benchmark or a token-saving result.

Test mistakes that change a quote

Track wrong prices separately from cases correctly held for clarification. Record operator correction time and unresolved cases alongside model and tool costs. A system that returns fewer prices can be useful if it makes genuine ambiguity visible, but unnecessary holds can overwhelm a desk. Agree both the permitted error types and the review capacity before comparing providers.

After the calculation passes, release the quote through a separate operation that checks the current rate version and the exact approved contents. If sending times out, recover the downstream status before sending again. Our retry article carries that part of the workflow through an uncertain outcome. Read: recovering an uncertain agent action