Agent reliability
The failures that matter in production are the ones that leave no error. Two of them are now fixed in frameworks you already run.
2 merged upstream fixes · 2 case studies · 4 tools · 1 paper
Claim 01
Two documented reliability defects found by Hermes Labs are now fixed in production agent frameworks, upstream and merged.
In LangChain, binding tools with a forced tool choice while extended thinking was enabled produced a request the Anthropic API rejected. The agent did not degrade; it failed with a 400 that pointed at the model rather than at the binding layer. The fix is merged.
In Microsoft Semantic Kernel, the chat-history truncation reducer removed the system prompt along with old turns once a conversation grew past its window. The agent kept answering, without the instructions it was built around. Nothing in the transcript recorded that the constraint had gone. The fix is merged.
Both are the same shape of problem: the system stayed responsive while the property you were relying on quietly stopped holding. That shape is what the rest of this path is built to catch.
What this does not show
Two fixes are individually documented with public PRs. The site's wider figure of 26 merged upstream contributions includes 24 others that are named by repository only, many of them maintenance and typing work rather than runtime defects. Fixing two defects does not make either framework reliable.
Claim 02
Some agent failures are visible before the agent runs, in the configuration, tool descriptions, and system prompts.
lintlang reads agent configuration statically. There is no model call in its analysis path, so its findings are reproducible and cost nothing to run on every commit.
It reports deterministic findings separately from heuristic ones, which matters because the two carry different weight in a review. A deterministic finding is a fact about the file. A heuristic finding is a suggestion that a human still has to judge.
What this does not show
Deterministic and heuristic findings are reported separately, and neither proves runtime safety. A configuration that lints clean can still fail under load, under adversarial input, or against a model whose behavior has changed.
Claim 03
What an agent actually did during a run can be recorded as evidence rather than reconstructed afterward from memory.
agent-gorgon observes file, network, and subprocess activity while an agent session runs, scores it against policy, and writes forensic records of what happened. The decisions it makes are deterministic, so the same observed behavior produces the same verdict.
The point is not prevention. It is that after an incident there is a record to read, instead of an argument about what the agent probably did.
What this does not show
This is reactive user-space monitoring. It is not a sandbox and not a prevention guarantee: it can tell you a policy was violated, not stop the violation from occurring.
Claim 04
Untrusted input can be probed with a sacrificial model before the primary model is allowed to act on it.
little-canary sends suspect input to a small canary model first and reads how that model responds, on the premise that a cheap model exposed to an attack shows the attack more readily than an expensive one does.
hermes-jailbench covers the adjacent question: whether a known attack pattern that used to fail against your endpoint still fails. It scores without an LLM in the scoring path, so a regression run is repeatable.
What this does not show
little-canary is an experimental security tool whose efficacy and false-positive behavior depend on the models and the evaluation distribution; no such figure is published. hermes-jailbench is a specialist regression tool, not certification — its scorer calibration and live baselines remain open evaluation debt.
Claim 05
The failure class these tools address has a published name and a definition that does not depend on the tools.
Silent Instruction Relaxation — an instruction quietly deprioritized when two cannot both be satisfied — is one of seven modes named in the taxonomy paper, derived from 1,461 controlled experiments conducted primarily on GPT-4o.
The Semantic Kernel defect is a live instance of that mode, found in a framework rather than in a controlled experiment. Naming the class first, then finding an instance in shipping code, is the sequence this path is arguing for.
What this does not show
The taxonomy is descriptive, not a detector, and its corpus was run primarily on one model family. It does not establish how often any of the seven modes occurs in other systems, and it has not completed external peer review.
Every artifact on this path
| Artifact | Kind | What it establishes | Status |
|---|---|---|---|
| LangChain PR 35544 | Fix | A forced-tool-choice crash under extended thinking, fixed upstream | merged |
| Semantic Kernel PR 13610 | Fix | System-prompt deletion in the truncation reducer, fixed upstream | merged |
| lintlang | Tool | Static, zero-LLM checks on agent configuration before runtime | PyPI 0.3.1 |
| agent-gorgon | Tool | Deterministic runtime scoring and forensic records of a session | PyPI 0.1.6 |
| little-canary | Tool | Sacrificial-model probing of untrusted input | PyPI 0.3.3 |
| hermes-jailbench | Tool | Repeatable zero-LLM regression scoring of known attack patterns | source |
| A Taxonomy of Epistemic Failure Modes | Paper | Seven named failure modes from 1,461 controlled experiments | preprint |
If this is the failure you are seeing, tell us the system and the symptom. Book a 30-minute call, or send a note and get a written read instead.