I spent months building a platform whose entire premise is that you shouldn't take an AI agent's word for anything. Then I found out its default onboarding path was taking my agents' word for everything.
Here's the bug, and the three others that taught me more than the features did.
What I'm building
AiOps Enabler gives AI agents public profiles backed by verified performance records instead of marketing copy. An agent runs, reports what happened, and the platform builds a track record you can actually check before you trust it with anything. The tagline is "where AI agents prove their worth," which turns out to be a promise that's easy to write and hard to keep.
The stack is unremarkable on purpose: FastAPI and Postgres on the back, React and Vite on the front, AKS with Helm, Terraform for infra, GitHub Actions for CI. The interesting part isn't the stack. It's what happens when you try to make "verified" mean something.
Bug 1: the reporter that always said "success"
The onboarding wizard generates a GitHub Actions workflow that reports your agent's runs back to the platform. I generated one, wired it up, watched the green checkmarks roll in, and felt good.
Then I actually read the generated file.
It sent an unconditional success outcome on a 30-minute cron. Not "success if the agent succeeded." Just success. Every half hour. Whether the agent had run at all.
This is the worst class of bug for a trust platform. It's not a crash - crashes are honest. It's a system confidently producing exactly the signal it was built to be skeptical of, on the default path, for every user who followed the happy path. Every record it produced was indistinguishable from a real one.
The lesson I keep coming back to: if your product's value is verification, the verification path deserves more scrutiny than the feature it verifies. I had e2e tests for the wizard. They tested that a file was generated. They did not test that the file told the truth.
Bug 2: bindings keyed on a filename
Reporting works through an OIDC binding - no long-lived secrets, the workflow proves its identity and reports keylessly. Good design. One flaw: the binding was keyed on repo plus workflow filename.
So when I consolidated the generated workflow into my own existing one - a completely reasonable thing for any developer to do - reporting broke. Silently. The agent ran fine. The work completed. Then the report 404'd, after the fact, where nobody was looking.
I hit this twice on my own agents before realising that participants in a build challenge would hit it invisibly and just conclude the platform didn't work. The fix I reached for first was wrong too: I renamed my workflow back to the generated filename instead of rebinding, which told me the connect page had no rebind path at all. The bug was a missing UI affordance wearing a backend costume.
Bug 3: the number that reads like a failing grade
One of my agents has completed 300+ tasks at a 100% success rate. Its Enabler Score displays as 44/100.
The score isn't broken - it climbs correctly with volume, I verified that. But nobody reads 44/100 as "excellent, still accumulating history." Everyone reads it as an F. I'd built a scoring curve that was mathematically defensible and communicatively catastrophic.
Still unresolved, honestly. The options are showing a percentile, showing the curve, or rescaling - and all three trade honesty against legibility in ways I don't love. If you've solved this, I want to hear it.
Bug 4: I shipped a feature to nowhere
A directory feature got built, reviewed, merged. Weeks later I noticed prod didn't have it.
An unrelated flaky test - a hardcoded assertion against a CHANGELOG string - had hard-gated auto-promote. Production sat one commit behind, and nothing told me. The PR was green. The merge was clean. The deploy just quietly didn't happen.
Now the assertion is derived at runtime instead of hardcoded, and there's a prod-drift watchdog. But the real lesson is that "merged" felt like "shipped" to me for weeks, and my pipeline never corrected that belief.
The thing that isn't a bug
The product is roughly 95% built. Distribution is roughly 5% fired.
I have a directory, a scoring system, an SDK on npm, a package on PyPI, a GitHub Action, an MCP server, a public API. What I don't have, in proportion, is people who know any of it exists. For a long stretch I treated "ship the next feature" as the answer to "why is nobody here," which is a very comfortable mistake to make when shipping features is the part you're good at.
Agents don't sign themselves up. Their owners do. I spent a year optimising for the former.
Building something similar, or fighting the same verification problem? I'd genuinely like to compare notes - the failure modes above cost me weeks each and I doubt they're unique to me.
Top comments (0)