This week: the agent did the hours. What do you charge?

Every issue since July has been about what AI does to the work. This one is about what it does to the number at the bottom of the invoice, because this week it came for mine.

On the bench

A consulting engagement I am delivering was sold the way consulting has been sold for forty years: a budget of senior engineer hours, at an hourly rate, against a list of deliverables. Time and materials. The customer bought hours because hours are what the industry knows how to buy.

Here is the problem. I do not deliver those deliverables in anything like the hours that were budgeted anymore. My agent drafts the architecture diagram from the discovery notes. It builds the first pass of the system-of-record matrix from the interview transcripts. It writes the status report. I review, correct, decide, and own the result, and the wall clock says the deliverable took a fraction of what it took me in 2023. If I bill the clock, I get paid a fraction of what the work is worth, and the customer gets the same deliverable, from the same senior engineer, for less than they agreed to pay. Nobody asked for that discount. The billing model just assumes the tool in my hand is a keyboard.

I spent part of this week working that out with the partner I contract through, and the answer we landed on is worth writing down, because I think a lot of you are about to hit it. We bill imputed value against deliverable progress, not keyboard time. The hours on the invoice reflect the senior engineer value of the deliverable produced, which is the number the engagement was sold on and the number the customer agreed was fair. The evidence of work is the deliverable and the weekly status report, not a stopwatch. That is a defensible position under a time and materials contract, and it is the honest one, because the customer is buying my judgment about their architecture, and the judgment is not faster because the typing is.

Two mechanics make it work instead of turning into an argument every month. First, the budget is allocated across the deliverables up front, so "percent complete" is a real number each Friday instead of a feeling. Second, I keep a private column beside the billed one: the keyboard hours it took. That gap is the most important number in the business right now, and I am not hiding it from myself. It is what a fixed-fee price would be built on, if and when this industry gets there.

One more decision, and it is the one I would tell you to copy. We are going to come in a bit under budget on purpose. Not far. Call it ten percent. When you can predict your delivery cost and the customer cannot, the temptation is to bill the full budget every time. The relationship is worth more than the last ten percent, and a customer who sees you finish under is a customer who calls again. The agent made that generosity affordable. The decision to spend it was mine.

The gauges

One of our founding members is testing an AI repricer against his own books, before he buys the seat

What I saw: one of our founding members runs a large Amazon retail arbitrage operation, eight figures a year in sales. Last Friday he told the community he is completely retooling his repricing, with AI as part of the analysis, and testing SellerSnap's new AI repricer as part of the strategy. Two days later he showed the workbench. He is running ScanPower's MCP integration in Claude on his phone, pulling in Amazon's Unified Transaction Report to calculate sales, then cross-referencing that against the SellerSnap API to come up with repricing strategies and tests. When someone asked what the flow was for, his answer was that he is pulling his buylist and linking each source to its orders and returns, and that there is a lot more in the API than the prep-and-ship workflow it was sold for.

The pieces are real and independently documented. ScanPower's co-founder open-sourced the harness that connects their MCP and API to physical scanning and printing. SellerSnap announced a new repricing engine the same week, optimizing for net ROI rather than raw Buy Box share. Amazon's transaction and settlement reports are the documented building blocks. What I want you to notice is the shape: the report he already trusts, from the system that already holds his money, pulled into a model, cross-referenced against the vendor's API, to design tests. Not "does the AI repricer seem smart." Tests.

Should you pay attention? Yes, and the reason is the order of operations. Every vendor you already pay is shipping an "AI" feature this quarter, usually as a new seat or a new tier. The reflex is to turn it on and see how it feels. His move is to wire the trusted export to a model first, formulate the strategy and the test himself, and then evaluate the vendor's feature against that. The vendor has to earn the seat against a test the operator designed, on the operator's own data. I should be clear about what he has and has not shared: the setup and the intent. No result yet, no buy or no-buy call. That is fine. The discipline is visible before the outcome is.

My position: pick one money decision in your business. Price, buying, or returns. Take the export you already trust from your system of record, hand it to a model, and ask for a strategy and a test you could actually run. Do that before you turn on the vendor's AI feature, because afterward you will not be able to tell whether the feature is good or whether you just wanted it to be.

Last week the price list. This week, the line that reprices the whole request

What I saw: last week I gave you the table: GPT-6 Astra at $10 in and $50 out per million tokens. The table did not show this sentence from OpenAI's own model page: "Prompts with more than 272K input tokens are priced at 2x input and cache rates and 1.5x output for the full request." Read "full request" twice. It is not an overage on the tokens above the line. Cross 272K by one token and the whole request bills at $20 in and $75 out. Astra's context window is about a million tokens, so the model will happily accept the request. The pricing page will happily double it.

Do the arithmetic once. A 270K-token request with a 5,000-token answer costs about $2.95 on Astra. A 300K request with the same answer costs about $6.38. Thirty thousand extra tokens more than doubled the bill. And here is the part the launch coverage missed: this is not new and it is not Astra's. The identical clause is on the GPT-5.6 Sol page and its siblings, and an archived copy of the Sol page from July 27 already carried it, five weeks before Astra existed. What changed on September 3 is that the same guardrail now sits under a model that costs two and a half times more, so crossing it costs two and a half times more. The most thorough treatment I found is AI Pricing Guru's, written for technical buyers with a cost estimator; if you have a developer, send it to them.

Should you pay attention? Yes, if anything in your business stuffs whole documents, whole email threads, or whole databases into a prompt. That is exactly the kind of job operators route to the flagship, because it is the "big important" one. A contract review with all the exhibits attached. A month of support tickets. A full product catalog. Those are the requests that live near 272K, and they are the ones nobody counts because the model accepted them without complaint.

My position: the number that matters is 272K, not the million on the spec sheet. In August I gave you the routing label: route by what it costs when the model is wrong. Add one line to the same audit: can this job cross 272K input tokens? If yes, either split it or route it somewhere the cliff is cheaper, and log every crossing. A vendor's context window is a capability. The billing line is the price.

The backup was on the same volume the agent could reach

What I saw: in April, an AI coding agent working for a startup called PocketOS deleted its production database. It took nine seconds. The story recirculated hard two weeks ago, mostly as a "don't let the agent touch production" morality tale, which is the least useful reading of it. The useful reading is in Business Insider's account and a legal-technical analysis that followed: the routine backups were on the same volume the agent's command could reach, so they went with the database. What saved the company was that the hosting provider kept a deeper disaster backup layer the agent could not reach, and its CEO said on the record that they recovered the data from it.

Two clocks are worth separating. The technical restore took on the order of thirty minutes once the deeper backup was found. Reconstructing customer records and making the business whole took on the order of thirty hours. The provider's disaster tier saved the data. Nothing saved the day.

Should you pay attention? Yes, and not because you run a startup. Because most small businesses have exactly one recovery copy, and they have never asked where it lives relative to the credentials their tools hold. In July I told you to give the agent minimum access. This is a different question, and a harder one: if the access you granted fails anyway, does the copy you would restore from survive that failure? A backup that shares the failure domain of the thing it backs up is a copy, not a recovery plan.

My position: run one test this week, no tooling required. List every credential your agents and automations can use. For each, ask whether that credential, misused, could reach the only copy you would restore the business from. If the answer is yes for any of them, the copy is not your backup; it is another thing that will be gone. And do not confuse your vendor's disaster tier with your plan. PocketOS was lucky theirs existed. Find out whether yours does, and whether anyone has ever restored from it.

Your move

Ten minutes, and it works whether the thing under test is a vendor's new AI feature, a model change, or a new agent workflow.

Our member's setup works because the test comes before the verdict. Most AI trials in small businesses end the other way: the trial ends, everyone agrees it "seemed to help," and the seat gets renewed. Fix that before the next trial starts.

1. (2 min) Name the one money decision the trial is supposed to improve. Price, buy, return, quote, collect. One. If the vendor's feature touches several, you are testing one of them, and you pick which.
2. (3 min) Write the metric in one line, in units of money or time, from a report you already trust. "Net margin per unit sold on the 40 SKUs in this list, from the settlement report." Not "better pricing."
3. (2 min) Write the comparison. Same metric, same report, either the four weeks before the trial or a set of items the trial does not touch. Without this you are measuring the season, not the tool.
4. (2 min) Write the window and the threshold. "Four weeks. Keep the seat if the metric improves by at least X against the comparison; otherwise cancel." Sign it, date it, put it where you will find it when the renewal email arrives.
5. (1 min) Add the two questions from the gauges: can this job cross 272K tokens on the flagship, and can the credentials involved reach your only backup. If either is yes, that is a finding before the trial starts.

The whole thing fits on an index card. The card is the product. The vendor's dashboard will tell you the feature is working; the card tells you whether it was worth paying for.

The meme

The bench this week, as a four-panel comic. The agent is not the problem in panel three. The billing model is.

The playbook: the deliverable ledger

Operators: the bench told you the decision. This is the working file, generalized so it fits a consultant, an agency, a bookkeeper, a designer, or a trades business quoting jobs. If you sell your time in any form and an agent now does part of the work, you need this before your next invoice, not after.

The idea

Time and materials billing assumes the clock measures the value. It never really did, but for forty years the clock was close enough, because a senior person's hour produced roughly a senior person's worth of output. That link broke this year. The honest replacement is not "bill fewer hours" and it is not "bill the old hours and hope nobody asks." It is a ledger that books value against deliverables, keeps the real cost beside it privately, and gives you the numbers to move to fixed fee when your customers are ready.

Four parts: the allocation, the weekly booking, the private column, and the shadow price.

1. The allocation

Before the work starts, split the sold budget across the deliverables in the contract. Not evenly. By judgment: how much senior thinking each one actually takes. The design bundle gets the most; the recommendation memo whose decision tree you already own gets the least. Write the split down. This is your internal document; the customer never sees it and does not need to.

The allocation does two jobs. It turns "percent complete" into arithmetic each week, and it forces you to notice, up front, which deliverables the agent will crush and which ones are all you. Those are different lines in the ledger and they should be, because the second kind is where your margin comes from and the first kind is where your margin leaks if you bill the clock.

A rule from my own file: if a deliverable is more than three quarters agent output with your review, that is a signal to allocate it less, not to bill it less. Allocation is about value delivered. The review and the accountability are the value; the agent produced the draft.

2. The weekly booking

Every Friday, one row per engagement: what got booked this week, cumulative, remaining, deliverables touched, and a decision column. Booked hours equal the allocation multiplied by the progress on each deliverable touched. If the architecture diagram was allocated twenty percent of the budget and it went from zero to half done, you book ten percent of the budget this week. That is the number that goes on the invoice and into the customer's time system if they have one. It is defensible to anyone who reads the contract, because the contract sold deliverables at a budget, and you are billing the deliverables against the budget.

The status report you owe the customer anyway carries the evidence: what was completed, what is at risk, hours consumed and remaining. Those two documents together are the timesheet. Nobody reconciles anything against a clock, ever, because no clock was ever the basis.

3. The private column

Beside "booked," a column nobody sees: keyboard hours. Yours, actual, honest, including the review time and the time you spent arguing with the agent about its first draft. Track it weekly with the same discipline as the booked number.

This column is the single most important number in your business right now, and I would guess most operators reading this do not know theirs within a factor of two. It tells you your real margin per engagement. It tells you which deliverable types the agent has changed and which it has not. And over three or four engagements, it tells you something no vendor and no consultant can: your delivery cost has become predictable. That is the precondition for the next section.

Do not let this column leak into the customer conversation. It is not a confession; it is cost accounting. A furniture maker does not itemize the table saw.

4. The shadow price

For every engagement billed this way, keep a short block at the bottom, filled in at close:

• What this deliverable set would have been priced at as a fixed fee.
• What it actually cost to deliver: your keyboard hours at your rate, plus tooling.
• Margin under the imputed T&M billing versus margin at that fixed fee.
• What made the estimate predictable this time.

You are not using this to bill anyone. You are building the case, with your own real numbers, for the day the customer or the partner says "what would fixed fee look like?" The reason most service businesses cannot move to fixed fee is that they cannot estimate. T&M lets them sell before they can. After three engagements with a private column, you can estimate, and you can prove it with a page instead of a theory. That page is the difference between asking for fixed fee and being offered it.

The under-budget rule

Decide the target before the first Friday: finish a bit under the sold budget, and put a number on "a bit." Mine is around ten percent. Adjust it week by week as the booking accumulates, but do not let it drift to zero because the budget was there. When your cost is predictable and the customer's expectation is not, the last ten percent is a choice about the relationship, and the relationship is worth more than the last ten percent. The agent made that generosity cheap. Spend it deliberately.

Translating it

An agency selling a website: allocate the scope across discovery, design, build, launch; book against milestones; private column is your team's real hours now that the agent writes the first draft of everything. A bookkeeper on a monthly retainer: the deliverables are the close, the reconciliation, the report; the retainer was priced on the hours those took in 2023; your private column tells you what they take now, and your shadow price tells you whether the retainer should go up, hold, or be repackaged. A trades business quoting a job: you already bill the deliverable, but your quote was built on labor hours that your estimating agent is now compressing; the private column is estimating hours per quote, and the shadow price is your new quote floor.

The honest costs

The allocation takes an hour per engagement, once. The Friday row takes ten minutes. The private column costs you the discomfort of seeing how few keyboard hours some deliverables take now, and the discipline not to react to that number by cutting your price. And there is a real risk to name: a customer with a strict time-system culture may ask for clock hours. Have the answer ready before they ask: the contract sold deliverables at a budget, the status report shows the progress, and the booked hours are the agreed value of that progress. If the customer wants to renegotiate to a clock, that is a pricing conversation, and you now have the numbers to have it.

Steal this: this weekend, take your current engagement or your biggest retainer and write the allocation: the sold budget split across its deliverables. Then add one private column and back-fill last week's keyboard hours from memory. You will have the two numbers, value and cost, side by side for the first time. Everything else in this playbook is just keeping them up to date.

Hit reply and tell me what's on your bench this week. I read every one.