> ## Content Index
> Fetch the complete content index at: https://operators-ai.ghost.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# This week: I taught a live class, then I handed this issue to a different model
- URL: https://operators-ai.ghost.io/live-class-different-model/
- Published: 2026-08-14T13:10:57.000Z
- Updated: 2026-08-14T13:10:57.000Z
- Description: A scheduled agent is not a bound, a click is not a safety program, and a card limit is not a decision record.
- Author: Justin Zsimovan
- Tags: weekly

Sunday I taught our first live session. Friday I handed the first pass of this issue to a different model family on purpose. Both were the same ruling: the expensive resource is judgment, and I spend it on purpose.

## On the bench

The live session ran about forty minutes. I walked the room through the thing I keep repeating in this newsletter: the harness matters more than the model. A good harness compiles identity, rules, memory, tools, and the current case before the model ever sees the problem. Frontier models from the big labs are close enough that shopping among them is usually a usage-cap decision, not a strategy. When the output "forgets" something you already told it, the first four checks are all harness checks: the fact was never saved, the procedure never loaded, the prior session was never searched, or a rule blocked access. The model is the last place I look.

I also said out loud something that has been shifting for me. I used to want one giant all-purpose agent. I don't anymore. Specialized agents with smaller jobs miss fewer triggers. Last week's editorial queue is the lived version of that: a scout, an editor, and a researcher, each with one job, each on a different model family. The output is still a pile of ideas in front of a human.

That queue sat again. Six finished packages were waiting when I sat down to write this. Some I archived. Two of the signals below came out of it. The playbook is the third. Latency waiting on me is still the design, not a defect.

Then I did something that would have sounded like a stunt last year. I handed the first draft of this issue to a different model family than the one that usually writes with me. Last week's playbook said to route by the cost of being wrong, not by how hard the task looks. A first draft of this newsletter is expensive-to-be-wrong on voice and cheap-to-be-wrong on labor. So a different taste got the first pass, and I still own every ruling, including the ones where I cut a paragraph that sounded like a press release. You're reading the working relationship this newsletter teaches.

## The gauges

### A schedule is not a bound

Google's [Managed Agents update](https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api-3-6-flash-hooks/?ref=operators-ai.ghost.io) (July 28, with pricing notes updated August 5) added the thing a lot of operators have been waiting for: persistent scheduled triggers, environment hooks that can allow or deny a tool call before it runs, and a token budget on the interaction. You can even [run a trigger immediately while it is still paused](https://ai.google.dev/gemini-api/docs/antigravity-agent?ref=operators-ai.ghost.io), which is the right primitive for "prove it manually, then turn the cron on."

Should you pay attention? Yes, if you have anything you are tempted to leave running overnight. No, if you read the launch as "Google solved unattended agents."

My position: do not schedule an agent until three things exist, and do not pretend Google shipped all three. First, an aggregate spend ceiling you control outside the vendor's per-run setting. Google's `max_total_tokens` is real, and it is also [per interaction, best-effort, and reset every run](https://ai.google.dev/gemini-api/docs/antigravity-agent?ref=operators-ai.ghost.io). A schedule of twenty runs is twenty fresh budgets. Second, a deny boundary that actually covers the actions that can spend money or talk to a customer. The [hooks documentation](https://ai.google.dev/gemini-api/docs/agent-hooks?ref=operators-ai.ghost.io) is honest about the hole: pre-execution allow/deny only fires for built-in sandbox tools, not custom functions or remote MCP servers, and a hook that crashes or times out fails open. Post-execution hooks cannot undo what already happened. Third, a human-reviewed manual run of the exact scheduled configuration. "Run immediately" is the graduation gate. It is not a ritual you skip because the prompt looked fine.

A token budget is not a spend limit. A hook is not a fence if the business action walks around it. A cron job is just a loop with a nicer name.

### A click is not a safety program

I already told you, in July, that [draft-first-send-second is the design](https://operators-ai.ghost.io/obedient-not-evil/) for anything that talks to a customer or touches money. That line still stands. What is new is the evidence that a stream of routine approve/deny clicks cannot carry that design.

Alex Wauters published [stats from his agent-permissions game](https://scalex.dev/blog/ai-agent-permissions-stats/?ref=operators-ai.ghost.io) on August 5: more than 40,000 plays, more than 409,000 approve/deny decisions, mean accuracy 66.3%. Players missed about one in three planted threats. The worst miss was a familiar wrapper, `npm run analyze`, at 64.7%, even though the malicious payload was visible in the on-screen history. Over-blocking was real too: benign commands got denied 40 to 60 percent of the time. Wauters is upfront that this was a short timed game with an artificial 34% threat density, not a study, and [the Hacker News thread](https://news.ycombinator.com/item?id=49195468&ref=operators-ai.ghost.io) spent a lot of energy arguing that some of the labels were themselves contested. Treat the specific percentages as one operator's instrumented game.

The mechanism does not need the game. Anthropic's own engineering post, [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude?ref=operators-ai.ghost.io) (May 25), reported internal telemetry that users approved roughly 93% of Claude Code permission prompts, and that attentiveness drops as the prompt volume rises. Their design conclusion is the part I want you to steal: contain blast radius at the environment first (sandboxes, egress, credentials that cannot do the damage), then steer the model, and treat human approval as a fallible second line. They also admit their own auto-mode classifier still misses about 17% of overeager risky actions.

Should you pay attention? Yes, if your current "safety program" is you clicking Allow on a long list of similar prompts. No, if you read this as permission to remove review from money, customers, or anything you cannot undo.

My position: I am not walking back July 22\. I am placing it. A human review on an irreversible, high-context decision is the design. A human review on the fiftieth lookalike prompt of the day is a fatigue generator that will eventually approve the one that mattered. Put structure under the routine path (narrow credentials, no send capability, no spend capability, a draft that cannot become a send by clicking the wrong button). Spend the remaining attention on the few decisions that actually need a person: the quote, the purchase, the customer message, the permission change. If the click does not include enough context to make a real judgment, it is not a review. It is a ritual.

### Last week I said no card yet. This week a bank shipped one.

Last Friday I wrote that [the agent-card instruction manual had shown up](https://operators-ai.ghost.io/my-agents-pitched-me/) and that the honest first policy for most small operations was still no card: the agent researches, a person clicks buy. I am not reversing that.

What changed is the product you might actually be offered. [Mercury launched Spend](https://mercury.com/blog/introducing-mercury-spend?ref=operators-ai.ghost.io) on August 11, including dedicated [AI Agent Cards](https://mercury.com/spend-management?ref=operators-ai.ghost.io) with budgets, limits, receipt policies, and guardrails. That is a real bounded card from a bank a lot of operators already use. It is also still a card. A budget tells you what the instrument may spend. It does not, by itself, leave a portable record of the ruling that allowed this exact payment.

Should you pay attention? To Mercury, yes, because this is how the pitch will arrive: "it's a dedicated card, so it's safe." To the playbook below, yes, because the useful question is no longer "can an agent pay?" It is "after it pays, can I retrieve the authority?"

My position: a spending limit is a setting. A checkable per-transaction authorization record is structure. If you cannot pull the purpose, merchant boundary, cap, approver, expiry, and evidence that allowed payment #47, you do not have agent-spend control. You have a thinner company card with a robot's name on it.

## Your move

Ten minutes. This one feeds the playbook.

1. List every place an agent can act without you in the room. Scheduled jobs, auto-drafts that become sends, auto-buys, auto-posts, overnight research that writes somewhere permanent. One line each.
2. Next to each line, write what actually stops a bad run. A spend ceiling you can prove. A credential that cannot do the damage. A human review of a specific irreversible decision. Or "hope."
3. Circle two kinds of lie: a per-run token budget standing in for a spend limit, and a routine approve/deny click standing in for a review.
4. For anything that can spend money, add one more column: after a payment, could you retrieve the ruling that allowed that exact charge? Yes, no, or "there has never been a payment."

Most operators find at least one circled lie. That is the line you fix this week, not the whole list.

## The meme

![Drake meme: rejecting a schedule plus a click plus a card limit, approving a bound plus a decision plus a receipt of authority](https://storage.ghost.io/c/6f/e7/6fe775a0-dff8-49ae-9628-ec858b8ecd0e/content/images/2026/08/2026-08-14-looks-like-control.png)

A cron job, an Allow button, and a spending cap can all sit in a dashboard and still leave the damaging action possible.

## The playbook: a card is a limit, not a decision record

Operators: last week's playbook was a routing audit. This one is the spend-authority sibling. Same shape. Inventory, a rule, a test, a rollback, and a prompt you can hand your agent. The trigger is Mercury shipping a dedicated agent card. The durable asset is a ruling ledger for money that outlives any one vendor.

Don't buy Mercury because I mentioned it, and don't try to stand up the AWS preview stack in a five-person shop. What you want is a test any vendor has to pass, including a bank you already use, before an agent is allowed to settle a charge.

### 1\. Two models, keep them separate

**Bounded card.** A dedicated instrument with a budget, a merchant category list, a velocity rule, and a revoke button. Mercury Spend's AI Agent Cards are a live example of this pole. [Their own product page](https://mercury.com/spend-management?ref=operators-ai.ghost.io) talks budgets, limits, receipt policies, and guardrails. That is useful. It answers "how much can this instrument spend, and where?" It does not, from public materials, answer "why was this exact payment allowed, under which still-valid ruling, in a record I can export?"

**Proofable authorization.** A payment cannot settle unless a still-valid decision says it may, and that decision leaves an artifact you can retrieve later: purpose, policy, approver, expiry, evidence. The closest public writeup is the [AWS / Solv Labs / ICME case study](https://aws.amazon.com/blogs/machine-learning/pay-with-confidence-how-solv-labs-built-verifiable-auditable-agent-payments-on-amazon-bedrock-agentcore-payments/?ref=operators-ai.ghost.io) on preview [AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments.html?ref=operators-ai.ghost.io): pre-authorization before settlement, a signed per-payment evidence record, policy-check proof, enclave attestation. They report the flow under four seconds. Treat that as a picture of the pole, not a shopping list. It is preview software, co-written by the vendors, and not independently verified in production at small-business scale. The [AP2 authorization spec](https://ap2-protocol.org/ap2/agent%5Fauthorization/?ref=operators-ai.ghost.io) is the vocabulary version of the same idea.

A perfect evidence record proves the payment cleared its policy. It does not prove the policy, the merchant, or the business decision was wise. Judgment still sits with you. The ledger just makes the judgment findable.

### 2\. The operator rule

**No decision, no settlement.**

In practice:

- The agent may research, compare, and assemble a purchase packet.
- Settlement requires a ruling that is still inside its expiry, still inside its cap, still inside its merchant/category boundary, and still attributable to a named approver (you, unless you have deliberately delegated a class of purchase).
- After settlement, you can retrieve that ruling and the payment together without asking the vendor's dashboard to "trust us."
- If any of those are missing, the payment fails closed. Missing is revoked, not "recreate it."

If you cannot implement the third bullet with a vendor today, you do not give that vendor's card to an agent. You keep the first-policy from last week: the agent prepares, a person pays.

### 3\. The ruling ledger (one row per allowed purchase class)

Do this in a spreadsheet or a dated note. Five columns, no more:

| Field             | What you write                                                       | Fail condition                                 |
| ----------------- | -------------------------------------------------------------------- | ---------------------------------------------- |
| Purpose           | The only job this money is for. One sentence.                        | "misc" / "supplies" / "whatever it needs"      |
| Boundary          | Named merchant, or a tight category plus a named ban-list            | "online" / "SaaS" / "ads"                      |
| Cap               | A number and a window. $X per charge, $Y per day, $Z per month       | A per-run token budget standing in for dollars |
| Approver + expiry | Who said yes, and the timestamp when yes dies                        | Open-ended, or "the agent can renew it"        |
| Evidence link     | Where the packet lives: quote, screenshot, SKU list, why-this-vendor | "it's in the chat"                             |

One row per class, not per charge, until a class has earned a standing rule. A standing rule still expires. I like 24 hours for the first ones and 7 days only after a class has run clean.

This is the same discipline as the send authorizations I have talked about in here before. Absence means no. A missing row is not an invitation to improvise.

### 4\. The vendor test (run before you issue any agent card)

Hand this to whoever is selling you the card, including your current bank:

1. Show me a dedicated instrument that cannot fall back to my personal or operating card if the agent card is declined or missing.
2. Show me the cap that stops the schedule, not the run. If twenty scheduled purchases each have a $50 cap, what stops the twenty-first?
3. After a test payment of $1, retrieve with me: the ruling, the approver, the expiry, the policy that passed, and the receipt. If any of those only exist as a screenshot of their UI, write down "not portable."
4. Revoke the instrument in front of you and confirm a second $1 attempt fails. Time it.
5. Ask what happens when their policy engine is down. Fail-open is a no.

You are not looking for a perfect score. You are looking for an honest map. Mercury, today, should clear (1) and parts of (2) if you set budgets carefully, and should be presumed weak on (3) until they show you an exportable authority receipt. The AWS/Solv writeup is the picture of a strong (3). It is not a product you can turn on Monday.

Do not cite horror stories you cannot source. I looked. The circulating "41 charges just under the cap" anecdote is an unattributed hypothetical, not a documented incident. You do not need a ghost story. The missing receipt is the finding.

### 5\. Acceptance test and kill condition

Before any agent is allowed to settle:

1. Create one ledger row for a real, boring, repeating purchase (the same vendor, the same SKU class, a small cap).
2. Have the agent assemble the packet only. You settle the first three by hand, against the row.
3. Only then issue a dedicated instrument scoped to that row, with an expiry measured in hours, not months.
4. After each of the next three settlements, retrieve the ruling and the receipt together. If you cannot, revoke the same day.
5. Kill the whole class if any of these fire: a charge outside the boundary, a charge after expiry, a charge you cannot pair with a ruling, or a second instrument appearing because the first one failed.

### 6\. What not to build

- Do not share your operating card, virtual or physical, with an agent. Dedicated or nothing.
- Do not build a classifier that decides, per cart, whether this purchase is "safe enough." You will debug the classifier more than it saves, and your acceptance story will collapse.
- Do not implement the AWS/Solv enclave stack as a weekend project. It is a picture of a pole, not a starter kit.
- Do not treat a receipt policy ("upload the PDF") as proof of authority. That is proof of purchase. Different document.
- Do not let a preview feature, an unbilled compute period, or a launch blog post move money.

### 7\. Hand it to your agent

Copy this to the agent that helps run your operation:

```text
Build and maintain a spend-authority ledger for any purchase an
agent might initiate.

1. Inventory: list every current or proposed agent path that could
   cause a charge, a subscription, or a vendor account to be created.
   For each, record: purpose, merchant or category boundary, dollar
   cap and window, named approver, expiry, and where the evidence
   packet will live. Missing fields are a fail, not a draft.

2. Default policy: agents research and assemble packets. They do
   not settle. A dedicated payment instrument is issued only for a
   ledger row that has already had three human-settled examples, and
   only with an expiry measured in hours until the class has run
   clean.

3. Vendor test: before recommending any agent card (including one
   from a bank we already use), run this five-question test and
   record the answers verbatim: dedicated instrument with no fallback
   to the operating card; cap that stops the schedule not just the
   run; retrieve ruling + approver + expiry + policy + receipt after
   a $1 test; revoke and confirm a second attempt fails; behavior
   when the policy engine is down. Do not recommend a vendor that
   fails the retrieve test.

4. Acceptance: after any instrument is issued, pair every settlement
   with its ledger row. If a settlement cannot be paired the same
   day, revoke and report.

5. Kill: recommend immediate revoke if a charge lands outside
   boundary, after expiry, unpaired to a ruling, or on a fallback
   instrument.

Propose ledger rows to me. Do not issue cards, store card numbers,
talk to a bank, or settle anything. Do not invent incidents. If you
cannot find a primary source for a risk story, say you could not
find it.

```

The last paragraph is the part most people skip. The ledger is the agent's job. The settlement decision is yours. Same division of labor as the editorial queue, and as last week's routing audit.

**Steal this:** pick the single most tempting agent purchase in your operation. Write the five ledger fields for it today. If you cannot fill them, the agent does not get a card, dedicated or otherwise. If you can fill them, settle the next one yourself and keep the packet. That is the whole playbook at the size of one charge.

---

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

— Justin