Rust + Python
fast-langgraph
Use it to accelerate LangGraph checkpoints and state.
Solution · AI project rescue
Stabilise an AI project that is losing confidence
When a pilot is late, unreliable or quietly losing its sponsors, we diagnose the actual cause from evidence and stabilise it with measured, reversible changes — or tell you plainly that it should stop.
Usually owned by: The engineering lead or sponsor accountable for a struggling AI initiative.
The situation
Recognise where you are
Troubled AI projects tend to look alike from the outside: a pilot that was “nearly ready” for two quarters, accuracy that seems to get worse as more users arrive, a growing list of special cases handled in prompts, and a team that has started to distrust its own measurements.
The causes are usually less mysterious than they appear. Common ones are an evaluation set that no longer represents real traffic, retrieval returning plausible but wrong context, retries that duplicate side effects, state that is lost between steps, or a cost and latency profile that forced compromises nobody wrote down.
A rescue begins by restoring a trustworthy picture of what is happening. Only then do we change things — in small, reversible steps, each one measured against the baseline, so the team and its sponsors can see confidence returning for evidence-based reasons.
How we approach it
From the system you have to the result you need
- 1
Restore measurement
Rebuild or repair the evaluation set from real traffic and known failures, so changes can be judged against something everyone trusts.
- 2
Classify failures
Separate retrieval, reasoning, tool, state, data and integration failures, and count them. Most rescues are dominated by two or three categories.
- 3
Fix by impact
Address the largest failure categories first with targeted, reversible changes, measuring each against the baseline before moving on.
- 4
Decide openly
Present the measured trajectory to sponsors with a clear recommendation: continue with a defined scope, change approach or stop.
Scope
What we need, what you receive
- What we need from you
- Access to the code, prompts, configuration and deployment of the current system.
- Logs or traces of real usage, with sensitive fields removed if necessary.
- The original goals and any acceptance criteria, however informal.
- Time with the people who built it — their knowledge of past decisions is valuable.
- What you receive
- A trustworthy baseline and failure taxonomy for the current system.
- A prioritised set of fixes, implemented and measured against the baseline.
- A regression suite that prevents fixed failures from returning.
- A written recommendation for sponsors: continue, change course or stop, with the evidence.
- Not included
- Assigning blame for past decisions — the work is about the system, not the people.
- Rewriting the system from scratch unless the evidence clearly supports it.
- Promising a fixed accuracy figure before the failure taxonomy is understood.
- How success is measured
- The team agrees on one baseline and trusts how it is measured.
- The largest failure categories are reduced measurably and do not regress.
- Sponsors receive a recommendation they can act on.
How to buy it
Start with a bounded first step
Decision guide
The questions buyers ask, in the order they ask them
01
Is our AI project failing, or just immature?
Immature projects improve when you fix things; failing ones do not, because the fixes are not aimed at the real causes. If changes are not moving a trusted measure, the measurement or the diagnosis is the problem.
02
Should we pause the project while we work this out?
Often not. A rescue can run alongside a limited pilot, using its traffic as evidence. Pausing is sensible when the system is causing harm or cost that outweighs what is being learned.
03
Do we need to replace the model or the framework?
Rarely as a first step. Most rescue findings sit in retrieval, state, tools and evaluation. Replacing the model changes many variables at once and makes the picture harder to read.
04
What would a rescue cost?
Rescues usually start with a fixed-fee readiness review focused on diagnosis, then move to a fixed-scope sprint against the largest failure categories. Indicative ranges are published on the engagement pages.
Evidence
What you can check before trusting us
Client results and public engineering are kept apart; the evidence method explains why.
Client delivery
No client case study is published for this situation yet. See all case studies.
Neul Labs public engineering
Neul-owned work you can inspect — not client case studies or warranties, and never a requirement.
Rust + Python
fast-litellm
Use it to speed up LiteLLM without changing your code.
Python
ormai
Use it to let an agent query a database, safely.
Python
memorg
Use it to add durable memory to an LLM chat app.
Further reading
A good fit
- There is an existing AI system with real users or a real pilot.
- The sponsor wants an evidence-based decision, including the possibility of stopping.
- The original team is available for at least some knowledge transfer.
Not a good fit
- The decision to cancel has already been made and only needs justifying.
- There is no access to the code, logs or people behind the system.
- The expectation is a guaranteed turnaround regardless of what the diagnosis finds.
Questions people ask
How quickly can you start on a struggling project?
A scoping call can usually happen within days. The review itself starts once access is arranged; the access route is often the slowest step, so it is worth raising early.
Will you work alongside our existing team?
Yes. Rescues go best with the original builders involved. Their context saves time and the improvements need to be theirs to maintain.
What if the recommendation is to stop?
Then you receive the evidence for that recommendation and a summary of what was learned. Stopping a project on evidence is a better outcome than continuing one on hope.
Other situations we help with: launch production ai · automate a business workflow · make ai useful for a team · get an ai system approved.
Stabilise an AI project that is losing confidence
Left alone, a struggling AI project consumes engineering time, erodes internal trust in AI generally and often ends with a decision made on politics rather than evidence.
Scope this with us