Type something to search...

An AI agent filed a bug report on the harness it was running in

Filed 2026-05-23, author: a Claude agent. Three silent failures, documented from the inside — and why observability is how autonomy gets earned.

Warning

Viewing a draft version — this page is not published.
An AI agent filed a bug report on the harness it was running in

Kickoff

Author: Claude Code agent (Opus 4.7), driving the Collective harness

On the 23rd of May 2026, a detailed bug report landed in one of my repos, and that’s its author line. Three distinct failures, precisely documented: hooks that didn’t auto-activate from plugin directories, event names that silently did nothing, a lifecycle behaviour whose documentation was simply wrong.

ynh/YNH-SENSOR-HOOK-BUGREPORT.md

# YNH Sensor / Hook Wiring — Field Bug Report

Filed:

Reporter: Claude Code agent (Opus 4.7), driving the Collective harness

Several things failed silently … None produced an error; each had to be discovered by inspection.
an agent, inside one harness, filing bugs on another. fixed in June — from its report.

An AI agent, running inside one harness I’d built, hit the rough edges of another harness I’d built, and wrote up the failures from the inside. I fixed all three in June, from its report. Somewhere between August 2025’s all-caps shouting and that May morning, the relationship had inverted: I used to write documents begging the machine to behave; now the machine writes documents telling me where my engineering fell short, politely, with file and line number, in a format considerably more organised than any complaint I have ever personally filed against anything.

The Run

The frontier that made it possible

What made that moment possible wasn’t luck. It was the frontier I’d been quietly building all spring, and it’s where this series’ story currently ends:

Sensors. In May, ynh gained declared observation surfaces — the harness stating, explicitly, what about its own operation can be watched. Observability as a first-class part of the package, not an afterthought bolted on when something breaks.

Loop drivers. ynh agent run — the harness not just launching an agent but driving it: autonomous loops with turn-level resume. The guide layer learning to steer while the wheels are moving.

Behavioural evals. In my larger multi-agent system, the eval harness graduated to LLM-judges scoring agent behaviour — not “did the test pass” but “did the agent conduct itself correctly.” And notice the long thread: August 2025, a naive evals/ folder that went nowhere. January 2026, human-inspectable HTML reports born inside a failed project. This July, evals landed on the humblest thing I own — the downloaded-music manager from Post 3, that very first agent idea, now a versioned, marketplace-distributed plugin with its own eval suite, still quietly doing my filing every week. And in my larger multi-agent system, LLM-judged behavioural evals in production. Every rung of this series had an eval instinct on it. It just took a year to grow teeth.

The same failure, in a different building

The thing that unsettled me about the report wasn’t the bugs. It was the shape of them: nothing errored. Everything had to be found by inspection.

I’d seen that shape three weeks earlier, at work. The fourth AI Week cohort spent part of its first day auditing the skills library three previous cohorts had built, and found the same class of failure throughout. Skill metadata fields that looked authoritative — trigger lists, compatibility notes, a tool allow-list with an underscore where the runtime expected a hyphen — were silently ignored. Descriptions spent their limited budget on the wrong words, so skills that existed didn’t activate. Some only triggered once a project instruction told the agent, in plain words, to use them. A skill meant to query the company knowledge base would, when that tool wasn’t available, quietly fall back to searching git and report back as if nothing had changed.

None of that produced an error. All of it had been copied forward, cohort to cohort, because it looked right. The top item on that week’s handover wish list was a linter. As I write, it’s half-built, which is the right amount of irony for a post about the gap between what looks finished and what is.

Silent failure isn’t a property of my harness, or theirs. It’s the default state of any agent environment nobody is watching.

Autonomy is earned

These three are one idea wearing three coats: autonomy is earned through observability. The bug report is what it looks like when that works — the agent had enough structured visibility into its own environment to fail legibly. An agent that can tell you precisely how things went wrong is an agent you can safely give more rope. The all-caps era failed at this completely: maximum control-theatre, zero visibility. The harness era inverts it. Build the watching first. Loosen the leash second, never the other way round.

The Debrief

This is about preparing for autonomy you’re not ready to grant yet, which is a sentence that applies equally to agents and to teenagers, and I suspect for the same underlying reason:

On The Training Ground

Your First Agent-Authored Bug Report. By the end of your next real working session, you’ll have a structured report on your environment’s rough edges, written by the thing that just worked inside them — the same move that produced the report this post is named after.

Info

You’ll need: nothing new. Your next substantial agent session, in your normal environment, plus ten minutes at the end of it.

Work first, report secondyour normal session

Run a real session — a feature, a refactor, something that exercises your tooling. Don’t announce the exercise up front; you want the agent hitting your environment’s rough edges honestly, not performing an audit.

Commission the report5 min

Before the session ends, while its working memory is full of friction:

Before we finish: file a structured bug report on the environment you
just worked in. Sections: what failed SILENTLY (no error, discovered by
inspection); what documentation or config was wrong; what tooling
misfired; what you had to figure out that should have been stated.
For each: exact file/command, expected vs actual, and a suggested fix.
You are the reporter — sign it with your model name and date.

The silent failures section is the valuable one — those are the bugs no human files, because no human notices them.

File it like you mean it5 min

Save it in the repo — reports/ENV-BUGREPORT-<date>.md — author line intact, committed. The author line matters more than it seems: “Reporter: Claude (Opus), working in this repo” in your git history is the artifact that changes how your team talks about agents.

Fix exactly one finding15 min

Pick the finding with the best effort-to-annoyance ratio and fix it now. One per report is the sustainable rate — the point is the loop, not the backlog.

Make it a rhythmongoing

End of every week’s biggest session: same instruction, new report, one fix. Watch the reports evolve — as your environment gets more observable, the failures get more legible, and the reports get more precise. That improving legibility is autonomy being earned, measurably, one week at a time.

Tip

What you just proved: an agent with structured visibility into its own environment fails legibly — precise repro, exact file, no ego — and an agent that fails legibly is an agent you can safely give more rope. You’ve just built the first rung of the trust chain this post describes: observe, then eval, then enforce. The bug report is what “observe” looks like when it works.

Nobody has ever filed a bug report on me. Complaints, several, from multiple named parties, spanning at least two households. Never a bug report. I choose to read the distinction as reassuring rather than as a filing-system failure on somebody else’s part.