LLM automation: the economics of dependable execution

In one of my tests with a personal autonomous agent, a small online purchase generated about $13 in inference fees. The agent completed the transaction, but repeated attempts to navigate the store made the execution disproportionately expensive.

That result describes one test, using a particular setup. It is not a benchmark for the cost of autonomous agents. Its significance is the distinction it exposed: completing a task and operating that task economically are separate achievements.

For enterprise automation, the investment case depends on the second. A useful assessment must examine the work required to verify outcomes, handle exceptions, and keep the cost of repeated execution within acceptable limits.

Make the hidden supervision visible

In a chat interaction, a person supplies much of the control. They inspect the answer, correct misunderstandings, clarify the objective, and decide whether the task is complete.

When the same model operates autonomously, those responsibilities have to be assigned elsewhere. The system needs a definition of success, a reliable view of the current state, limits on permitted actions, and a way to stop or escalate when progress becomes uncertain.

A longer prompt can clarify intent. It cannot by itself establish that an invoice was created, a calendar change respected every constraint, or a retry avoided making a second purchase.

Completion should be verified against the system of record. A model’s account of what happened is useful context, but consequential actions need observable evidence of their result.

Assign reasoning to the part of the process that needs it

The architecture should reflect the nature of the task. Some workflows have known steps and occasional ambiguity. Others require a model to choose the next action as new information arrives.

Anthropic makes a similar distinction between predefined workflows and agents that direct their own tool use in its guidance on building effective agents. The choice carries implications for predictability, latency, and cost.

Three flows from my own work illustrate how this distinction affects design.

• Email triage: fetching messages, removing duplicates, applying explicit rules, and recording outcomes can be handled in code. The model can focus on ambiguous messages, using a bounded context and a defined classification format.
• Capacity planning: the system can assemble calendar availability, deadlines, and workload before asking the model to propose a plan. Validation then checks that the proposal respects the constraints before changes are applied.
• Browser operations: stable, permitted paths can be automated and checked at each step. When the interface changes, model reasoning can assist diagnosis and recovery, with limits on retries and on actions that create external commitments.

The appropriate balance will vary by workflow. What matters is that the organization can explain which decisions are delegated to the model and how their consequences are controlled.

Measure cost per verified outcome

Inference price is one component of the operating cost. Repeated attempts, tool usage, infrastructure, human review, incident handling, and ongoing maintenance all affect the economics.

A practical measure is the total operating cost over a period divided by the number of correctly completed tasks. Include failed attempts in the cost and exclude unverified completions from the outcome count. Assess initial engineering expenditure separately over the expected useful life of the automation.

The distribution also matters. An acceptable average can conceal a small number of tasks that consume excessive time or cost. Track completion time, retry frequency, intervention rates, and expensive exceptions alongside the average.

In the shopping test, repeated exploration and accumulated context contributed to the bill. Narrower tool access, bounded context, and reusable paths are options to evaluate. Their value should be measured in the actual workflow, including the maintenance they introduce.

Compare the result with the current process at equivalent quality. Time released becomes business value when it reduces expenditure, creates usable capacity, or improves an outcome the organization values.

Treat recovery as part of the process

A production design needs to specify what happens after an ambiguous result. If a request times out after a transaction may have succeeded, repeating the action can create a duplicate. The system should first establish what was committed and whether retrying is safe.

Controls should match the consequences of the action. Drafting a classification and releasing a payment carry different obligations. Tool permissions, approval points, execution limits, and audit records should reflect that difference.

External content also requires a clear boundary. An instruction embedded in a message or web page must not acquire the authority of the user’s operating policy simply because the agent reads it.

These requirements have operational owners. Someone must maintain integrations, review exceptions, respond to incidents, and decide when a workflow should be suspended. That work belongs in the implementation plan and cost model.

Expand autonomy on evidence

A sensible pilot begins with a bounded task and an outcome that can be checked. Establish the current process baseline, define acceptable errors and intervention levels, and evaluate normal cases alongside meaningful exceptions.

Begin with proposals or supervised execution where the consequences warrant it. Broaden authority when the evidence supports doing so, and keep a clear route for human intervention when the system reaches its limits.

Coding, extraction, and classification can offer useful starting points because outputs can often be checked against tests, schemas, or labeled examples. Those checks have limits, and their coverage should be understood.

The decision to scale should rest on demonstrated operating performance: verified outcomes, manageable exceptions, and an acceptable cost of ownership. That is the point at which an impressive capability becomes a dependable business process.