Every Agent Needs a P&L

Give an agent a goal, access to a model, a retrieval layer, a set of tools, and permission to act. It consumes resources. It makes decisions about how to use them. It creates an output that is supposed to have business value. Sometimes it succeeds. Sometimes it retries, escalates, or creates work that somebody else must repair. That is not a feature call. It is a tiny operating business.

Yet most companies account for it like software. They watch token spend, perhaps latency, and perhaps the number of conversations. Those numbers are useful for engineers and almost useless for deciding whether the agent deserves another dollar. A finance leader cannot compare 4.8 million tokens with an analyst, a managed service, or a process redesign. A product leader cannot tell whether more usage is adoption or simply more looping. An executive sees a growing invoice attached to a promising story and has no honest way to join the two.

The missing artifact is a profit and loss statement for the agent: the value of accepted outcomes on one side, the complete cost of producing them on the other, and the difference in the middle. Not an annual business case assembled before the pilot. A living operating view, by workflow and by outcome, that changes when the agent changes.

This is the Cost pillar of the 4 C's made operational. Chapter 18Chapter 18 · 6 min LockedThe Hidden Cost of Agentic AIWhere the dollars actually go. explains where agentic cost actually hides. This essay goes one step further: once the cost is visible, give it an owner, place it beside value, and force the system to earn the autonomy it consumes.

Imagine a customer-support agent that handles ten thousand conversations. Reporting that it consumed nine hundred million tokens tells you what one supplier metered. It does not tell you whether customers got answers, whether cases closed, whether people had to correct the answers, or whether the company saved a minute of work. It is like judging a restaurant by kilograms of flour used.

The denominator has to be a completed business outcome. For support, that might be a case resolved without reopening within seven days. For finance, an invoice matched and accepted without correction. For engineering, a change merged and still healthy after deployment. For analytics, a decision-ready answer with approved sources and no material revision. The definition must include acceptance, because generated is not the same as useful and delivered is not the same as correct.

Once the outcome is defined, three numbers become possible: cost per attempted outcome, cost per accepted outcome, and value per accepted outcome. The second number is the one most dashboards avoid. It includes every failed attempt required to produce the successful ones. If an agent completes one task for a dollar but only half its work is accepted, its effective unit cost is already two dollars before review and remediation enter the account.

Chapter 20Chapter 20 · 6 min LockedBudget-Aware AI DesignDesigning for budgets from day one. treats budget as an architecture input, not a finance constraint added later. That starts with naming the unit the budget buys. If nobody can finish the sentence ‘one dollar buys us…’ in business language, the programme does not have unit economics. It has telemetry.

Model inference is only the visible line. The full stack begins with generation and embedding calls, then adds retrieval, reranking, storage, orchestration, tool execution, observability, security services, network movement, and the idle capacity of infrastructure reserved for peaks. Those are the direct costs. Agentic systems then add a more important set of variable costs: retries, fallback models, repeated retrieval, long-running loops, human review, escalation, incident response, and repair.

Failures belong inside the unit cost, not in an operational footnote. Suppose a claims agent costs thirty cents when it works. One in ten attempts needs a second model pass. One in twenty reaches a human for six minutes. One in two hundred creates forty minutes of correction. The nominal thirty-cent workflow may have an effective cost several times larger. The precise number depends on wages and volumes; the accounting principle does not.

Context has a cost too, and that does not make context optional. Better definitions, retrieval, and memory often increase the first-pass request cost while lowering the total cost per correct outcome. A longer prompt that prevents two retries is cheaper. A reranker that avoids a ten-minute human review is cheaper. A curated semantic layer that costs money to maintain may eliminate an entire class of incorrect answers. This is why Chapter 21Chapter 21 · 6 min LockedQuality, Speed, and Cost TradeoffsHow to balance accuracy, latency, and spend. balances quality, speed, and cost instead of optimizing any one alone.

The practical rule is simple: allocate every cost that changes when the workflow runs, and separately track the shared platform cost required to keep it available. Do not bury the second category, but do not divide it so aggressively that a useful small workflow appears uneconomic merely because it was the first tenant on a new platform.

A useful P&L does not need accounting theatre. Start with one workflow, one owner, one month, and seven lines. Volume: how many eligible tasks arrived. Attempts: how many agent runs occurred. Accepted outcomes: how many met the business definition. Gross value: the conservative value of those accepted outcomes. Direct run cost: models, retrieval, tools, and infrastructure. Review and failure cost: human minutes, retries, escalations, and remediation. Net contribution: gross value minus all attributable cost.

Add two quality notes beside the arithmetic: the acceptance criteria and the confidence of the value estimate. A resolved support case may have a strong value estimate because the company knows its historical handling cost. A sales research brief may have a weaker one because the link to revenue is indirect. Do not hide that uncertainty inside a precise-looking currency figure. Mark it, review it, and improve it with evidence.

Value should be conservative and causal. If an agent drafts a report that a person rewrites, it did not create the full value of the report. If an agent completes work that would otherwise wait rather than require a new employee, the value may be cycle-time improvement rather than avoided salary. If the workflow reduces risk, use expected loss avoided only when there is credible history behind the probability. Inflated value destroys the P&L faster than missing costs do, because people stop trusting the entire instrument.

The resulting number is not a verdict on AI. It is a decision surface. A negative contribution can be rational during a bounded learning period. A positive contribution can still be unacceptable if the downside risk is wide. What matters is that the subsidy, the learning objective, the owner, and the date of the next decision are visible.

Every production agent needs a named human who owns its economic result. Not merely the platform bill, and not merely model performance. This person owns the relationship between spend, quality, risk, and business value. They can explain why the agent exists, what one accepted outcome is worth, what the current unit cost is, which failure mode dominates that cost, and what decision will be made if the number moves outside its boundary.

That owner is rarely the central platform team. The platform team can make spend observable, provide routing, set common controls, and negotiate shared contracts. It cannot decide what an approved invoice is worth to accounts payable or how much review is acceptable for a clinical workflow. Economic ownership belongs with the workflow, close to the people who can judge its output and change the process around it.

This is the same ownership problem described in the Agent Org Chart, but with money attached. Context has owners because definitions decay. Actions have owners because permissions create risk. Agents need economic owners because activity expands until somebody is accountable for the return.

Without that person, optimization becomes local. Engineers lower token cost while human review rises. The business increases volume while the acceptance rate falls. Procurement secures a lower unit price while the architecture becomes harder to move. Each team improves its number and the company loses money more efficiently.

Most cost controls are rear-view mirrors. A threshold triggers after spend has crossed it, somebody receives an alert, and a meeting is scheduled. Agents operate too quickly for that pattern. A loop can consume the day's allowance while the owner is asleep. A malformed queue can turn one customer event into thousands of model calls. By the time a monthly report looks unusual, the decision has already been made repeatedly.

A budget contract moves the decision into the runtime. It states the maximum cost per task, per user, per workflow, and per period; the permitted number of reasoning or tool loops; the models available at each value tier; and what happens when a boundary is reached. The response should be designed in advance: use a smaller model, reduce context, switch from action to draft, ask for human approval, defer non-urgent work, or stop. Silence and surprise are not valid fallback modes.

Budget contracts should be paired with quality floors. A system that meets its budget by quietly dropping citations or using an unsuitable model has not been optimized; it has moved cost into error. The contract therefore carries both sides: spend ceiling and acceptance floor. Chapter 19Chapter 19 · 6 min LockedNot Every Task Needs the Best ModelRouting, cascades, and right-sized intelligence. explains model routing, while Chapter 36Chapter 36 · 10 min LockedCompaction and the Token BudgetBudget tokens like money, compact history without dropping commitments, and detect degradation before a user does. applies the same discipline to token budgets and compaction.

For consequential actions, the contract also carries a risk limit. The cheapest route is irrelevant if it increases the chance of an expensive irreversible mistake. Chapter 15Chapter 15 · 6 min LockedGuardrails, Approvals, and Audit TrailsDesigning safe agent behavior in practice. provides the guardrails and approval stack; The Blast Radius shows how to size the downside. A serious P&L includes expected failure cost, not just the happy path.

The most useful experiment in agent economics is not model A versus model B. It is context package A versus context package B, measured on accepted outcomes. Teams often treat retrieval, memory, semantic definitions, and examples as one growing bundle. They can see the tokens increase and cannot see which piece earns its place.

Run the comparison like a product decision. Establish a baseline with the minimum safe context. Add one context asset: a glossary, a customer history, a policy excerpt, a retrieved example, or a compacted memory. Measure the change in first-pass acceptance, retries, review minutes, latency, and total cost. The margin of context is the additional outcome value and avoided failure cost divided by the additional cost of supplying and maintaining that context.

Some context will have extraordinary margins. A current policy table may eliminate an entire review queue. Some will be decorative. A large history may add tokens while distracting the model from the present task. The point is not to minimize context. It is to make every recurring piece of context justify its place in the working set.

This connects the Cost and Context pillars directly. Chapter 6Chapter 6 · 6 min LockedBusiness Meaning Beats Raw RetrievalNaive RAG is not a context strategy. explains why business meaning beats raw retrieval. Chapter 35Chapter 35 · 11 min LockedRetrieval Mechanics: Chunking, Hybrid Search, and RerankingThe engineering layer under every context strategy — chunking, hybrid search, reranking, and how to prove it works. shows how to evaluate retrieval mechanics. The P&L supplies the final test: did better context improve the economics of a correct outcome, after its own maintenance cost was included?

Cloud programmes learned this lesson slowly: usage is not value. Agent programmes are about to learn it faster because agents can manufacture their own usage. A longer reasoning trace, more tool calls, more retrieved documents, and more generated drafts can make an activity dashboard look healthy while the unit economics deteriorate.

This is why requests, conversations, tokens, and autonomous actions should not be executive success metrics. They are diagnostic measures. The success metrics are accepted outcomes, cycle-time change, quality, avoided loss, net contribution, and the distribution of those results. Averages alone are dangerous. An agent can have positive average economics while a small class of failures carries an unacceptable tail cost.

Be careful with time saved too. Asking users how much time an agent saves produces generous numbers. Measure what happens to the process. Did the queue shrink? Did cycle time fall? Did capacity move to another named task? Did overtime decline? Did throughput increase without proportional hiring? Saved minutes become value only when something else changes because they were saved.

The discipline may produce an uncomfortable result: an agent people enjoy using but that does not yet create measurable economic value. That is useful information, not an argument to delete it immediately. Decide whether it is an employee benefit, a learning investment, or a strategic option, fund it under that name, and stop pretending it is operating leverage.

The P&L becomes valuable only when it changes behaviour. Run a monthly operating loop for mature workflows and a weekly one during launch. Measure the full stack. Attribute it to a workflow, owner, model, context version, and outcome. Decide whether the economics remain inside the agreed envelope. Constrain the system automatically where the boundary is hard. Improve the largest driver rather than the most fashionable one.

That last instruction matters. If human review dominates, a cheaper model will barely move the total. Improve grounding, scope, or the review interface. If retries dominate, inspect tool failures and ambiguous stopping rules. If retrieval dominates, test caching, indexing, and smaller working sets. If a rare incident dominates expected cost, reduce blast radius before optimizing tokens. If value is weak, change the workflow rather than tuning the agent.

Keep versions in the account. A model change, prompt change, context release, tool update, or policy change can alter both sides of the statement. Without versioning, a better month becomes a story; with versioning, it becomes evidence. Chapter 11Chapter 11 · 7 min LockedContext Is a Living Layer, Not a DocumentDefinitions drift, macro conditions shift, agents relearn — treat context like code, with ownership, versioning, and continuous review. argues that context should be managed like living infrastructure. Its economic effect should be versioned with it.

Over time, the P&L becomes a routing signal. High-value, high-risk outcomes can earn stronger models and more review. Low-value, reversible tasks can use smaller models and tighter budgets. Unprofitable classes can be deferred, batched, redesigned, or removed. The budget stops being an annual ceiling and becomes part of how the agent reasons about the work.

In the first week, choose one production workflow, name its owner, and define an accepted outcome. Pick something narrow enough that a knowledgeable person can inspect fifty examples and agree whether each one counts. Record the current human or software baseline without inventing precision.

In the second week, instrument every run with a workflow identifier, model and context version, token and tool cost, latency, retry count, final disposition, and review time. Preserve the links between attempts so three retries appear as the cost of one outcome rather than three unrelated requests. Do not wait for a perfect observability platform; a reliable export joined to an outcome table is enough to learn.

In the third week, label a representative sample, calculate cost per accepted outcome, and identify the largest cost driver. Include human time and failed attempts. Publish the assumptions beside the number. Invite finance, operations, and the frontline users to challenge them. A useful metric survives disagreement by becoming more precise.

In the fourth week, set one quality floor, one cost ceiling, and one runtime response for crossing each boundary. Then choose a single improvement against the largest driver and measure the next cohort. At the end of thirty days, you may not have a complete ROI model. You will have something rarer: an economic claim that another person can inspect, reproduce, and use to make a decision.

The first wave of enterprise agents was funded on possibility. That was reasonable. New capabilities need room to be explored before every benefit can be reduced to a line item. But exploration and operation are different phases, and the longer a programme stays between them, the more likely it is to mistake growing consumption for growing value.

A P&L does not make an agent less ambitious. It makes ambition durable. It tells the platform team where infrastructure matters, the workflow owner where quality pays, procurement where switching leverage sits, finance what the budget buys, and leadership which agents have earned a wider scope. It also makes stopping a workflow an ordinary portfolio decision rather than a referendum on AI.

The organizations that scale agents will not be the ones that make inference cheapest in isolation. They will be the ones that can connect every meaningful dollar of spend to a governed outcome, see when that relationship changes, and act before an invoice or an incident forces the conversation.

Every agent already consumes a budget and produces a result. Giving it a P&L does not create the economics. It simply ends the period in which nobody had to look at them.