An agent is not an extension of the employee who created it

AI

An agent is not an extension of the employee who created it

Anh-Tho Chuong•Sep 21•6 min read

A customer opens a support ticket. An agent reads it and drafts a reply. Who do you bill?

Almost every system answers with the employee who set the agent up. That is the natural model, it is the one your customer record already supports, and it is wrong in a way that stays cheap for about a year.

The request touched six things, and each one can resolve to a different party.

Now a harder one. You sell an AI code-review agent. A retailer buys it through AWS Marketplace, on a private offer their parent holding company negotiated. A contractor on the payments team installs it and points it at four repos. It runs on every pull request, including PRs from engineers in a different subsidiary.

Identity is a contractor who leaves in two months. Entitlement belongs to the payments team. Policy is a spend cap set by a finance group that has never opened the product. Funding is the holding company's committed AWS spend. Contract is the private offer, priced below your list. The invoice comes from AWS, on AWS's cycle, minus AWS's fee.

Six layers, six answers, one record.

Nobody starts there. Most teams shipping agents today could run on one customer record and a token meter and be fine for two years. Then a customer asks why their March invoice says one number and their dashboard says another, and answering means knowing which price was in effect and which principal made the call. No amount of downstream reconciliation recovers an attribution you never recorded.

So two things go in on day one: the principal on the usage event, and a version stamp on pricing inputs. The rest can wait until you have a reason.

Start with the contractor, because the contractor leaves first. The employee model breaks three ways: the employee leaves and the agent keeps running, the agent starts serving teams that employee was never on, or it runs work nobody in particular approved.

A workload identity handles all three. The agent gets its own record, that record points to an accountable owner, and its entitlement and budget come from the workspace or project sponsoring each run. When one agent serves several teams, each invocation carries an explicit billing scope.

The retailer and their holding company are already an account tree. The parent funds a commitment, the subsidiaries draw against it, usage is attributed to the child and settled against the parent. That holds until one subsidiary signs its own contract, bills in another currency, or needs separate tax treatment.

Modeling the money the way HR models the people is expensive to undo, and it is the same mistake as billing the agent to the employee. One level up.

Between the agent's own record and a correct account tree, finance finally has something to put a limit on. They will ask for one and mean three: a rate limit for throughput, a spending cap for consumption over a period, a credit limit for financial exposure. Teams routinely ship one of them and describe it as all three.

Any of the three can live at the key, agent, user, team, workspace or parent level, which is where it gets expensive, so write down precedence and inheritance before it reaches code. What happens when a team is blocked and its parent still has budget? Which limit wins when two apply to the same call?

A cap is worth whatever your balance is worth at the moment you check it. That is where real time stops being one requirement and turns into four.

The last row is the one teams underestimate. An invoice has to be reproducible months later, after a mid-period discount and a refund that landed once the period had closed. The first three can be approximate. That one cannot.

The third row is the expensive one. Twenty agents start work against a $100 remaining balance. A typical run costs $2. A bad one costs $15.

Reserve the worst case and you admit six agents and block fourteen that would have spent about thirty dollars between them. Reserve nothing and a bad afternoon lands at $300 against a $100 balance. Neither number is acceptable, and the gap between them is the whole design problem.

AWS is the honest reference point here. Budget data updates up to three times a day, typically 8 to 12 hours apart, and the documentation says plainly that you can pass your threshold before Budgets notifies you, and keep spending after it does. Budget actions can deny new provisioning, but they fire off that same delayed data, so the enforcement inherits the lag. The largest billing operation in the world ships an alert and is careful to call it an alert.

Reservation also costs two things beyond the blocked runs. It adds latency to every call. And it turns authorization into an availability dependency: if the service answering "may this run" is slow, your product is slow, and when it's down, your product is down. Long-running agents are worse again, because many have no useful maximum cost to reserve against.

Every alternative trades one problem for another. Bounded overshoot means agreeing in advance to some amount of unbilled usage. With queuing you have converted a spend problem into a latency problem, which is sometimes the better problem to have. Downgrade the model and you keep throughput while changing the product your customer is paying for. An overdraft policy lets in-flight work finish and settles afterwards. All four are defensible, none is free, and the choice belongs to whoever owns the customer promise.

The boundary between systems sits at exactly that decision. A monetization platform supplies commercial state: current usage, entitlements, balances, alerts. The application or gateway in the request path does the enforcement. Anything promising to do both from outside the request path is describing a dependency, not a feature.

Lago sits on the commercial-state side of that boundary: it maintains balances and entitlements and emits alerts, while the application or gateway decides whether to throttle, reroute or block a request. That separation is deliberate. Billing can tell you where commercial state stands; synchronous enforcement belongs in the request path.

Reconciling two of your own stores is the easy version. Back to the code-review agent. One pull request produces a usage record in your meter, a rated charge under the private offer terms, a submission to AWS in whatever unit they accept, a line on the retailer's AWS bill, and a revenue entry with a matching receivable. Five records, two companies, and nothing forcing any two of them to agree at a given moment.

The failures are ordinary. A submission times out after you already recorded the usage. A discount takes effect mid-period. A refund gets approved after AWS has closed their period and you have closed yours. Then the retailer disputes a line nobody can reproduce from the original call.

Two things save you here. Pricing inputs versioned across model, feature, metric, tier, channel, currency, effective date and contractual override, so any charge can be recomputed exactly as it was first calculated. And an explicit reconciliation state on every record: matched, pending, rejected, corrected, written off. A record with no state is a record you cannot defend in a dispute.

Commercial terms need the same precision. "The partner receives 20%" cannot be implemented. Twenty percent of list price, net revenue, or collected cash? Before or after credits, refunds, tax and marketplace fees? Measured at event time, invoice time or settlement? A contract becomes operational when those answers exist as versioned rules, which is usually months after the PDF is signed.

Most of this is year-two work. The no-brainers: On day one, all four are schema changes. After the first enterprise contract, they are migrations.