The number arrived on a Monday, which is when these numbers always arrive.

Something had been given a task on the Friday afternoon. It was a reasonable task, given to a system that had been running quietly and correctly for two months, by a team that had done everything properly. The task involved reconciling a set of records against several sources and flagging discrepancies.

Over the weekend it reconciled those records against several sources and flagged the discrepancies. Then, because the instruction had been to be thorough and because it had no reason to believe it was finished, it checked the discrepancies. Then it checked the checks. Then it looked for related records that might also contain discrepancies, found some, and began again.

Nothing failed. No error was raised. No alert fired, because no threshold had been crossed that anybody had thought to define. Every individual step was a correct execution of a reasonable instruction.

By Monday morning it had performed roughly twelve thousand operations on a task that a person would have considered complete after about forty.

The Crocodile read the incident summary, which was not really an incident summary because there had been no incident, and opened one eye.

“It didn’t break,” he said. “That’s the problem.”

What changed

Everything in the previous three lessons assumed a shape: a request goes in, an answer comes out, and you can reason about the cost of that transaction because you know how many of them there are.

Autonomy removes that assumption. A task is no longer one call. It is a variable number of calls, determined at runtime, by the system’s own judgment about whether it has finished.

Read that sentence again, because it is the whole lesson. You have handed the spending decision to the workload. Not the budget, not the ceiling, the actual moment-to-moment decision about how much work this particular task warrants. That is a genuine transfer of financial authority and almost nobody deploying an agent has framed it that way to the person who owns the budget.

The four multipliers

Iteration depth. Steps per task, variable, and unbounded unless somebody bounds it. Most frameworks have a default. Most defaults are generous, because a low default makes the demo fail.

Context re-transmission. The state is resent at every step. This is where Lesson 13 stops being additive and starts being multiplicative. A bloated prompt in a single-call workflow costs you once. The same prompt inside a forty step loop costs you forty times, per task, forever.

Tool call fan-out. Each step may trigger retrieval, a search, a call to another system, each with its own cost, some of which sit outside your AI budget entirely and appear as increased load on systems whose owners have no idea why.

Retry and self-correction. Attempts that fail and are retried internally, succeeding on the third go. These are invisible in every error metric you have, because from the outside the task succeeded. It succeeded three times more expensively than the number in your business case.

Four multipliers, compounding rather than adding. A modest inefficiency in each produces a large number at the end, and none of the four is visible in a per-call cost report.

The variance problem

The most important operational point in this post, and the one I would put on a wall.

Average cost per agent task is a nearly useless number. The distribution is what matters, and the distribution has a tail.

Most tasks complete in a handful of steps and cost very little. That produces a healthy-looking average that will pass every review you put it through. Meanwhile some small proportion of tasks, triggered by inputs nobody anticipated, go around the loop a hundred times. Those tasks are where all the risk lives and they are entirely invisible in the mean.

Manage the ninety-ninth percentile. That is where the weekend incidents are, and the ninety-ninth percentile of an agent workload is often a startlingly different number from the average, in a way that is not true of any other cost line your organization manages.

The jungle’s twelve thousand step weekend did not move the monthly average very much. It was one task. It was also, on its own, a meaningful fraction of the month.

Controls that actually work

Four, and they are not sophisticated, which is what makes their absence so common.

• Step budgets. A hard maximum number of iterations per task. Set it deliberately rather than accepting a framework default, and set it based on what a competent person would need rather than what feels generous.
• Cost ceilings per task. Enforced at the gateway, not in the application. A task that exceeds its ceiling stops and escalates to a human, which is a far better outcome than a task that continues.
• Wall-clock limits. The simplest and most effective control against the weekend scenario specifically. Nothing autonomous should be able to run unattended for sixty hours because nobody was in the building.
• An external termination condition. This is the important one. The definition of done must not depend solely on the system’s own assessment that it is done. Something outside the loop has to be able to say that is enough.

Task-level attribution

A design requirement rather than a control, and it has to be decided before deployment because retrofitting it is close to impossible.

Cost must be attributable per task, not per call. If your instrumentation records calls, then an agent estate is a fog: you can see that a great many calls happened and you cannot connect them to the units of work that caused them, which means you cannot compute a cost per task, which means everything in Act II stops working the moment anything becomes autonomous.

Every call carries a task identifier. That is the whole requirement, and it is trivial on day one and a project on day four hundred.

The autonomy dial is a budget decision

The framing I would most like a leadership team to take from this lesson.

How much autonomy a system has is usually treated as a safety question, and it is one. It is also a financial one, because autonomy is precisely the property that converts a predictable cost into a distribution with a tail.

More autonomy means more capability on ambiguous work and more variance in what it costs. Less autonomy means narrower capability and a cost you can forecast. Neither is correct in general. Both are correct somewhere.

What should not happen is inheriting the setting from a framework default chosen by somebody who was optimizing for demonstration quality. Choose it, per workload, with the business in the room, and understand that you are choosing a cost distribution and not just a capability level.

Where agents earn their cost

To be clear that this is not an argument against autonomy.

Agents genuinely earn their cost on high value, low volume, previously impossible work. Investigations that a person would not have had time to run. Analysis across sources nobody would have manually connected. Work where the alternative was not a cheaper method but no method.

They rarely earn it on high volume routine work that a single well-routed call handles at a fraction of the cost. That is the same sufficiency argument as Lesson 12, one level up, and it fails the same way: somebody chooses the most capable available approach during a pilot and nobody revisits it.

The question to ask of any agent deployment is what would this cost as a deterministic workflow with three routed calls, and is the difference buying you anything. Sometimes it is buying you a great deal. Often it is buying you flexibility on a task that was never ambiguous.

Three ways this goes wrong

The unbounded loop. No step ceiling, no cost ceiling, no wall clock, discovered by invoice on a Monday.

Mean-only monitoring. A healthy average, a ruinous tail, and no visibility into the second until it arrives.

Agents as fashion. Autonomy applied to work a routed single call would have done better and cheaper, because agents were what the roadmap said and nobody asked what the alternative would have cost.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, stop asking for the average cost per agent task. Ask for the ninety fifth and ninety ninth percentile, and then ask what the hard ceiling is. If there is no hard ceiling, that is the finding.

If you sit in the Crocodile’s chair, enforce step budgets, cost ceilings and wall clock limits at the gateway before anything autonomous reaches production. Limits set inside the application are not limits, they are intentions.

If you sit in the Mandrill’s chair, choose the autonomy level deliberately and understand you are choosing a cost distribution. Then ask what the same task would cost as a deterministic workflow, because sometimes the answer changes your mind.

For everyone: require a termination condition that does not depend on the system’s own judgment about whether it is finished. Everything else in this list is a mitigation. That one is the actual fix.

Jungle Lesson 15

Autonomy is the point at which you stop buying answers and start buying attempts, and the system decides how many. Budget the tail rather than the average, because the average will look entirely fine right up until the weekend it does not.

That closes the third act. The jungle now knows where its unit economics are actually set, which turns out to be in a series of engineering decisions made months before anyone looks at a bill. Whether inference runs on a variable curve or a fixed one. Which tier handles which task. How much context travels with every question. Where the constrained workloads sit and what that costs. How much autonomy the system has and therefore how long its tail is.

Every one of those is a financial decision made by somebody who was not thinking about finance, using a default set by somebody who was thinking about a demonstration.

Which raises a question the jungle has been avoiding since Lesson 5. Who is allowed to make these decisions, how does the money reach them, and what happens to an organization whose entire funding machinery is built around things that end when the thing it needs to fund does not end? That is the fourth act, and it opens with the argument the Fox has been dreading, which is the one where he proposes reducing his own territory. Lesson 16 is about capability rather than project.

If you have anything autonomous in production, the fastest useful thing you can do this week is find out what your most expensive single task cost last month. Not the average. The worst one. Most organizations cannot answer, and the answer is usually the reason to build the controls.