To govern an agent, define its purpose, access, and review process, then assign someone to oversee its operation and cost. Measure cost against useful work, such as a completed intake review. Name who will respond when quality or cost falls outside the agreed limits.
Set limits, review quality and cost, then adjust with a named owner.
Use an owner, limit, and review framework
AI cost governance connects three decisions: who owns the work and spending, which limits apply, and what evidence triggers a review. A budget is one control inside that framework. Quality, permissions, and human review still determine whether the work is acceptable.
Scroll horizontally to see all columns.
| Decision | Record before launch | Review question |
|---|---|---|
| Owner | Workflow owner, budget owner, organization admin, and exception responder | Who acts when the workflow becomes costly or unreliable? |
| Limit | Monetary allowance, currency, period, scope, and applicable request path | Does this path apply the policy and the intended response? |
| Review | Completed tasks, quality findings, repeated attempts, and spending | Are cost changes explained by more useful work or avoidable rework? |
AgentShelf supports monetary budgets for organization, team, user, and widget scopes. Organization admins choose hard or soft budgets. On supported covered paths with an active policy, soft limits warn and continue; hard limits reject covered requests at the limit. Other paths can continue without a budget check. Agent and workspace reporting provides visibility, not separate enforcement. These controls make budget responsibility concrete while leaving source permissions and quality review as separate decisions.
For choosing amounts, periods, scopes, and verifying actual request coverage, use the LLM budget management guide. The framework below explains how to operate that policy alongside quality and authority controls.
Assign the workflow and budget owners
Use one fictional workflow throughout this guide: a procurement reviewer asks, “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent compares the submitted packet with the current vendor intake checklist and record. The packet lacks a current insurance certificate, so the agent prepares a review summary and a draft request. A person still decides whether to send the request or continue the vendor review.
The operating record for that draft could read:
Northstar Supplies intake — operating review (draft)
Owner: Procurement process owner; assign a named person before the pilot.
Allowed: Read the packet, current checklist, and current vendor record; prepare a summary and draft request.
Human decision: A procurement reviewer checks the evidence and decides whether to send the request. The agent cannot update the record or approve the supplier.
Review signals: Missing-evidence findings, reviewer corrections, handoffs, and cost per reviewed packet.
Cost limit: Set with the budget owner from an expected workload and pilot baseline; no threshold is set in this example.
Status: Draft for review before pilot.
Before a pilot, assign a process owner and an operator for exceptions. Record who may request the review, which packet and reference sources are in scope, what the agent may read, and what it may prepare. In this example, the permitted output is draft text; changing the vendor record, sending a request, or approving the supplier remains outside the agent’s authority. Name who can pause the workflow and who reviews the draft.
Review cost per useful task through each stage
- Before the pilot: Agree on the job, approved sources, read and write permissions, human review point, fallback path, and tests. Set a monetary spending allowance and verify the response on the selected request path.
- During the pilot: Review completed drafts and exceptions. Track packet volume, cost per reviewed packet, time spent by reviewers, missing-evidence detection, and corrections. Interpret the measures together: a low cost per packet is not useful if reviewers must redo the work, and a handoff can be the correct outcome when evidence is missing.
- Before expanding: Confirm the owner, user group, data access, tools, and review rules still match the workflow. Revisit the tests when the checklist, source records, or permissions change.
For the Northstar example, count a useful unit as one packet that a reviewer can assess using the summary and evidence. Include model usage, repeated attempts, connected service charges, and review or correction time when measuring cost. Do not infer savings from the number of drafts; compare cost and quality against the current human process over the same set of work.
Calculate cost per completed task
A cheap model can still produce an expensive workflow. If its results need heavy fixing, the staff time can outweigh any savings on model charges. To compare options fairly, add up everything a workflow costs, including failed attempts and the time people spend reviewing and correcting results. Then divide by the number of results you could actually use.
Cost per usable result = (model charges + other service charges + staff time reviewing and fixing results + any running costs you choose to include) ÷ usable results.
Compare options on the same task, over the same period, using the same rule for what counts as usable. The agent can fill in most of the worksheet from its own usage records and the review outcomes. Your team sets what counts as usable and the hourly rate for staff time.
Cost per completed task worksheet (blank)
- Task, and what counts as a usable result: ___
- Period and number of tasks submitted: ___
- Model attempts and charges (include retries and failed attempts that were charged): ___
- Other service calls and charges (include repeated calls): ___
- Staff time reviewing and fixing results, and the hourly rate used: ___
- Running costs included, and how they were divided, or a note that they were left out: ___
- Usable results (count results, not attempts): ___
- Total cost, and cost per usable result (if no results were usable, report the total cost and that outcome): ___
Here is a fictional comparison of two options on the same 100 tasks. The numbers are made up to show the method. They are not real model prices or customer results.
Scroll horizontally to see all columns.
| Item | Cheaper model | Pricier model |
|---|---|---|
| Tasks submitted | 100 | 100 |
| Model attempts | 200 at $0.01 = $2 | 100 at $0.03 = $3 |
| Other service calls | 200 at $0.02 = $4 | 100 at $0.02 = $2 |
| Staff time reviewing and fixing | 400 minutes at $30/hour = $200 | 100 minutes at $30/hour = $50 |
| Usable results | 80 | 90 |
| Total cost | $206 | $55 |
| Cost per usable result | $2.58 | $0.61 |
Staff time makes almost all of the difference here. That is an assumption of the example, not a rule that pricier models need less review, so measure it in your own pilot. Hosting and other fixed costs are left out of both columns. In a real comparison, say what you left out and check quality on the same set of tasks.
This worksheet measures what a result really costs. A budget does something different: it caps spending on the requests it covers, and staff time is not part of it. See AgentShelf's budget controls for what a budget covers.
Use a cost governance checklist
- Name the owners of the workflow, the budget, and exceptions.
- Agree what counts as a usable result, and fix the workload and period you will measure.
- Record the budget and how requests reach the agent, then test what happens at the limit.
- Count failed attempts, and say which costs are measured and which are left out.
- Review quality, rework, usable results, and spending together.
- Record whether you will adjust, pause, or continue, and what triggers the next review.
Define separate cost, quality, and authority responses
Choose a trigger and owner for each kind of stop. These fictional Northstar examples do not set a universal threshold:
Scroll horizontally to see all columns.
| Condition | Example trigger | Response |
|---|---|---|
| Quality | A reviewer cannot trace a required finding to the approved packet, checklist, or vendor record. | Pause that packet’s draft, identify the missing or conflicting evidence, and rerun the affected case before accepting the result. |
| Spend | The pilot reaches the monetary limit set with the budget owner. | A covered hard policy rejects requests; a covered soft policy warns and continues. The named owner reviews spending and decides whether to pause the workflow or change its allowance. |
| Authority | A run attempts to send a request, change the vendor record, or approve the supplier. | Treat it as a boundary failure, block the action, and verify system state before any retry. |
Set the spending threshold from expected workload and the cost of a reviewed packet. Confirm that the configured path applies it to the intended workflow; if the environment cannot pause use, assign an operator to monitor and stop it manually. Review available run records for sources, tool activity, handoffs, and failures. Compare a repeatable set of ordinary, incomplete, and conflicting packets after changes. If a record cannot explain a draft, add an appropriate review step before expanding use.
Keep the owner, limit, and review record current
Keep a current record of:
- Ownership: The workflow owner and intended users.
- Scope and permissions: Approved sources, action scope, and approval rules.
- Evidence and evaluation: Evaluation criteria and cost baseline.
- Operating limits: Known limits and the pause procedure.
- Review: The review date.
Revisit the record on a schedule and after a material change. See the permissions review, pre-pilot evaluation guide, and AgentShelf’s governance and cost controls overview for related guidance.