What does it cost to delegate a business task?

Cheap model tokens do not automatically make a cheap operation. A task may require enrichment, retries, human review, reconciliation and support for the automation itself. For a solo founder, the useful unit is the completed business task and the supervision it required.

The platform has a model price book, run records and an agent cost/value ledger. It distinguishes cost from attributed value and avoids giving an unruled workflow an invented value claim. This is a strong foundation for experimentation, provided the inputs and metric definitions are made precise.

Count a business task once

One enquiry might produce five model attempts and three agent episodes. That is still one enquiry. If all eight runs claim the time saved from handling the enquiry, the economics are inflated.

The ledger uses demand references and a claim registry to deduplicate verified business units. The production design should persist those claims transactionally and define what “verified” means for each workflow. A completed lead brief and a won customer are different outcomes with different evidence.

A cost record should include:

Model calls + retrieval + enrichment + connector fees
+ allocated infrastructure + human review + recovery work
+ platform charges, where applicable

The current ledger includes inference costs, currency conversion and visible platform-fee lines. Human review and broader operating allocation need to be supplied or extended explicitly. A property named “fully loaded” does not make missing costs appear.

Work through an illustrative calculation

Assume 100 tasks in a trial. Model, retrieval and infrastructure allocation totals S$18. Twenty reviews take three minutes each, and five recoveries take twelve minutes each. Valuing founder time at an illustrative S$60 per hour adds S$120. Ninety tasks reach the defined accepted outcome.

machine_cost = 18
review_cost = 20 * 3 / 60 * 60
recovery_cost = 5 * 12 / 60 * 60
accepted_tasks = 90
cost_per_accepted_task = (
    machine_cost + review_cost + recovery_cost
) / accepted_tasks
# S$1.533... per accepted task

These are planning assumptions, not measured platform results. If the manual baseline is eight minutes per task, 100 tasks require 800 minutes. The illustrative trial still requires 120 minutes of review and recovery. The difference is released capacity, not automatically a cash saving or a reduction in payroll.

The experiment should measure the real baseline and review burden before making a business-impact claim.

Keep acquisition economics dimensionally correct

The marketing prototype includes a metric called margin-adjusted CAC. For conventional payback reporting, I would keep ordinary acquisition cost and gross-margin contribution separate:

CAC = acquisition spend / new customers
Monthly gross profit per customer = monthly revenue × gross margin
Payback months = CAC / monthly gross profit per customer

For an illustrative US$2,000 acquisition cost, US$2,000 monthly revenue and 70% gross margin, payback is about 1.43 months. If CAC is first divided by gross margin and then divided again by gross-margin-adjusted monthly revenue, the margin is applied twice. The current prototype's similarly named properties need this semantic reconciliation before their outputs are used as conventional payback figures.

A ranking score can intentionally penalise low margins. It should simply have a distinct name and not be presented as the standard payback calculation. Contract value also needs a period definition before it is multiplied by retention months.

Price references need an effective date

The gateway price book and exchange-rate snapshot make reruns inspectable. A run should retain the price-book version and model route used to calculate its cost. Some current entries are placeholders; they are not present-day provider quotes.

Counterfactual routing savings can compare the same token volume under another model price, but that comparison does not prove equal quality. A cheaper route is useful only if it meets the task's acceptance condition. I would pair cost comparisons with the same scenario set and include escalations and retries.

The founder's operating scorecard

For each loop I want accepted tasks, cost per accepted task, review minutes, unresolved failures, external-effect errors and the evidence supporting any attributed value. A separate column can show modelled potential. Keeping measured and modelled quantities apart makes the trial easier to improve.

The decision after a week might be simple: automate the first draft, keep commercial messages reviewed, and stop an enrichment step whose cost exceeds its observed usefulness. That is a more valuable result than a large headline about “hours saved” derived from the number of agent calls.

Price the exception path before optimising tokens

Take a reminder about an unpaid invoice. The normal path reads the balance, drafts a message and waits for review. The exception path finds a recent payment whose allocation is still unresolved, asks the founder to investigate and postpones contact. That investigation is part of the cost of the workflow. Moving it to a separate queue does not make it disappear.

The public lab puts machine cost, review time and recovery time into the same denominator:

from decimal import Decimal
from company_lab.business import task_cost

cost = task_cost(
    machine_minor=1800,
    review_minutes=60,
    recovery_minutes=60,
    hourly_minor=6000,
    accepted=90,
)
assert cost == Decimal(13800) / Decimal(90)
assert task_cost(1800, 60, 60, 6000, 0) is None

The result is in minor currency units per accepted task. A zero denominator is undefined, not zero cost. These inputs reproduce the illustrative S$1.53 example above. They are deliberately visible so a reader can substitute measured values.

Reserve a budget before concurrent work starts

Imagine three research agents each reading “S$5 remaining” and starting a S$3 enrichment job. A post-hoc ledger will accurately explain why S$9 was spent; it will not prevent the overspend. The dispatcher needs an atomic reservation before granting work.

UPDATE run_budget
SET reserved_minor = reserved_minor + :reservation
WHERE run_id = :run_id
  AND spent_minor + reserved_minor + :reservation <= ceiling_minor
RETURNING run_id;

No returned row means the action cannot start under that budget. The caller must validate a positive reservation and trusted run ownership before executing this statement. Reconcile the reservation against the actual receipt; release only the unused portion. A worker timeout is not evidence that a paid provider call never happened.

For token-billed calls, reserve against the permitted input and output envelope using a dated price book. For fixed-price enrichment, reserve the quoted unit cost. Keep currencies separate until a recorded exchange-rate conversion is applied. A reservation can be conservative without pretending to be the final charge.

Measure the manual alternative on comparable work

A fair baseline uses the same task boundaries. If manual work includes checking the customer record and correcting an invoice, automated work must include those steps too. Do not compare a human's complete resolution time with the model's time to produce a first draft.

For a small pilot, sample task type, complexity, active handling minutes, elapsed waiting time, outcome and correction minutes. Report medians and tails separately. A faster average can coexist with rare two-hour recoveries. Founder time is particularly constrained because the same person sells, delivers and supervises the platform.

A task may release time without producing more revenue. To claim an economic benefit, record what happened to that capacity: more accepted deliveries, fewer overtime hours, faster collection, or simply a less fragmented working day. Those are different outcomes and deserve different labels.

Decide which work deserves another iteration

My review table would contain baseline handling time, assisted handling time, acceptance rate, critical errors, total cost and evidence freshness. I would stop a workflow whose review burden exceeds the manual alternative even if its token bill is tiny. I would also retain an expensive task if it reliably prevents a material error, with that rationale stated explicitly.

The exercise is a cheaper model route with twice as many corrections. Run both routes on the same held-out scenarios and compare complete task cost. Include unsuccessful attempts in the numerator. The question is whether the business gets a dependable outcome at an acceptable total cost, not whether one API call became cheaper.