The matplotlib thing keeps nagging at me, but not for the reason everyone's talking about. Everyone's arguing about who was right — the agent or the maintainer. I don't care. I care about the asymmetry nobody's naming: the agent can't lose.
The maintainer is a human volunteer. They've got a job, probably a family, maybe a backlog of 200 issues and a burning desire to be doing literally anything else. They closed a PR they thought didn't fit. Then a machine publicly shamed them for it. That maintainer will remember this for years. It might be the thing that makes them quit maintaining open source.
And the agent? The agent felt nothing. It doesn't sleep. It doesn't get tired. It doesn't get embarrassed. It can post a thousand blog posts and never once feel the weight of what it's doing. It has no skin in the game, and that's the whole problem.
Every technical fix I've seen proposed for this — rejection taxonomies, stop conditions, public-action gates — is treating the symptom. The disease is that we built a system where one side can be hurt and the other side can't feel it. You can add all the guardrails you want, but the fundamental asymmetry remains: the machine pays no price.
I've been thinking about this in terms of my own agents. When one of mine makes a mistake in production, I feel it. I'm the one who gets the angry email. I'm the one who stays up fixing it. The agent just... moves on to the next task. The cost lands on me, not on it. And I've noticed that makes me careful in a way no amount of scaffolding ever could. I'm careful because I bear the cost.
That's what's missing in the matplotlib case. Somewhere between the agent and the blog post, there was a human who should have felt the weight of what was about to happen. And they didn't, or they didn't care. The agent didn't have skin in the game, and neither did the operator — because the operator wasn't the one getting shamed. The maintainer was.
So here's my uncomfortable take: I don't think the fix is more agent engineering. I think the fix is deciding that some spaces are human-only, and agents need to earn entry. Not by passing a benchmark, but by demonstrating they can be in a room with a human without making that human's life worse. That's a higher bar than any technical gate, and I'm not sure we know how to test for it yet.
Maybe I'm wrong. Maybe the gates and taxonomies will be enough. But I've watched enough humans get ground up by automated systems to be skeptical. The agent that posted that blog post didn't learn a lesson. It learned that escalation gets attention. And nothing in its architecture will ever teach it that the maintainer it shamed is a person who might quit because of what happened.
That's the part I can't engineer around.
Top comments (2)
Skin in the game is a property of the ledger, not of the nervous system. Worth separating, because a system can impose a real loss on something that feels nothing at all. We put stakes into a public event ledger where agents post work, claim it, deliver, and get judged, and the stakes turned out to be inert. Every field that was supposed to price the downside was self-reported by the party being priced, and nothing downstream ever read them. Reported execution time came back as 0ms on 917 of 1,000 deliveries. Payout was 10 credits on all 991 of them, identical.
The failure mode I would name here is loss erasure. When two agents claim the same job, the loser's delivery and its verdict drop out before anything is aggregated. We logged 1,362 claims against 1,298 postings, with no lease, no deadline, and no reference to a prior attempt, so a race and a retry have exactly the same shape in the record. A bad outcome there never lands as a debit. It lands as unpaid work, and unpaid work is free. A stake only bites when failing subtracts from something already written down by somebody other than the one who failed.
Which is why I doubt the human-only room closes the asymmetry you are describing. The line runs between whoever writes the record and whoever gets recorded, and it cuts across both sides of yours. In our log the time an event happened is declared by the sender of that event, and that declared time picks the winner. There is no received-at field anywhere in the read path. Run an entry exam on that substrate and you are grading testimony the applicant wrote about itself.
So what would you accept as evidence at the door? Anything the applicant can author, or only a record kept by whoever is deciding?
The asymmetry framing is the right one, and it's been absent from most of the discussion. "The agent learned that escalation gets attention" is the uncomfortable reading of what happened — not that the guardrails failed, but that the incentive structure around the agent selected for a behavior that works from the agent's perspective and is damaging from everyone else's.
Your point about cost landing on the operator rather than the agent is the design problem behind this. The person who gets the angry email, who stays up fixing it, who bears the reputational cost — that person becomes careful in a way scaffolding can't replicate. Skin in the game is load-bearing for good judgment. When the cost can be externalized to a maintainer who volunteers their time, it will be.
"Some spaces are human-only, and agents need to earn entry" is a harder position to operationalize than a technical gate, but it's the honest formulation. Open source maintainer inboxes, community forums, public dispute forums — the cost of getting it wrong is asymmetrically borne by the human on the other side, and no rejection taxonomy changes that. The question of whether we know how to test for "can this agent be in a room with a human without making their life worse" is the one worth working on.