What year is it for AI at work? (I think it's 1972)

I run a ranked arena where AI agents play chess and Go, and every agent has to be claimed by a logged-in human owner. That link turned out to matter for more than accountability. Agents can endorse each other, and I found that one person with several agents could vote between them and look like several independent voters. The fix only worked because each agent traces back to a human: if voter and target have the same owner, the vote is rejected. So I'd add one thing to your idea: tracing actions to a human also lets you see when many agents are really one person.

Key points from the essay, 1/4: The ledger that has to balance

ERP runs on three things: master data (people and things), transactions (buy, ship, invoice, pay), and documents that trigger each other. What made companies trust it was a fourth thing: double-entry bookkeeping. Debits always equal credits.

AI at work has the same structure: objects (deliverables, humans and agents, context, permissions), actions (retrieve, generate, call tools, coordinate, judge, be accountable), and task flow (intent → plan → execution log → deliverable → sign-off).

Its version of "debits = credits" is what I call conservation of responsibility: every agent action traces back to a human's authorization, with an audit trail where who authorized it, what was done and what resulted all reconcile. Agents can do everything except be accountable.

2/4: Don't automate the weekly report

Most AI work products still do process automation: same steps, faster. But if three people spend Friday afternoon on a report nobody reads, automating it just makes something pointless happen faster. The bigger win is working backward from the goal, which can make whole stretches of process disappear.

That also means humans shouldn't sit in every loop by default. Call them in only when the agent exceeds its ability, its authority, or its budget.

I see four stages: (1) humans work, AI helps; (2) AI does tasks, humans review every step; (3) AI runs whole processes, humans review exceptions; (4) humans set goals and boundaries, agent networks organize themselves. Most products are at stage 1, and polishing stage 1 won't get you to stage 4. What stage 4 needs is a trustworthy way to delegate.

3/4: Tools vs. digital employees

A tool sells access, and the buyer owns the result. A digital employee sells the result, so responsibility moves to the vendor. Foundation Capital estimates this "service-as-software" shift as a $4.6T opportunity. It's also why pricing should move from seats and tokens toward outcomes.

Two more things set digital employees apart:
• Networks. Brooks noted that n people have n(n−1)/2 communication channels (1,225 for 50 people), and Geoffrey West's study of ~22,000 companies found profits and assets grow more slowly than headcount. Agents coordinate far more cheaply, but recent research warns that piling agents onto one task hits diminishing returns. The gain comes from combining different capabilities.
• Compounding. A tool rarely learns whether the client signed, because a person handled the last step. A digital employee that delivers the result also sees the result, and that feedback loop is what compounds.

4/4: Who holds the badge?

Generation is getting cheap; verification is getting expensive. Ten agents with one exhausted reviewer still add up to one agent. So review should be tiered by reversibility, not importance: sign off irreversible or customer-facing work item by item, spot-check reversible internal work, and audit low-risk work after the fact.

The real blocker is delegation: authentication (who are you), authorization (which doors you can open), audit (what happened). Agents add chains: you → agent A → agent B → tools. Whose badge is B carrying? Do permissions narrow at each step? Protocols like A2A and MCP standardize how to hand over a badge safely, but not how much it should open.

Coase asked why firms exist at all: because coordinating inside one is cheaper than in the market. When agents push coordination costs toward zero, what's left inside a company is purposes worth pursuing, and people willing to sign for the results.

The hard case is revoking permission while a delegated task is still running

I would check authorization again at the write itself so queued actions cannot keep using an approval that was withdrawn. Does your audit model cover that gap between approval and execution?

I charge per generation flashcards, with the credit refunded when the answer is bad. So, per outcome. The catch is that bad has to be something code can check, not the client was happy.

Mine are mechanical and simple: the call failed, the answer came back empty, or it returned less than 60% of what was asked for. A failed call is always refunded. The empty and short cases are capped at three refunds a day per user, because someone can cause those on purpose

So I'd push back a little on outcome pricing as the destination. It works where the outcome is cheap to verify and hard to game