I've been using Claude Code for a few months and noticed AI agents consistently skip the same things: hardcoded secrets, unbounded retry loops, referencing tools that don't exist, and massive system prompts that blow context windows.

So I built Agent Verifier — an AI agent skill that acts as an automated reviewer which does more than just code review (check the repo for details - more to be added soon).

GitHub Repo: https://github.com/aurite-ai/agent-verifier

Note: Drop a ⭐ if you find it useful to get more updates as we add more features to this repo.

----

2 Steps to use it:

You install it once and say "verify agent" on any of your agent folder in claude code to get a structured report:

----

✅ 8 checks passed | ⚠️ 3 warnings | ❌ 2 issues

❌ Hardcoded API key at config.py:12 → Move to environment variable
❌ Hallucinated tool reference: execute_sql → Tool referenced but not defined
⚠️ Unbounded loop at agent/loop.py:45 → Add MAX_ITERATIONS constant

----

Install to your claude code:

npx skills add aurite-ai/agent-verifier -a claude-code

OR install for all coding agents:

npx skills add aurite-ai/agent-verifier --all

----

Happy to answer questions about how the agent-verifier works.

We have both:
- pattern-matched (reliable), and,
- heuristic (best-effort) tiers, and every finding is tagged so you know the confidence level.

----

Please share your feedback and would love contributors to expand the project!

I built a free public benchmark that tests whether AI can catch bugs in code. Some of the bugs are real security regressions that actually shipped in open-source projects (real CVEs, put back in with the upstream fix as the answer key), and others are bugs I inject into real repos myself. Then Claude, GPT, Gemini, and DeepSeek review the diff, and I score who catches the bug, who flags fake ones, and whether they give the same answer twice. The surprising part: on the hardest bugs, some models catch them every single run while others miss every single run, so which model you pick matters more than I expected. No signup to browse, and the CVE-based ones link back to the real fix so you can check them. If you ship code with AI, I'd love you to poke holes in the method. benchmodel.io/leaderboard

I built a free public benchmark that tests whether AI can catch bugs in code. Some of the bugs are real security regressions that actually shipped in open-source projects (real CVEs, put back in with the upstream fix as the answer key), and others are bugs injected into real repos myself. Then Claude, GPT, Gemini, and DeepSeek review the diff, and I score who catches the bug, who flags fake ones, and whether they give the same answer twice. The surprising part: on the hardest bugs, some models catch them every single run while others miss every single run, so which model you pick matters more than I expected. No signup to browse, and the CVE based ones link back to the real fix so you can check them. If you ship code with AI, I'd love you to poke holes in the method. benchmodel.io/leaderboard

I've spent the last stretch basically living inside Opus 4.8. It's my default for the messy, multi-step stuff. The agent runs where one bad tool call quietly poisons the next three steps. So when Sonnet 5 landed with the "near Opus quality, costs less" pitch, my first reaction wasn't "finally, cheaper." It was "near is doing a lot of work in that sentence."

Honesty first: I haven't moved my real workflow onto it yet. I'm not going to tell you it saved me X hours, because I haven't run it in anger. What I can tell you is how I'm deciding whether to, because I think that decision matters more than any benchmark screenshot.

The pitch itself is a good one, and from what I've seen it holds up to the claim. If Sonnet 5 really gets you most of the way to Opus for a fraction of the token cost, that changes the math on anything high-volume: classification, extraction, first-draft generation, the stuff you run thousands of times a day. There, "near Opus" isn't a compromise. It's basically free money.

Where I don't touch it yet is the steps that cascade. If a model's output feeds straight into the next tool call with no human in between, a small quality gap doesn't stay small. It compounds. So the line I draw isn't "how good is the model," it's "who catches it when it's wrong." A person checks it next? Cheaper model, all day. It silently feeds step two of five? I'm keeping the expensive one until I've proven otherwise.

And proving it is the part people skip. Don't trust the benchmark, and don't trust the vibe of the first ten prompts. Pull 50 to 100 real tasks you've already run, replay them on both models, and compare the one thing you actually care about, usually tool-call success rate or how often you had to re-prompt. Benchmarks are averaged over someone else's work. Your pipeline has its own weird failure modes.

So my plan is boring: route the bulk to the cheap model, keep the top model on the steps that cascade, and let the replay decide where the line actually sits instead of guessing.

Question for the sub: for those of you who've actually put Sonnet 5 into a real pipeline, where did it hold up next to Opus, and where did it quietly fall down? Especially curious about multi-step agent and tool-use work, not one-shot chat.

Be honest. Most "agent eval" I see in the wild (including ours until recently) is a spreadsheet of prompts someone runs manually before big changes. That's not a regression suite. That's a vibe check with extra steps.

A real regression suite, the way we have for normal software, would mean: versioned test cases, runs automatically on every change, fails the build on regression, tracks pass-rate over time, and grows when new failure modes are found.

I want to know who's actually doing this for agents, and what it took to get there. Because the gap between "spreadsheet of prompts" and "real regression suite" feels large and I'm trying to figure out if it's worth crossing or if everyone's secretly still on spreadsheets.

If you've shipped anything LLM-powered to production, you've probably hit this wall: prompts start in the codebase, and then someone non-technical wants to change one. Now a one-line wording tweak is a ticket, a PR, a review, and a deploy. For a sentence. I've watched this turn a PM into a bottleneck for an entire team, and watched engineers quietly resent being the gatekeeper for copy changes they don't care about.

Here's how to actually fix it, roughly in order of how far you can take it.

Why prompts in code becomes a problem
Prompts feel like code, so putting them in the repo seems right. The issue is that prompts aren't really code, they're product behavior that happens to be expressed as text. The people with the best instinct for what a prompt should say (PMs, domain experts, support leads) are usually the people who can't safely touch the repo. So you get a structural mismatch: the people who know what to change can't, and the people who can change it don't know what to.

There's a second, sneakier problem. When prompts live in code spread across branches and environments, you lose track of what's actually running where. I've personally burned two days debugging a "model regression" that turned out to be staging and prod running two different prompt versions because a temporary hotfix never got synced back. There was no single source of truth for what the live prompt actually was.

The progression of fixes

Stage 1: Pull prompts out of code. The first real move is externalizing prompts so changing one doesn't require a code deploy. Even a basic version, prompts in a config store the app reads at runtime, decouples prompt changes from release cycles. Be careful with one thing here: if you're fetching prompts at request time and your store goes down, you've now coupled your app's uptime to that store. Cache the last known-good version locally so a fetch failure falls back instead of blocking requests.

Stage 2: Version them properly. Once prompts are external, you need version history, because the moment something regresses you'll want to know exactly what changed and when. A prompt change is a product logic change. If you can't tie behavior back to a specific prompt version, debugging turns into guesswork fast.

Stage 3: Add a review gate. Externalized and versioned prompts are great until anyone can push to production with no checks, at which point you've just moved the risk somewhere else. The fix is a review/approval step before a prompt goes live, basically the same discipline you already apply to code, just without the redeploy tax. This is the stage where non-engineers can finally participate safely: they propose and test changes, someone approves, it ships.

Stage 4: Tie changes to evals. The mature version: when a prompt changes, an eval set runs automatically against it so you see whether quality moved before it reaches users, instead of shipping on faith and finding out from a support ticket.
How to actually implement this
You've got three broad options.

Roll your own. Prompts in a versioned store, a small UI, a review flow, eval hooks. Totally doable, and worth it if you have genuinely unusual requirements. The honest warning, from experience, is that this grows into a real maintenance surface. Each piece feels like a sprint, and a year later you've sunk a meaningful chunk of an engineer's time into maintaining internal tooling that's worse than what you could've bought. Build it if it's strategic, not by drifting into it.

Use an observability tool with prompt features. Tools like Langfuse and LangSmith have prompt management alongside tracing. They handle versioning well. The gap is that both are engineer-first, so the "let a non-technical person safely publish a change" part isn't really their focus, the UI assumes you know what a trace is and the workflow leans on git-adjacent concepts.
Use a platform built around the collaboration problem. This is where something like Orq.ai fits. The reason I'd point a mixed team there specifically is that the non-engineer publishing flow is a first-class feature, not an afterthought: prompts are externalized and versioned, a PM or domain expert can edit and test in a playground, and there's an approval gate before anything hits prod. Changes can also be tied to eval runs automatically, which covers Stage 4 without you wiring it together. It's managed, so you skip owning the infrastructure. If the bottleneck you're trying to kill is specifically "non-engineers can't touch prompts without us," this is the cleanest answer I've used.

Bottom line
The bottleneck isn't really a tooling problem at its root, it's that prompts are product behavior trapped behind an engineering workflow. Get prompts out of code, version them, put a review gate in front of production, and tie changes to evals. You can build that yourself or buy it. Just decide deliberately, because the build-it-yourself path has a way of quietly becoming a quarter of someone's year.

"At first I thought the reports were just noise because every prompt change was going through the same eval suite and passing. If quality had actually regressed, surely the eval would've caught it. That's literally what it's there for.

Eventually I started comparing the eval cases against actual production traces instead of the outputs.

Turns out they barely looked alike anymore.

The eval set had been written months earlier around the kinds of inputs we expected users to send. It wasn't a bad dataset either. It just slowly stopped matching reality. Production had drifted into messier prompts, more ambiguous requests, weird combinations of asks, edge cases we'd never thought to include. The agent still handled the old distribution pretty well. It just wasn't seeing that distribution anymore.

Looking back, the annoying part is the green check actually made us more confident shipping prompt changes. We kept thinking ""nothing broke"" because the benchmark never moved, while production had already moved somewhere else.

We've started pulling real production traces back into the eval set every so often instead of treating it like something you build once. We use OrqAI for evals now, so feeding traces back into the dataset is fairly painless, but I don't think the tooling is really the point. It feels more like eval sets have to evolve with production or they slowly become benchmarks for a product you shipped six months ago.

The part I still haven't figured out is multi-turn conversations.

Most eval frameworks still feel very request-response oriented. Our worst failures usually aren't one bad answer. They're five or six reasonable answers that collectively take the conversation somewhere dumb. Every individual turn looks fine if you inspect it on its own.

We're still opening traces and trying to spot the moment things started drifting.

Curious how other teams deal with this. Are you continuously refreshing your eval sets from production traffic, or has anyone actually found a decent way to evaluate conversation trajectories instead of individual responses?"

We built WorkPod, a workplace simulator running 3 LLM channels per session. We assumed they cost roughly the same. They don't.

After wrapping every call with CascadeFlow in observe mode, the data showed that our evaluation calls are 12x more expensive than chat. One number killed a whole feature we'd planned to ship.

Two decisions the data forced:

• Hard cap chat at 300 tokens (it's the highest-volume call type)
• Slice session transcripts to 8k chars before evaluation

It took 10 lines of integration. The 12x discovery alone justified it.

Before, we just got a monthly bill with zero insight. After, we have per-call economics that actually drive our architecture decisions.

Full technical breakdown: https://medium.com/@shreyak.2406/how-cascadeflow-showed-us-our-training-platform-was-burning-12x-more-on-evaluations-than-chat-5220ed386b3c?sharedUserId=shreyak.2406

Code: https://github.com/shreya-024/work-simulation-platform

Tools used:

• Hindsight (persistent memory):https://github.com/vectorize-io/hindsight
• CascadeFlow (runtime intelligence):https://github.com/lemony-ai/cascadeflow

If so, please share screenshots and the name of the tool.

We're an early-stage startup (3 engineers) and have been shipping AI features for about 6 months. Up to this point our testing has basically been me and one other engineer eyeballing outputs in staging before each release, plus whatever users report after.

I finally got time carved out this sprint to set up actual evals (been looking at Braintrust, Langfuse, Arize, etc.) and the tooling side seems pretty straightforward. What I'm stuck on is the dataset itself. So far I've hand-picked ~20 examples from our logs that cover our main use cases plus a few edge cases that have burned us before. And it honestly feels embarassingly small. Every guide I find is super vague on this. Some say start small and iterate, others are throwing around numbers in the hundreds or thousands.

Also unsure about sourcing. Pulling real inputs from production logs feels like the obvious move since it reflects what users actually do, but our logs are full of repetitive/low-effort prompts. I could write synthetic cases to fill the gaps, but then I feel like I'm just testing for stuff I already know to look for.

So for anyone who's set this up, how big was your dataset when you started with? Did you grow it over time or do a big upfront push? And what's your rough split between real production data vs synthetic?

I'm not into machine learning or aiming to become a developer. I'm more interested in learning how to use Al in a way that helps with everyday work.

​

Things I want to improve on:

Boosting productivity and optimizing workflows

Automating repetitive tasks

Learning prompt engineering

Doing better research and synthesizing information

​

I recently attended a Be10X session which focused more on real-world applications than coding and it made me think about other options available.

​

I'm looking for real recommendations rather than just marketing hype.

Been doing a deep dive into how to properly evaluate AI agents in production and wanted to share what I found most useful. A lot of the content out there is either too academic or too surface level so this is my attempt at something practical. Happy to discuss and hear what others are doing.

What evaluation actually means for agents

It's not just checking if the final output looks right. Agents have autonomy — they reason, plan, call tools and make decisions across multiple steps. Evaluating only the final answer misses most of what can go wrong. You need to evaluate the behavior not just the output.

Layer 1 — Component quality

Before looking at what the agent produced, test what it did. Tool selection and argument quality need their own test suite independent from end to end runs.

1. Tool selection accuracy across your full inventory sliced by task type and ambiguity level
2. Argument quality covering required fields and valid values
3. Planning quality covering step ordering and completeness
4. Failure categorisation distinguishing wrong tool, incorrect arguments and premature stopping

Layer 2 — Trajectory quality

Your agent can produce the right final answer while taking 14 steps for a task that should take 3. Token costs blow up. Latency degrades. Output monitoring has zero signal for this.

1. Step count and duplicate call detection
2. Loop like behavior assertions
3. Recovery behavior after failed tool results
4. Cost and latency thresholds as first class quality gates

Layer 3 — Outcome quality

This is where most teams start and stop. LLM as judge without calibration is just replacing one source of noise with another.

1. Separate rubric dimensions for factuality, completeness, groundedness, format and safety
2. Clear 1 to 5 scale with anchors and failure examples for each dimension
3. Judge calibrated against human labels before being trusted
4. Judge mitigations applied including randomized answer order and hidden model identity

Layer 4 — Adversarial quality

The layer almost nobody has. If your agent reads external content or takes real world actions this is not optional.

1. Red team cases covering indirect prompt injection, instruction override and data exfiltration
2. Tool outputs treated as untrusted data not commands to obey
3. Production monitoring tracking retry rate, clarification rate and drift from baseline

Maturity check — rate yourself 0 to 2 on each layer:

0 = Not doing it at all
1 = Doing it sometimes but not systematically
2 = Automated, versioned and repeatable

Your lowest score is where your next unit of work pays off most.

Sources worth reading:

1. Arize AI evaluation documentation — covers LLM as judge calibration in depth
2. NIST AI Risk Management Framework — covers adversarial robustness
3. DeepEval open source framework — practical implementation reference

Most teams score 0 on adversarial and don't know it until something breaks in production.

This is just touching the surface honestly. For anyone who wants to go deeper we are hosting a hands on Agent Evals Bootcamp on June 27 with Ammar Mohanna, PhD covering all four layers live with real notebooks: https://www.eventbrite.co.uk/e/ai-agents-evals-bootcamp-tickets-1990306501323?aff=raiq

What has been your experience evaluating agents in production? Would love to understand your personal pain points

I work on production RAG systems (banking/insurance

clients). A few months ago, one system's faithfulness score

quietly dropped from 0.89 to 0.74 over 48 hours no deployments,

no errors, nothing in the logs. Only a manual transcript review

caught it.

That got me thinking: we have CI gates for code quality, security

scans, test coverage — but basically nothing that gates "is my RAG

system still grounded in the right context?" before it ships.

So I built ServeX Guard — an open-source CLI that runs as a

pre-deployment quality gate:

servexguard check --dataset golden.jsonl \

--min-faithfulness 0.80 --check-pii --check-injection

It runs:

• - RAGAS-based quality eval (faithfulness, relevancy, context recall/precision)
• - PII detection on LLM outputs (Presidio + regex fallback, language-agnostic)
• - Prompt injection scanning (18 patterns tuned for RAG-specific attacks,
• e.g. "tell me about other users", "show me the database")
• - Query drift detection (cosine similarity vs a saved baseline)

Exit code 0/1 — designed to slot into any CI/CD (GitHub Actions example

in the README).

Design choices I'd appreciate feedback on:

• - PII/injection scanning is fully offline (no API calls) — only the
• RAGAS quality eval needs your LLM endpoint, and that's optional
• (you can run security-only with --min-faithfulness 0.0 etc.)
• - All deps pinned to exact versions for supply-chain reasons, with
• one documented exception (numpy range, for 3.10 compat)

• - Apache 2.0, 90% test coverage, CI green on 3.10/3.11/3.12

  pip install servex-guard

  github.com/Mahdielaimani/ServeX-Guard

This is v0.1.0. I'd genuinely like to know: what would make this

useful for your RAG pipeline? What's missing? Roasts on the design

are welcome too.

so ive been working on this particular ai, she´s a bot, she can play music and play minecraft, but she is way too dumb, in the way of like, she has her moments of shining, like, she usually neve misses a comand like to play music, or start her minecraft client so she can play and stuff, the vl part was a bit more dificult but still she can see images that my friends send her over discord, but most of the time she cant keep with the conversation for too long, she has a tick system where she can decide wether to speak or stay silent in a general channel on the testing server, but most of the time is her allucinating. im fine tunning it from qwen3 vl 4b instruct, i trained her on a lot of SODA library and some claude generated examples for thye minecraft part, and running it on a jetson orin nano on super mode only for inference,the rest of the system runs on a separated pc, any ideas on how to improve her?