Paying for agents you deploy at a client's site

Decide whose money the deployment spends

A consultant sent to a client site might use the consultancy's company card and expense the work, or receive spending access funded by the client. The physical location of the work does not decide who pays. Your agreement does.

The same applies when you deploy an agent that buys research, enriches records, or generates media. Before adding a credential, settle who funds the calls, who can change the allowance, and what happens when the engagement ends. Vaaya's agent keys provide the delegated-spending part of this corporate-card analogy; they are not issued bank cards.

A working prototype can conceal these questions because its creator pays for every experiment. After the client starts using it, an unrestricted development key becomes a continuing financial commitment. Give the production deployment a deliberate owner.

Choose between provider-funded and client-funded operation

In a provider-funded arrangement, your business pays Vaaya and charges the client under your service agreement. You might include a usage allowance in a fixed fee or invoice agreed usage separately. That commercial decision belongs in your contract and billing system.

Keep the Vaaya credential on infrastructure your business controls. If the client's users need to request work, expose an authenticated application interface that checks the client, allowed operation, and budget before your server calls Vaaya. Do not let a client-supplied account identifier decide which other client's work it can request.

In a client-funded arrangement, the client owns the Vaaya account and supplies a deployment-specific credential through its secret-management process. The client can review its account, change the allowance, or revoke access without asking you to move the deployment onto a different payment source.

When the client controls the machine or runtime, assume its administrators can inspect credentials stored there. For a deployment that needs the client's own payment and account-data boundary, use a client-owned account. An ordinary key from your shared provider account cannot create that boundary.

Ordinary keys separate attribution, not client accounts

Give each provider-controlled deployment its own key. Use a recognizable label and maintain an application record linking your client ID, deployment ID, and Vaaya key ID. An external ID is a mapping aid, not proof that Vaaya created a new customer account.

Ordinary keys share the owner's account and wallet. Read access can expose account-level agent information and transaction history. A spending ceiling does not turn that credential into a private client portal. Keep it server-side even if its permitted spend is small.

Keep the primary management key away from client deployments. An ordinary non-primary key cannot manage sibling keys, but that narrower write permission does not imply that all account data is isolated. Separate funding ownership, secret storage, and data access explicitly.

Vaaya also documents managed customer accounts for applications with managed customer access. This separate integration gives a customer a distinct identity and wallet, funded explicitly from the developer's prepaid balance. It supports a narrower set of synchronous catalog calls; streaming LLMs, routed One methods, and background jobs are not supported by managed wallets yet. Confirm access and endpoint support for your integration before designing around it. Creating an ordinary agent key does not enable it.

Make the engagement budget visible

For an ordinary key, set a day, week, or month ceiling appropriate to the agreement. Its usage is available for the current period. The account still needs funds, and other deployments under the same owner still draw on that account.

Imagine a consultancy agreeing to a $30 weekly tool allowance for one client deployment. This is an invented example, not a Vaaya customer record or service price. If the engagement lasts three weeks, a weekly ceiling alone does not enforce a $70 engagement total. Your application must also track and limit that total across calendar periods.

Assign someone to review spend against delivered work. A low bill can hide an agent that stopped early, while a higher bill might reflect an agreed increase in workload. Keep the requested output, relevant receipt IDs, final status, and client mapping together so the reviewer can explain either case.

Turn usage into a bill deliberately

A per-key usage total is useful evidence for accounting. Your client invoice also depends on the agreement: included usage, markup if any, support fees, credits, and who pays for rework. Vaaya cannot infer those terms from the key's label.

For usage-based billing, collect records throughout the engagement in your application and reconcile their final charges before invoicing. Retain the link from a client charge to the underlying work. Do not add an aggregate settlement to usage you have already counted and treat both as new spending.

Native client statements and automatic rebilling are Coming soon. Today, your own reporting and invoicing process must perform the client mapping and apply the commercial terms. Avoid promising clients an automatic monthly statement until that process exists.

Include the ending in the deployment plan

At handover or termination, stop scheduling new work, reconcile outstanding jobs, and revoke the engagement's credential when access should end. Revocation prevents later authenticated calls; it does not cancel a provider job already running or reverse its charge.

Record who retains outputs and receipts, who owns the remaining account balance, and whether the client will continue under its own account. For the provider's cash planning, see treasury management for an agent-run business. For the controls delegated to each deployment, start with your agents need corporate cards.

Before the next client launch, put the funding owner, deployment key, allowance, review date, and offboarding owner in the same deployment record.

Questions

Does a separate agent key give each client a separate account and wallet?

No. Ordinary agent keys share their owner's Vaaya account and wallet. A key label or external ID helps attribution but does not provide tenant isolation. Managed customer wallets are a separate access-dependent integration.

Who should own the Vaaya account for an agent running on a client's infrastructure?

Use a client-owned account when the client controls the runtime and needs its own payment and account-data boundary. If the provider pays, keep its credentials on a provider-controlled server behind an authenticated application interface. Never put the provider's primary management key in a client deployment.

Will Vaaya automatically turn client usage into an invoice?

Native client statements and automatic rebilling are Coming soon. Current per-key usage can inform your own reporting and invoicing, with your application responsible for client mapping, pricing, and reconciliation.