A coding agent should take a billing setup into a sandbox, where a human can test it, rather than deploy billing logic to production on its own.
2
Portable skills files give the agent context about a complex billing API, while detailed error messages help it correct failed calls.
3
Agents can be products, buyers, or users, and the last category pushes software companies away from seat pricing toward usage and credits.
Summary
Andrew Garvin demonstrates a Stripe Projects workflow that uses a coding agent to create a Metronome billing sandbox from a natural-language request. His example copies Lovable's prepaid credit model, including auto recharge, separately scoped credit pools, usage, and a draft invoice. The demonstration depends on portable skills files that explain Metronome's API and verbose errors that let the agent recover from mistakes. Garvin is clear about the boundary: billing contains business-critical rules and real financial consequences, so the agent should accelerate setup and testing while a human remains responsible before production. He also presents three ways to think about agents: as a product being priced, as a buyer that can provision services, and as a user consuming software. The last case changes pricing assumptions because one agent may do work that previously required many seats. HubSpot's move toward credits is his example of that shift.
Billing agents can create expensive failures when usage and credits are involved
Garvin says Metronome has spent years metering API calls for companies such as OpenAI and Anthropic, while also handling credits, commits, discounts, and offers. Agent-driven products add another failure mode because an agent can run away with spend. His example is an agent with a wallet that it alone can spend from, with controls at that level. Billing is difficult because a system may need to combine pay-as-you-go usage with prepaid balances, sales commitments, discounts, and limits. Those rules need to be tested before customers or production traffic are involved.
A natural-language request can provision a billing sandbox through Stripe Projects
Garvin initializes Stripe Projects from the CLI and selects Claude for the setup. Stripe Projects provisions a Stripe account and backend services, which can include services such as Vercel, Postgres, and a Metronome billing agent. He then asks the system to create a demo billing engine that mimics Lovable's pricing model. The request includes a prepaid credit system with automatic recharge. The live demo has a setup error before it proceeds, which gives a concrete example of why this workflow belongs in a test environment.
Portable skills files carry the API context an agent would otherwise miss
Metronome has invested in an extensible set of skills files for agents working with its API. Garvin says the files provide context about a complicated product, reduce friction during setup, and can be installed and used by customers on their own side. They are portable, so the guidance does not need to remain inside one demonstration. In the demo, the skills also direct the agent to send usage into Metronome. That lets a developer inspect a customer with actual usage rather than checking only whether an account or contract was created.
Billing should stop at the test environment until a person checks it
Garvin rejects the idea that a customer should operate the whole billing system without human involvement. He describes billing as business-critical and full of deep business logic. His recommendation is to use the coding agent to accelerate the work into a test mode, then test the setup before moving anything to production. The demo creates a sandbox rather than deploying directly. For Metronome, testing means more than seeing a provisioned customer. It also means sending usage through the system so the resulting balances and invoices can be inspected.
Verbose errors give the agent a chance to fix its own API calls
During the setup, Garvin points to an error response and explains Metronome's developer experience approach. The team wants errors to be more verbose and clear so an agent can understand what failed and self-correct. He says the team is looking for more failure cases, especially during initialization and setup, then improving the guidance those errors provide. This is a practical guardrail for agent-driven development. The agent still makes mistakes, but the API response contains enough information for the next attempt to be better.
Agents have different economic roles as products, buyers, and users
Garvin separates three roles that companies often group together. An agent can be the product, which creates a need to meter tokens or other usage. It can be the buyer, as in Stripe Projects procuring a Stripe instance and backend services for an application. It can also be the user, which is the role he says is driving Metronome's current growth. Each role changes what a company needs to expose and how it should charge. The buyer role also means services need to be discoverable to agents that are building applications or working on the open web.
Agent users weaken the connection between seats and software value
Garvin cites HubSpot as a company moving from a seat-based model toward credits. He says the change is beginning in EMEA, with a lower seat price and a credit-based model added alongside it. The reason is that an agent may operate an entire system, so paying for a seat that represents a human login becomes less useful. He calls this direction headlessness and says Salesforce and others have discussed it. If one agent performs work that previously involved many users, pricing needs to track the work or usage rather than the number of seats.
The demo builds scoped credits, usage, and a draft invoice from one description
Inside Metronome, Garvin opens the customer created for the test and then its draft invoice. The setup copies Lovable's credit-only model, with monthly auto recharge, different credit types scoped to different usage, and an invoice for overspending at the end of the period. The invoice contains separate pools for build credits, plan mode credits, cloud credits, and AI gateway credits. Metronome's first-class credit object holds the initial balance, while the usage added by the agent draws that balance down. This gives the developer something concrete to inspect before production.
"The fundamental reason behind that is because what they need to be concerned about is a world in which an agent can operate their entire system."11:00
Who should watch
You are using an agent to set up usage billing and need a boundary between fast experimentation and production deployment.
Your API has to work with coding agents, and you want practical ideas for skills files and error messages that help them recover.
Your pricing still assumes one human per seat, while agents may perform work for many people or consume the product directly.
