Who Pays for the AI Agent: Central Budget or Departments?

In most companies the best answer is a hybrid. Fund the shared foundation centrally, and charge the running cost of each agent role to the department that owns it. Central funding protects experimentation and standards, while departmental charging creates accountability for value, so the right split depends on who can actually judge whether an agent is worth what it costs.

Key takeaways

• Funding is not only an accounting choice. It decides who asks for agents, who says no, and who cleans up when a pilot stalls.
• Central funding lowers the barrier to starting and keeps standards consistent, but it makes agents feel free and weakens ownership.
• Departmental chargeback ties cost to benefit, but it makes teams avoid shared work such as monitoring, evaluation and permission review.
• Split costs by what they buy: the shared foundation and incident response are central, the agent role and its usage belong to the department that defines its success.
• Start by showing each department its costs before billing them, and review the split whenever the number of agents or users changes materially.

Why does the funding question matter more for agents than for software seats?

A software seat is simple. One person, one line on an invoice, one obvious owner. An AI agent role behaves differently. Its cost moves with use: how many requests it handles, how many documents it reads, how many actions it takes in your tools. It also depends on parts that no single department owns, such as the connection to your systems, identity and permissions, logging, and the method used to evaluate its work.

So the question "who pays" quietly becomes three other questions. Who decides which agent roles exist? Who is accountable for the value they deliver? And who notices when cost drifts away from value?

The way you answer shapes behavior long before it shapes a spreadsheet. If the answer is vague, you get one of two outcomes: agents multiply because nobody is charged, or they never start because nobody will volunteer a budget. How a vendor invoices you (by usage, by seat or by retainer) also limits what you can allocate, which is why it helps to read how AI agent pricing models differ before you design the internal split.

What does central funding do well, and where does it go wrong?

Under central funding, one budget, usually held by finance, operations or a technology leader, pays for the agents, and departments request them. This has real strengths.

• It removes friction at the start. A team with a good idea does not need to find money first.
• It lets leadership choose roles by value to the company, not by which department has spare budget.
• It keeps one approach to permissions, logging, data handling and vendor terms, so you do not end up with several different standards.
• It avoids duplicate tools bought by neighboring teams for the same job.

Central funding fits the early period particularly well, when nobody yet knows what an agent role is worth and the honest goal is to learn.

The incentives it creates are the problem. When a resource is free to the requester, demand grows without discipline. Requests arrive as wish lists. Departments treat the agent as a service delivered to them rather than a role they manage, so they invest less in adoption, feedback and clear instructions. The central team ends up responsible for outcomes it cannot influence, and its budget becomes an easy target at the first cost review.

Watch for these signs that central funding has drifted into trouble:

• Requests arrive without a named owner or a stated success measure.
• Agents keep running after the team that asked for them stopped using them.
• The central team can report total spend but cannot say what any single role achieved.
• Departments describe the agent as "the central team's project".

What does departmental chargeback do well, and where does it go wrong?

Under chargeback, each department pays for the agents it uses, either from its own budget or through an internal allocation. The strengths mirror the weaknesses of central funding.

Chargeback ties cost to the people who benefit. It forces a business case before the role is created, and it gives the department a reason to tune the scope, improve the instructions and retire roles nobody uses. It also produces a natural owner: the person whose budget pays is the person who answers the question "is this worth it?"

The incentives it creates are different, and they are easy to underestimate.

• Departments avoid shared work. Monitoring, recurring evaluation and permission review feel like overhead when they appear on your own line, so they get postponed.
• Small teams under-invest. A team with a tight budget may skip testing to save money, then absorb the cost of a visible mistake.
• Shadow tools appear. If the official agent carries a charge and a consumer tool can be bought on a card, some teams will choose the card. That feeds the tool sprawl you were trying to prevent.
• Allocation arguments consume energy. Debating how to split a shared integration between three teams can cost more than the integration.
• Surprise bills damage trust. Usage that varies from month to month, charged to a department that could not predict it, makes people distrust the whole program.

The last point has a practical remedy: set limits and alerts before you charge anyone. A practical setup for agent usage limits and budget alerts turns a variable cost into one a department can plan around.

Which costs belong in the shared pool, and which belong to the department?

The cleanest way out of the central versus departmental debate is to stop treating the agent as one cost. Split it by what each line buys. Use this decision guide:

• Shared foundation (identity, permission framework, logging, the evaluation method, vendor and data-handling terms): central. The benefit and the risk are company-wide, and no department should be able to defer them to save money.
• Connections to systems many teams use, such as a customer system or a ticketing tool: central, because several roles depend on them.
• The agent role itself (its instructions, memory, tools and approval rules): the department, because the department defines what success means.
• Usage and tool actions of that role: the department, within a limit set by the central owner.
• Staff time spent reviewing the agent's work: the department, and it should be counted, because it is part of the true cost.
• First experiments and pilots: central, with a time limit and a clear question to answer.
• Incident response and recurring permission reviews: central, because they must not depend on one team's budget cycle.

Two tests settle most borderline cases. If you cannot say who benefits from a cost, it is shared. If a department could switch something off and the rest of the company would not suffer, it is theirs.

How do you build a hybrid model step by step?

You do not need a finance project to start. This sequence works for a mid-sized company and can be done with a spreadsheet and a few conversations.

• Name an owner for every agent role. This is a business person, not a technical one, and the guidance on what an executive sponsor for an AI project must do applies at role level too.
• List every cost line using the categories above, including the human time spent on review and feedback.
• Make usage visible per role. Without tagging activity to a role you can only see a total, and a total cannot support a decision. The observability concepts in the OpenTelemetry primer describe the logs, metrics and traces that make this possible.
• Create a shared pool for the foundation, incident response and time-limited pilots.
• Begin with showback for one full cycle. Report each department's role costs to it without billing, so people can question the numbers before the numbers carry consequences.
• Agree on a unit of value for each role, such as cost per handled request or per drafted document. The FinOps Foundation's material on unit economics explains why a cost per unit of value is more useful than a total.
• Switch the running costs of each role to the owning department, with limits and alerts set in advance.
• Review each role on a regular schedule and make one of three decisions: continue, change or retire. The guide on stopping a pilot without wasting the work already done helps when the answer is retire.

The NIST AI Risk Management Framework is a useful reference for the accountability side of this plan, because it treats clear roles and responsibilities as part of managing AI, not an afterthought.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a real company. A distribution business has a customer support team, a finance team and a sales operations team. Leadership wants to try an agent in support first.

The company pays for the first pilot from a central pool. The support manager is named as the owner of the role and defines the success measure: how many routine requests the agent drafts correctly, as judged by the team lead. For one cycle the support manager receives a report of what the role used, with no charge attached.

The report shows that most of the cost comes from a few long, rarely useful tasks. The manager narrows the scope. Cost falls and quality holds. Only then does the usage of the role move to the support budget, with an alert set well below the point where the manager would be uncomfortable.

Later, finance asks for its own agent. It wants access to the same ticketing connection support already uses. Because that connection sits in the shared pool, finance does not inherit a share of an integration it did not request, and support does not feel it is subsidizing a neighbor. Each department pays for its own role. The company pays for what everyone depends on.

The model can still fail. If the central pool is too thin, foundation work gets skipped. If chargeback starts before the department understands its numbers, people retreat to cheaper tools. Review both after each new role is added, and revisit the split when many more teams join. The article on scaling AI agents across a company, one team at a time covers how to pace that growth.

How does Be Human's managed approach handle the funding question?

Be Human's first engagement defines one useful role: its memory, its tools, its approval boundaries and an observable success criterion. That gives a company a natural unit to attribute cost to and an owner to attach it to. Managed operations, which can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, are recurring foundation work that suits a central budget. Activity can be reported per role, so a company can choose central funding, showback or chargeback for the role itself. How the cost is allocated inside the company remains the company's decision.

Frequently asked questions

Should IT own the AI budget? IT is a sensible custodian of the shared foundation, since it already handles access, vendors and security. It is usually the wrong owner of the value of each role, because it cannot judge whether a support or finance task is being done well. Keep the foundation with IT or operations, and give each role an owner in the business.

Is showback enough, or do we need real chargeback? Showback is enough while the company is learning and the numbers are still moving. Move to chargeback once a role has a stable scope, a named owner and a usage pattern the department can predict. If departments ignore the showback report entirely, that is a sign the cost is too small to matter or the report is not useful, and neither calls for billing.

How should we handle an agent used by several departments? Treat it as shared infrastructure, not as a role belonging to one team. Fund it centrally, or split usage by tagged activity if the departments rely on it to different degrees. Name one accountable owner so it does not become everyone's tool and nobody's responsibility.

What if a department cannot predict usage costs? Set a usage limit and an alert before charging, and share the report with the owner regularly so they learn the pattern. Where the cost is still unpredictable, keep it in the central pool until the role stabilizes. Charging a department for a number it cannot control teaches it to avoid the agent.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.