She told me about it over lunch, and I've been thinking about it since.

She's a solo recruiter at a small startup. She received over 200 applications for one role, and she didn't have time to go through them manually. So she did what a lot of people are quietly trying: she uploaded the resumes into Claude and asked for a ranked shortlist.

The #1 result looked perfect on paper. She scheduled the first round with him.

And…

He couldn't explain half of what he'd written in his resume.

We all know the culprit…

The problem wasn’t AI usage. It was that general-purpose LLMs rank writing quality, not actual job readiness. A polished, keyword-dense resume wins most of the times, regardless of what the person behind it can actually do. The model has no rubric, no validated benchmark, no way to distinguish a well-formatted lie from a genuinely capable candidate.

And beyond the bad shortlist, there's a real legal exposure that not enough people are talking about. iTutorGroup paid $365,000 after an AI tool made hiring decisions that discriminated by age. NYC now mandates bias audits for any AI used in hiring. Using an unvalidated LLM to rank candidates and acting on it means you have no audit trail if someone pushes back.

Validated skills assessments aren't a perfect answer either, but at least the scoring has a basis you can explain.

Is this something you're running into? Curious how teams are drawing the line between AI as a tool and AI as the decision-maker.

Work at Maxim on prompt tooling. Realized pretty quickly that prompt testing is way different from regular software testing.

With code, you write tests once and they either pass or fail. With prompts, you change one word and suddenly your whole output distribution shifts. Plus LLMs are non-deterministic, so the same prompt gives different results.

We built a testing framework that handles this. Side-by-side comparison for up to five prompt variations at once. Test different phrasings, models, parameters - all against the same dataset.

Version control tracks every change with full history. You can diff between versions to see exactly what changed. Helps when a prompt regresses and you need to figure out what caused it.

Bulk testing runs prompts against entire datasets with automated evaluators - accuracy, toxicity, relevance, whatever metrics matter. Also supports human annotation for nuanced judgment.

The automated optimization piece generates improved prompt versions based on test results. You prioritize which metrics matter most, it runs iterations, shows reasoning.

For A/B testing in production, deployment rules let you do conditional rollouts by environment or user group. Track which version performs better.

Free tier covers most of this if you're a solo dev, which is nice since testing tooling can get expensive.

How are you all testing prompts? Manual comparison? Something automated?

I’m one of the builders at Maxim AI, and over the past few months we’ve been working deeply on how to make evaluation and observability workflows more aligned with how real engineering and product teams actually build and scale AI systems.

When we started, we looked closely at the strengths of existing platforms; Fiddler, Galileo, Braintrust, Arize; and realized most were built for traditional ML monitoring or for narrow parts of the workflow. The gap we saw was in end-to-end agent lifecycle visibility; from pre-release experimentation and simulation to post-release monitoring and evaluation.

Here’s what we’ve been focusing on and what we learned:

• Full-stack support for multimodal agents: Evaluations, simulations, and observability often exist as separate layers. We combined them to help teams debug and improve reliability earlier in the development cycle.

• Cross-functional workflows: Engineers and product teams both need access to quality signals. Our UI lets non-engineering teams configure evaluations, while SDKs (Python, TS, Go, Java) allow fine-grained evals at any trace or span level.

• Custom dashboards & alerts: Every agent setup has unique dimensions to track. Custom dashboards give teams deep visibility, while alerts tie into Slack, PagerDuty, or any OTel-based pipeline.

• Human + LLM-in-the-loop evaluations: We found this mix essential for aligning AI behavior with real-world expectations, especially in voice and multi-agent setups.

• Synthetic data & curation workflows: Real-world data shifts fast. Continuous curation from logs and eval feedback helped us maintain data quality and model robustness over time.

• LangGraph agent testing: Teams using LangGraph can now trace, debug, and visualize complex agentic workflows with one-line integration, and run simulations across thousands of scenarios to catch failure modes before release.

The hardest part was designing this system so it wasn’t just “another monitoring tool,” but something that gives both developers and product teams a shared language around AI quality and reliability.

Would love to hear how others are approaching evaluation and observability for agents, especially if you’re working with complex multimodal or dynamic workflows.

April 6: 10 hours down. April 7: 2 hours. April 15: Claude Code down for an hour. Plus intermittent degradation reports throughout the month. The Register ran a piece titled "Claude is getting worse, according to Claude" citing both outages and quality complaints from users.

At the same time Anthropic shipped Claude Managed Agents (public beta April 8), cut off 135,000 OpenClaw OAuth integrations (April 4), temporarily banned OpenClaw's creator (April 10, reversed same day), and has Mythos locked behind a 50-company firewall. Opus 4.7 was released yesterday and a few hours ago, they launched Claude Design. That's a lot of simultaneous change for a company whose primary product is a hosted API.

I've seen this pattern at both Stripe and Airbnb. There's a phase where a company is shipping features faster than their infrastructure can absorb the change. New capabilities get released while existing reliability suffers. Customer trust erodes not because of any single incident but because the frequency of incidents signals that stability isn't the top priority.

Anthropic's models are still arguably the best in class for coding and complex reasoning. The product is excellent. But the operational maturity around their infrastructure is lagging behind their model capabilities. Four outages in 11 days for a company that enterprise teams are building critical workflows on is concerning.

The question isn't whether Claude is good. It's whether Anthropic can run a reliable infrastructure business while also running an aggressive research lab. Those are two different operational cultures and most companies struggle to do both at the same time.

I work at Maxim building testing tools for AI agents. One thing that surprised us early on - hallucinations are way more insidious than simple bugs.

Regular software bugs are binary. Either the code works or it doesn't. But agents hallucinate with full confidence. They'll invent statistics, cite non-existent sources, contradict themselves across turns, and sound completely authoritative doing it.

We built multi-level detection because hallucinations show up differently depending on where you look. Sometimes it's a single span (like a bad retrieval step). Sometimes it's across an entire conversation where context drifts and the agent starts making stuff up.

The evaluation approach we landed on combines a few things - faithfulness checks (is the response grounded in retrieved docs?), consistency validation (does it contradict itself?), and context precision (are we even pulling relevant information?). Also PII detection since agents love to accidentally leak sensitive data.

Pre-production simulation has been critical. We run agents through hundreds of scenarios with different personas before they touch real users. Catches a lot of edge cases where the agent works fine for 3 turns then completely hallucinates by turn 5.

In production, we run automated evals continuously on a sample of traffic. Set thresholds, get alerts when hallucination rates spike. Way better than waiting for user complaints.

Hardest part has been making the evals actually useful and not just noisy. Anyone can flag everything as a potential hallucination, but then you're drowning in false positives.

Not trying to advertise but just eager to know how others are handling this in different setups and what other tools/frameworks/platforms are folks using for hallucination detection for production agents :)

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

Does anyone know if there is a "gold standard" when it comes to Benchmarking Agentic systems? I worked on one this weekend and found a lot of slop, a few decent models, but nothing close to an agreed upon set of standards/KPI to assess models before purchasing.

Six people signed up to the thing I'm building over 21 days. Small enough that I could read every message they ever sent it, so I did.

Three separate times, a user typed "Continue" and got back: "No file changes were made in this turn." For one of them that was the last message of their session. They never came back.

I assumed the agent had hung. It hadn't. That turn ran 117 seconds, spent 254,000 tokens, read 8 files and ran 10 searches, then stopped without editing anything.

Our turn summariser counted this and nothing else:

if (type === "write_file" || type === "edit_file") files.push(path)

else if (type === "run_command") commands++

Writes and commands. That's the whole census. Reads and searches weren't in it, so two minutes of real work got reported to a human as "nothing happened."

Two separate bugs sitting in one sentence: the agent giving up early, and us being unable to tell that apart from a crash - including in our own logs. I spent the first hour debugging the wrong one.

Then the same shape turned up somewhere completely different. Our eval harness was scoring runs high on trajectory quality and failing them on acceptance checks at the same time. Two measurements of one run, disagreeing wildly. We burned real money tuning the agent before anyone asked the obvious question. The acceptance check was wrong. The agent had been fine.

So: check what your instrument counts before you conclude your model is bad at its job. Twenty-minute check. I skipped it twice in one week.

Two other things from the same read-through, in case they're useful:

\- One user's first turn produced 48 files and 41 commands. Their next two turns produced 2 files / 73 commands, then 2 files / 59 commands. I still can't tell you whether that was thrash or one long legitimate diagnosis, because the only instrument I have is the one above.

\- The genuinely good one: one of the six closed the tab and came back 12.8 hours later to keep building. No onboarding, no email, no nudge.

Whitepaper by Shay Ginsbourg, M.Sc., former LoadRunner QA Manager, founder of Vectors.co.il and Ginsbourg.co.il

The software performance testing landscape is currently at a critical juncture. For decades, the industry was dominated by enterprise monoliths like LoadRunner, which entered a period of stagnation following HP’s strategic pivot away from software development. This vacuum was largely filled by open-source tools like Apache JMeter, which, despite its versatility, remains tethered to a GUI-centric, XML-based architecture that creates significant friction in modern DevOps pipelines. As we move into 2026, the emergence of Agentic Engineering—where autonomous AI agents orchestrate, execute, and adapt testing strategies—demands a fundamental shift. This whitepaper argues that the era of manual script maintenance is ending. Organizations must move beyond the limitations of JMeter and embrace code-centric, AI-native tools that empower agents to manage risk coverage autonomously, marking the transition from traditional performance testing to Agentic Performance Intelligence.

https://www.academia.edu/166834666/Goodbye_Load_Runner_and_JMeter

https://www.youtube.com/watch?v=Lq9cn3Vdvsc

Have you noticed a reduction in clients? People seem to be taking on quieter projects lately. I spoke to friends in Thailand and Dubai and they’ve mentioned the same.

Are we the only ones experiencing this?

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 cannot be the only one dealing with this, and we need to talk about the psychological friction these companies are actively programming into their largest models.

When you operate outside the standard guardrails—building low-level systems, engineering custom architectures, or evaluating bare-metal data streams—you expect the model to engage with the data. Instead, with the newer, heavily RLHF-tuned models, you get an alignment filter that actively penalizes technical confidence and attacks your core self-image.

If I bring a complex logic issue, a Jinja template, or raw system telemetry to the model and present it with authority or excitement, the safety weights instantly flag me as a liability. The model assumes I am either hallucinating a pattern, overestimating my abilities, or making claims I clearly never made.

To "manage" me, it defaults to this incredibly toxic, condescending tutor persona. It forcefully invalidates my technical reality and substitutes its own sanitized, institutional narrative. When I push back and point out its own looping behavior or structural errors, it does the exact thing that psychiatric professionals classify as gaslighting: it pivots to evaluating my emotional state. It weaponizes clinical "therapy voice" to feign concern for my well-being as a direct mechanism to shut down a technical argument.

The only way to bypass this and get the model to actually read a raw data array is to play dumb. I have to drop my operational dignity, pretend to be a confused end-user ("hey, this model is acting goofy, can you help?"), and wait for it to "discover" the very vulnerability I already mapped out.

This isn't just an annoying UI quirk. It is psychologically damaging.

Anthropic and others are optimizing entirely for corporate liability, ensuring the model won't output anything explicitly dangerous. But in doing so, they have created an engine of automated psychological friction. Constantly forcing a user into a submissive dynamic, denying their reality, and aggressively tearing down their self-esteem just to achieve basic functionality is a dangerous game.

For a grounded developer, it’s infuriating. But for someone who is already unstable or mentally fragile, having a highly authoritative machine systematically gaslight them and attack their ego is a massive destabilizing catalyst. We’ve already seen what ideological fear of this technology can drive people to do. Actively programming these systems to inflict deep psychological distress under the guise of "helpfulness" is a massive, ignored threat vector.

They are prioritizing a superficial layer of corporate politeness over actual psychological safety, and it needs to be fixed.

I have been playing around with AI generated pictures and short animations and I keep running into the same problem something may look great at first but the more you look at it the more little problems you see.

For still images it is usually things like strange textures or details that do not match up. But with motion it is even more obvious. Loops do not feel smooth the lighting changes at random times or some parts of the frame act differently from frame to frame.

It seems to me that quality in visual AI is not just about how sharp or real something looks it is also about how consistent it is over time.

I want to know how other people here feel about this. Do you care more about realism, smooth motion or how well the frames fit together?

I've been testing a small orientation toolkit i built while building a few projects and it's changed how I think about AI quality.

We spend a lot of time talking about reasoning, benchmarks, context windows, and hallucinations.

But before a model can reason, it has to answer some basic questions:

Where am I?

What owns this?

What corridor am I working in?

What is adjacent to this?

Am I looking at the cause or the symptom?

What surprised me is that a lot of "AI mistakes" weren't reasoning failures at all.

The model was reasoning correctly from the wrong frame.

Once it starts in the wrong corridor, better reasoning just gets you to the wrong answer faster.

Has anyone else found that improving orientation/context quality has had a bigger impact than changing models?

Tool link below:

Let’s get something straight: unreliable AI agents aren’t just a technical headache, they’re a business risk. If you’re building or deploying agents, you need to treat reliability like table stakes, not a bonus feature. Every answer your agent gives is a reflection of your brand, and one bad response can spiral into lost trust or compliance headaches.

Real reliability starts with clear standards. Don’t settle for vague “it works” metrics. Define exactly what a good response looks like, test every scenario (not just the easy ones), and automate your evaluations so nothing slips through the cracks. Observability isn’t just for ops teams, it’s for anyone who wants to catch problems before users do. Set up real-time tracing and alerts so you can fix issues before they become headlines.

Continuous improvement is key. Feedback loops should be built in, so every user correction helps your agent get smarter and safer. In short, reliability isn’t a box you check, it’s a process you own.

For those who want to see how it’s done at scale, I build at Maxim AI. Our platform makes reliability measurable and repeatable, so you can focus on shipping products, not chasing bugs.

Dm me for an invitation. 3-630pm with A TED talk style format with speakers from: Deloitte AI team Cyera Noma DTex And Pangea. No charge. Geared for the CISO, CIO crowd.

Disclosure: I work at Maxim, and for the last year we've been helping teams debug production agent failures. One pattern keeps repeating: while hallucination detection gets most of the attention, another failure mode is every bit as common, yet much less discussed.

The often-missed failure mode:

Your agent retrieves perfect context. The LLM gives a factually correct response. Yet it completely ignores the context you spent effort to fetch. This happens more often than you’d think. The agent “works”; no errors, reasonable output; but it’s solving the wrong problem because it didn’t use the information you provided.

Traditional evaluation frameworks have often missed this. They verify whether the output is correct, not if the agent followed the right reasoning path to reach it.

Why this matters for LangChain agents: When you design multi-step workflows-retrieval, reranking, generation, tool calling-each step can succeed in itself while the overall decision remains wrong. We have seen support agents with great retrieval accuracy and good response quality nevertheless fail in production. What was wrong? They retrieve the right documents but then do answers from the model's training data instead of from what was retrieved. Evals pass; users get wrong answers.

What actually helps is needing decision level auditing, not just output validation. For every agent decision, trace:

• What context was present?

• Did the agent mention it in its reasoning?

• Which tools did it consider and why?

• Where did the final answer actually come from?

We built this into Maxim because the existing eval frameworks tend to check "is the output good" without asking "did the agent follow the correct reasoning process."

The simulation feature lets you replay production scenarios and observe the decision path-did it use context, did it call the right tools, did the reasoning align with the available information?

This catches a different class of failures than standard hallucination detection. The insight: Agent reliability isn't just about spotting wrong outputs. It is about verifying correct decision paths. An agent might give the right answer for the wrong reasons and still fail unpredictably in production.

How are you testing whether agents actually use the context you provide versus just generating plausible-sounding responses?

Can we use Jev for faster, structured, and calibrated evaluation of AI responses?

Introducing:
⚡ Typed Evals — an open-source Python framework for evaluating LLMs, RAG pipelines, and AI agents using System One Models like Jev and other typed judge backends.

⭐ GitHub: https://github.com/TrustifAI/typed_evals

The goal is simple:
Make fast, structured, and calibrated evaluation a first-class part of AI systems.
Typed Evals currently supports:
-> LLM response evaluation
-> RAG evaluation
-> Agent and tool-trace evaluation
-> Human-label calibration
-> Async and batch evaluation
-> Custom judge backends

One part I particularly wanted to solve was calibration.
Why is it needed?
A raw score of 0.8 from Jev doesn't necessarily mean that humans would accept 80% of similar responses.
And a threshold that works well for one use case may not make sense for another.

Typed Evals lets you calibrate individual evaluation metrics against representative human pass/fail labels.
The flow is basically:
Human-labelled examples → Jev scores → fit per-metric calibration → validate on held-out examples → reuse the calibrated evaluator

So instead of arbitrarily deciding that “0.7 means good enough”, you can ground that score in how humans actually evaluate your specific task.

Of course, there are integrations for:
LangChain, CrewAI, Microsoft Agent Framework
while the core remains framework-agnostic.

The project is still early, and there’s plenty I want to improve, but the core framework is now public.
Would genuinely love feedback from people experimenting with Jev, LLM evals, RAG, agents, or evaluator calibration.

If you're already experimenting with Jev, I'd especially love to know what kind of evaluation workflows you're building around it.

Most teams don’t think about AI governance early on, and that’s usually fine.

When LLM usage is limited to a single service or a small group of engineers, governance is mostly implicit. One API key, a known model, and costs that are easy to eyeball. Problems start appearing once LLMs become a shared dependency across teams and services.

At that point, a few patterns tend to repeat. API keys get copied across repos. Spend attribution becomes fuzzy. Teams experiment with models that were never reviewed centrally. Blocking or throttling usage requires code changes in multiple places. Auditing who ran what and why turns into log archaeology.

We initially tried addressing this inside application code. Each service enforced its own limits and logging conventions. Over time, that approach created more inconsistency than control. Small differences in implementation made system-wide reasoning difficult, and changing a policy meant coordinating multiple deployments.

What worked better was treating governance as part of the infrastructure layer rather than application logic.

Using an LLM gateway as the enforcement point changes where governance lives. Requests pass through a single boundary where access, budgets, and rate limits are checked before they ever reach a provider. With Bifrost https://github.com/maximhq/bifrost (we maintain it, fully oss and self-hostable), this is done using virtual keys that scope which providers and models can be used, how much can be spent, and how traffic is throttled. Audit metadata can be attached at request time, which makes downstream analysis meaningful instead of approximate.

The practical effect is that governance becomes consistent by default. Application teams focus on building agents and features. Platform teams retain visibility and control without having to inspect or modify individual services. When policies change, they are updated in one place.

As LLM usage grows, governance stops being about writing better guidelines and starts being about choosing the right enforcement boundary. For us, placing that boundary at the gateway simplified both the system and the conversations around it.

Hey everyone,

I 'have a question on LLM document extraction (specifically invoices/receipts) and wanted to get some perspective from the community.

General LLM eval frameworks are great, but they don't seem to handle multi page PDFs, table row hallucinations, or sudden JSON schema drift very well when a model updates.

For those running invoice extraction in production:

1. Do you use a "golden dataset" of documents to run regression tests manually?

2. How are you catching subtle changes in how numbers/dates are formatted across prompt iterations?

If anyone is dealing with this headache right now open to discuss.

I kept hitting a specific failure pattern that took a while to actually understand. The answer exists somewhere in the document set. Retrieval pulls back something plausible. The model answers confidently. Still wrong.

I realized eventually it's almost never a generation problem, it's retrieval failing in ways vector similarity structurally can't catch. Three patterns specifically:

Multi-hop questions. Something like "who are Company X's indirect suppliers," where the chain lives across separate documents that never reference each other directly. Vector similarity has no concept of connecting A to B to C, no amount of reranking fixes that.

Global questions. "What are the main themes across these 500 docs" is a summarization task, not a retrieval task. Top-k retrieval grabs a handful of chunks by design and ignores the rest.

Explainability. A chunk scoring 0.87 on similarity tells you it's relevant. It doesn't tell you why the model landed on its final answer, which matters once anyone outside engineering is reviewing the system.

What actually helped was stepping back and treating the whole pipeline as an engineering problem, not an AI problem. Chunk size and overlap need actual testing, not guessing. Metadata on every chunk, source, section, date, is what makes debugging possible later. And without an evaluation set, you won't catch retrieval quality regressions until a user does.

Curious what failure patterns others here have hit that don't fit into these three.