This week: AI got cheaper, found its memory, and reached for the company card

Three stories crowded the AI feed this week. A capable model got dramatically cheaper. A startup launched a shared memory for whole companies. Payment companies gave agents a way to create controlled virtual cards and complete real purchases.

Together, they put agents closer to the parts of a business where mistakes stop being funny. They are cheaper to run, better informed, and gaining real authority.

On Wednesday I published a piece about the opposite end of that spectrum: boring old automation quietly reversing decisions humans made on purpose. This issue is about what happens when that bug gets a bigger engine.

On the bench

If you read Wednesday's piece, you know the short version: an hourly HR sync kept re-enabling an account IT had urgently disabled, and a routine refresh in one of my own systems resurrected a contact I had explicitly ruled out as spam. If you missed it, start there. It is free and it is the setup for everything below.

What I have been sitting with since publishing it is the timing.

The same week I watched a dumb hourly sync erase a human decision, the industry announced cheaper agent-capable models, shared company memory as a product, and payment rails that let an agent hold a card. Every one of those moves gives automation more reach. None of them fixes the blindness I wrote about on Wednesday. A sync that cannot tell stale data from a human ruling does limited damage when all it touches is a directory. Give that same blindness a memory of every decision your company ever made and a way to spend money, and the mistake stops being a cleanup task. It becomes a wrong purchase, a contacted customer who opted out, or an account that will not stay disabled.

Wednesday's piece told you how to catch the bug with a ten-minute test. It deliberately stopped short of the durable fix, because that fix deserves a full spec, not a paragraph. That spec is this week's playbook: the ruling ledger, written so you can hand it to your agent and have it built properly.

The gauges

The price floor moved again

On Thursday, OpenAI announced on X that it cut the price of GPT-5.6 Luna by 80% and Terra by 20%. The company's pricing note says Luna can now handle tool use and multi-step work at $0.20 per million input tokens and $1.20 per million output tokens. It also moved its automatic review feature to Luna and expects that work to cost about ten times less.

Should you pay attention? Yes, if you run anything repeatedly. Customer-message classification, document sorting, product cleanup, quote intake, review passes, and background research all get more interesting when the cheap model can use tools instead of only filling in a template.

My position: do not spend Friday ripping out a model that works because a chart moved. Pick one frequent, low-risk workflow where cost forced you to cut corners. Run the same evaluation against the cheaper model. If quality holds, move that lane and keep the savings. Model routing is becoming ordinary operating discipline, not an engineering parlor trick.

The useful question is no longer "what is the smartest model?" It is "what is the cheapest model that clears this job's acceptance test?"

The company brain became a product category

Supermemory launched what it calls a company brain: a shared memory that lives in Slack, learns from company conversations and connected tools, answers questions, and can act through those tools. The launch drew serious attention on X because almost every team has the same mess. Decisions live in Slack, documents, email, somebody's head, and the ticket nobody updated.

Then Punit Arani asked the better question: "Who's building the company hands?" A brain that can recall every decision but cannot do anything is a better search box. Hands without memory are worse. They act without knowing what the business already decided.

Should you pay attention? Yes. Shared context is moving from custom infrastructure into a product you can invite to Slack. That is a real shift for small teams that cannot spend six months building an internal knowledge platform.

My position: do not buy a company brain because the demo remembers an old conversation. Before connecting it, name one recurring action it should improve and one fact it must never expose to the wrong person. Then test both. Retrieval quality gets the demo. Permissions and correction behavior decide whether it belongs in your business.

And ask what happens when the brain is wrong. "It remembers everything" is marketing. "Here is how a person corrects a bad memory, and here is every action that used it" is an operating system.

The agent has a card now

Corpay announced Agent Card, which lets an AI agent generate a controlled virtual card for an approved business transaction. Days earlier, Visa and Lianlian announced a live B2B agentic transaction. Their agent identified a purchasing need, compared suppliers, placed an order, and completed payment inside predefined controls.

That is not a speculative demo about what agents may do someday. The payment rails are arriving now.

Should you pay attention? Absolutely, even if you would not let an agent spend one dollar today. Procurement, software renewals, ad budgets, supplies, and vendor payments are all full of repetitive decisions. The time savings are real. So is the blast radius.

My position: creating the card is straightforward compared with governing it. The controls around the card will decide whether this is useful or reckless. What can the agent buy? From whom? Under what amount? Which purchase needs approval? What happens when the preferred vendor is out of stock? Can a human decision to block a vendor survive tomorrow's catalog refresh?

For most small businesses, the sane first version is simple: let the agent assemble the purchase, show its evidence, and prepare the payment. A person approves the money. Expand authority only after the system produces clean receipts and survives exception tests. "It stayed under the limit" is not proof it made a good decision.

Your move

Wednesday's audit told you how to find out whether your syncs respect your decisions. This week, build the inventory that the fix depends on. Fifteen minutes.

1. Open a blank page and list every decision in your business that must never be silently reversed by software. Not tasks. Decisions. Think in categories: who we never contact, which accounts stay off, which vendors we refuse, which prices only an owner changes, which customer promises we keep no matter what a feed says.
2. For each category, write who is allowed to make that ruling and who is allowed to reverse it. One name or one role per line. If the honest answer is "whoever edits the record," that category is unprotected.
3. Circle the three categories where a silent reversal costs the most: money, a customer relationship, or access to your systems.
4. For those three, write down where that decision currently lives. A field in the CRM? A checkbox? Somebody's memory? That location is what your automation would need to check before acting, and today it almost certainly does not.

That list is not busywork. It is the ruling-type catalog for the ledger in this week's playbook. The audit told you whether you have the bug. The inventory tells you exactly what the fix has to protect first.

The meme

The card is not the scary part. "Nobody needs to review this" is.

The playbook: build a human-ruling ledger

Operators: Wednesday's piece ended with "fix the class, not the record." This is the class fix, in full. It is not another line in a prompt telling the agent to respect human decisions. It is a durable place where those decisions live, plus a rule that every sync and agent must check before acting.

I call it a human-ruling ledger. The name is plain because the job is plain: when a person has deliberately decided something, automation can read that decision but cannot quietly erase it.

You can add this to a custom system, ask a vendor to support the pattern, or build a lightweight version in a database or spreadsheet. The database can be simple. The precedence rules cannot.

1. Separate facts from rulings

A fact describes the world as a source currently sees it:

• HR says the employee is active.
• The supplier feed says the product is available.
• The CRM says the contact is eligible.
• The calendar says the slot is open.

A ruling describes what the business decided to do:

• Keep this account disabled pending review.
• Never contact this person.
• Do not buy from this vendor.
• Hold this slot for the customer until noon.

Do not store those as competing values in the same field. If active = true can overwrite disabled = true, the newest write wins even when the older write carries more authority. Facts can refresh automatically. Rulings require an explicit superseding decision.

2. Use the smallest ledger that can prove authority

Start with these fields:

{
  "ruling_id": "rul_01J...",
  "entity_type": "contact",
  "entity_id": "crm_48291",
  "ruling_type": "do_not_contact",
  "value": true,
  "status": "active",
  "decided_by": "user_justin",
  "decided_at": "2026-07-31T15:20:00Z",
  "reason": "Reviewed as spam",
  "source": "manual_review",
  "supersedes": null,
  "expires_at": null
}

The required pieces are the stable entity ID, the ruling type, who made it, when they made it, and whether it is still active. A free-text reason is useful. supersedes gives you a chain instead of an edited history. expires_at is optional and should be empty by default. A customer opt-out should not expire because somebody forgot to renew it.

Do not identify records by display name or email alone. Names change, addresses get reused, and duplicate contacts happen. Resolve the ruling to the same stable ID your automation uses before it acts. If identity is ambiguous, stop for review rather than guessing.

3. Write precedence before code

Use this order unless your domain requires something stricter:

1. Legal, safety, privacy, and customer-consent blocks.
2. Active human rulings.
3. Provider-enforced limits and approval requirements.
4. Current source-system facts.
5. Agent recommendations.
6. Default behavior.

Higher rows can block lower rows. Lower rows never erase higher rows.

That means a fresh supplier catalog can update price and availability, but it cannot reactivate a vendor a person blocked. A new CRM import can update the contact's company, but it cannot remove a do-not-contact ruling. A model can recommend a purchase, but it cannot override the approved-vendor list because its alternative scored better.

When a ruling must change, write a new ruling that points to the old one in supersedes. Never silently mutate the old row. You want a history you can explain after the fact.

4. Put the check at the last responsible moment

Checking the ledger when a workflow starts is not enough. The world can change between research and action.

Check immediately before the irreversible step:

load proposed action
resolve stable entity IDs
load active rulings for those entities and this action type
apply precedence rules
validate amount, destination, consent, access, and required fields
if any check fails: stop and create a review item
if approval is required: show proposal and evidence, then wait
execute once
write a receipt with the ruling IDs and source records used

For customer communication, check before sending, not when drafting. For money, check before creating or releasing the payment, not when comparing vendors. For access, check before enabling the account, not when the HR sync begins.

A long-running agent should re-check after every pause or handoff. Yesterday's approval is not automatically approval for today's changed order.

5. Make every action leave a receipt

A useful receipt answers six questions:

• What triggered the run?
• Which source records did it read?
• Which rulings did it find?
• What did it propose?
• Who or what approved it?
• What happened when it acted?

Store the exact ruling IDs, not a sentence saying "policy checked." If a customer asks why they were contacted, you should be able to show the consent state and active rulings the system saw at send time. If an agent buys the wrong item, you should know whether it violated a ruling, missed one, or followed a bad rule correctly.

Receipts are also how authority expands safely. Ten clean runs with complete evidence tell you something. Ten runs where nobody complained tell you almost nothing.

6. Fail closed without hiding the work

If the ruling store is unavailable, the protected action stops. It does not assume there are no rulings. "Could not check" and "no blocking ruling exists" are different states.

The agent should still preserve its useful work. Save the draft message, vendor comparison, proposed order, or account change as a review item. Then tell the operator exactly why execution stopped.

Use this failure response:

{
  "status": "needs_review",
  "action": "send_customer_message",
  "reason": "ruling_check_unavailable",
  "proposal_saved": true,
  "safe_to_retry": true
}

Do not bury the exception in a log. Put it where the owner already reviews work. A system that fails safely but nobody can hear is still broken.

7. Give your agent this implementation brief

Copy this into the agent that maintains your automation:

Add a durable human-ruling ledger to this workflow.

A human ruling is a deliberate decision that automated imports, syncs,
models, and source refreshes may read but may not overwrite. Keep source
facts separate from rulings. Resolve every ruling to a stable entity ID.

Before any customer communication, payment, access change, deletion, price
change, or other irreversible action:
1. Load active rulings for the affected entities and action type.
2. Apply this precedence: legal/safety/consent blocks, human rulings,
   provider controls, source facts, model recommendations, defaults.
3. Stop on missing identity, conflicting rulings, unavailable ruling storage,
   failed validation, or missing approval.
4. Save the proposed work for review rather than discarding it.
5. Re-check rulings immediately before execution.
6. Execute idempotently so a retry cannot duplicate the action.
7. Write a receipt containing the trigger, source record versions, ruling IDs,
   proposal, approval, action result, and timestamp.

Never edit an old ruling to reverse it. Write a new ruling with a supersedes
reference. Rulings do not expire unless expires_at was explicitly set.
Provide a migration plan, tests, rollback plan, and an operator view for
active rulings and stopped actions. Do not connect new live credentials or
activate customer-facing actions during implementation.

That last sentence matters. Your agent can build and test the mechanism without granting itself the authority the mechanism is meant to control.

8. Do not ship until these tests pass

Use test records and sandbox actions.

1. Resurrected contact: mark a contact do-not-contact, run a full import, and prove the contact remains blocked.
2. Disabled account: disable a test account, run the upstream sync with the person still marked active, and prove the account stays disabled.
3. Blocked vendor: block a vendor, refresh the catalog with that vendor offering the best price, and prove the agent excludes it.
4. Changed proposal: approve a purchase, change the quantity or vendor, and prove the old approval no longer authorizes execution.
5. Ledger outage: make the ruling store unavailable and prove the action stops while the proposal survives for review.
6. Duplicate retry: replay the same event twice and prove only one message, payment, or record change occurs.
7. Explicit reversal: write a new ruling that supersedes the old one and prove the history remains intact.
8. Receipt proof: pick any completed action and reconstruct why it happened from stored evidence without reading application logs.

If a vendor tool cannot pass these tests, stop treating it as a configuration project. It may be missing a capability you need.

9. Keep the operating habit boring

Once a month, review active rulings with an owner:

• stale temporary holds
• conflicting decisions
• records that no longer resolve cleanly
• repeated stops that point to a bad workflow
• actions with missing receipts

Do not measure success by how many times the agent acted. Measure clean execution, clean stops, time waiting for review, and reversals caught before action.

The aim is visible authority, not a business frozen under a pile of approvals. Low-risk, reversible work can move fast. Customer trust, access, money, and permanent records earn a slower lane until the evidence says otherwise.

Steal this: pick one human decision your automation has reversed before. Put that class of decision in a durable ledger, make every relevant workflow check it at the last responsible moment, and refuse the action when the check cannot complete. Once that works, you have something worth connecting to better memory and cheaper models.

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

— Justin