Billing an AI Agent Without Breaking Its Tool Loop

A user instructs a desktop agent to create a promotional campaign, which involves inspecting products, verifying inventory, crafting copy, and generating an image. Publishing the campaign still requires business approval. This user request may involve multiple model requests, local tool calls, and an additional image-generation request.

To address billing concerns, a subscription gateway is proposed to be placed between the agent and its model provider. This gateway could either count every model request as a new conversational "turn" or hold off on delivering the final result until the billing record is confirmed. However, introducing this metering has altered who controls the workflow.

The article explores how to add account-level model billing while maintaining the agent's context, tool loop, and execution decisions in its host.

For a locally orchestrated agent, the host is responsible for maintaining the conversation, managing model calls, assembling context, supplying tool schemas, interpreting responses, executing authorized tools, and deciding whether additional model requests are necessary. The billing gateway, in contrast, has a narrower role: it authenticates the caller, checks access to the requested model service and its allowance, forwards the request, preserves the result, and tracks usage.

The host and billing gateway should remain separate entities, each with its own responsibilities. The host should not be transformed into a billing authority or a separate planner. Billing should not automatically grant permission to modify a product's price. The implementation should clearly distinguish between the agent's model request, the billing gateway's metering, and the business execution path.

The gateway adds latency, authentication, and persistence to the system. While these factors warrant measurement, they do not mean that the gateway should assume ownership of the user's task. The host should retain control over the user's workflow, including the decision to initiate additional model requests based on the agent's evaluation.

To ensure that billing is handled correctly, the host must create a new model-operation ID for each genuinely new request and store this ID before sending the request to the provider. If the provider fails to return a response, the host can use the original ID to recover the operation. It is also important to maintain separate identities for business invocations, as a model-operation receipt cannot prove the execution of the resulting business update.