Loading…
Rescue
It passed the demo. It worked in testing. Now it's giving wrong answers, getting stuck in loops, failing silently on 30% of inputs, or behaving differently than it did last month. Something changed, a model update, a knowledge base addition, a new edge case, and the agent can't handle it.
We diagnose what's broken, fix it, and add the evaluation coverage that prevents the same failure from recurring. The diagnostic is a fixed-cost 5-day engagement. Fixes are scoped and quoted after the diagnosis is complete.
Tell us what’s failing.
Six categories of agent failure. Most broken agents have more than one. The diagnosis phase finds all of them.
Your system prompt was tuned against a specific model version. The provider silently updated the model, same name, different behaviour. Outputs that were reliable six weeks ago are now inconsistent. This is one of the most common causes of a "working" agent that gradually degrades. The fix is a combination of evaluation coverage to detect future drift and prompt revisions tuned to the current model version.
The agent calls a function that returns an error, an unexpected schema, or nothing at all. Without proper error handling in the tool execution layer, the agent either hallucinates a response or gets stuck in a loop. We audit every tool call path, add structured error handling, and ensure the agent can recover gracefully when a tool fails.
Conversation history grows until it exceeds the model's context window. The agent starts to lose track of earlier instructions, forget the system prompt details, or produce responses that ignore information it was given. The fix is usually a context management strategy: summarisation, sliding window, or selective history pruning depending on what the agent needs to remember.
The knowledge base the agent retrieves from has grown, changed, or accumulated conflicting content. Embeddings were computed for old content and never updated. Chunk sizes that worked for the original document set don't work for the current one. The agent starts giving confidently wrong answers because retrieval is returning the wrong context.
There is no systematic way to measure whether the agent is working. When it breaks, the first signal is a user complaint. We add an eval harness (a set of representative test cases with expected outputs and a scoring rubric) so you can detect regressions before they reach production.
OpenAI, Anthropic, and Google update their models continuously. Function calling schemas change. JSON mode behaviour shifts. Temperature scaling differs between versions. An agent built tightly against one model version can break silently when the provider rolls out an update. We audit for version-specific assumptions and make the system version-resilient.
Three outputs. The diagnosis tells you what's wrong. The fixes make it right. The eval harness keeps it right.
Root cause diagnosis
We run your agent on a representative set of inputs, document every failure mode we observe, and trace each failure back to its cause. You receive a written report within 5 business days. If there is more than one failure mode, they are each addressed separately, the report doesn't conflate distinct problems into a single vague finding.
Targeted fixes
Every fix comes with a test case that would have caught the bug before it reached production. We don't fix prompts without adding an eval that checks the fix holds. We don't patch tool call handling without adding a test for the failure path. The fixes are the deliverable; the test coverage is the guarantee that the same failure doesn't recur.
Eval harness
An evaluation harness your team can run before deploying prompt changes or model updates. Covers the failure modes we fixed plus a set of representative happy-path queries. If a future model update would break your agent, you'll see it in CI before your users do.
Agent repair is a specific kind of engagement with specific prerequisites. If these apply, we'll tell you upfront.
Agents that have never been tested on real inputs
If the agent was built in a demo environment against hand-picked test cases and has never handled real user queries, the first step is building an evaluation set from real traffic, not debugging failures in the abstract. We can do that work, but it's a different engagement than fixing a known failure mode.
Teams who want the fixes without the test coverage
We won't patch a broken agent without adding evaluation coverage. A fix without a test is just moving the problem forward. If you want targeted repairs with no regression protection, we're not the right fit for this engagement.
Agents built entirely inside no-code platforms
If your agent lives inside Voiceflow, Chatbase, or a similar platform, we can't fix it at the code level, the platform controls the execution environment. We work on code-level agent implementations. If you want to move off the platform, that's a migration engagement.