Agents in Teams: who holds the bill when the prototype becomes enterprise usage?

From prototype to enterprise usage, in record time

An agent published in Teams can cross the line between demonstration and enterprise usage at a dizzying speed. What was a useful prototype for a few users suddenly becomes available to entire teams, with the leverage typical of collaboration tools: fast adoption, little friction, and consumption that follows the same slope.

Microsoft's documentation describes publishing Foundry agents to Teams and Microsoft 365 Copilot, with an approval step depending on the path chosen. That point is worth emphasizing: depending on the route taken, a control already exists in the process. But someone still needs to occupy that control, and the financial question needs an explicit place in it.

That is where the real risk lies. An agent that is technically ready, integrated, tested, and appreciated by its first users is not necessarily financially ready. The difference between the two plays out in a very short window, often between a convincing demo and an announcement in a team meeting.

The core question: who controls the bill?

When an agent becomes enterprise usage, its consumption stops being a technical anecdote and becomes a cost line in its own right. Who pays? Which cost center? How does the cost evolve with the number of users, conversations, runs? These questions do not need a perfect answer, but they need a clear one before opening up, not after the first bill.

The temptation to treat an agent as just another IT project is strong. That would be a misjudgment: an agent calls models on every execution, and its unit cost depends on variables that partly escape classic infrastructure governance, such as interaction length or the model selected. The cost per run then becomes the relevant unit of measurement, alongside the usual adoption indicators.

Three named owners before opening up

Before any large-scale opening, three roles should be named, with distinct and documented responsibilities. The first is the Product owner: they own the version, the expected usage, and the success criteria. Without them, the agent lives without a measurable purpose, and no one can say whether its cost is justified.

The second is the Platform owner: they cover access, data, supervision, and the shutdown procedure. That last point is often overlooked, even though it determines the ability to react to runaway consumption or unexpected behavior.

The third is the FinOps owner: they define cost allocation, cost per run, alerts, and the budget. This is the safeguard that turns a consumption trajectory into a managed one. These three roles are not honorary titles: each must know the answer within their own scope, and know who decides when usage and budget come into conflict.

Updates, the blind spot of cost per task

An agent is never frozen. An agent update, or a change in the underlying model, can silently change the cost per task: a more capable model may be more expensive to run, a change in calling logic may multiply invocations, and a new feature may lengthen interactions.

A simple rule should therefore be established: any agent or model update triggers a new check of the cost per task. That check does not have to be long; it should compare unit consumption before and after, on a comparable scope, and verify that the gap is consistent with the value expected from the update.

One important caveat: version-related behaviors and the exact shutdown functions depend on the deployment method. To be verified in the target environment before publishing, without relying on generalities. What holds for one publishing channel does not necessarily hold for another.

Trade-offs to own

Setting up this framework has a cost, and it must be owned explicitly. Approval steps slow down publishing; budget alerts create discussions; the requirement for success criteria forces product decisions. Conversely, the absence of a framework defers those frictions to the moment they hurt most: when consumption has already slipped and usage is entrenched.

The right balance, in my view, comes down to one sentence: publishing speed stays high, but the front door is locked by simple questions that cannot be answered with a plain yes. Version, expected usage, access, data, shutdown procedure, allocation, cost per run, alerts, budget. Nine points, three owners, one decision.

A checklist before scaling up

To make this framework operational, here is a suggested checklist, to be treated as a starting point to adapt to your context:

1. Name the three owners explicitly: Product, Platform, FinOps.

2. Document the agent version, the expected usage, and measurable success criteria.

3. Verify access, the data mapping, and the supervision available.

4. Test the shutdown procedure in the target environment, since the exact functions depend on the deployment method.

5. Define cost allocation and the relevant unit of measurement, typically cost per run.

6. Configure alerts and set an initial budget, even a provisional one.

7. Plan the recheck trigger: any agent or model update restarts the cost-per-task calculation.

A governance question, not a brake

Agent governance is only useful if it does not kill the agility that makes agents valuable. The goal is not to prevent publishing, but to make sure that by the time an agent becomes enterprise usage, someone already knows who funds it, how its cost is measured, and how to stop it if needed.

The question to ask internally is simple: in your organization, who validates that an agent that is technically ready is also financially ready? If the answer is not obvious, the third chair at the approval table is probably still empty.