I spent months building a reliability layer for LLM applications — but I'm still trying to understand if I'm solving the right problem

You are absolutely hitting on one of the most painful, unglamorous realities of moving LLM applications from a cool demo to production. Anyone who has built an agentic or heavily structured AI workflow knows the sheer panic of valid JSON that completely breaks a business rule or subtly drops a required key. Writing bespoke validation logic and endless try/catch retry loops around every single prompt is exactly what drains developer time.

The middleware approach you are taking with Linden (ALLOW, WARN, REGENERATE, BLOCK) is a fantastic abstraction framework because it decouples validation from core application logic.

To answer your question about whether you're solving the right problem: yes, but the trick is integration friction. Developers are lazy—if setting up Linden's schemas feels as tedious as writing their own custom Pydantic or Zod validators, they might pass. How are you approaching schema definition or rule creation? Are you letting developers declare these business rules natively in code, or is it managed through an external dashboard?

The problem is 100% real. Right now, most teams are stuck writing brittle, custom Pydantic validators or using a second, cheaper LLM just to grade the output of the first one. It’s expensive, introduces high latency, and still doesn't handle the 'REGENERATE' or 'BLOCK' workflow seamlessly.

One question on Linden’s implementation: how do you manage the latency budget when a validation fails and you trigger a regeneration? In production B2B apps, waiting for a multi-step retry loop can kill the UX.

The problem may be real while still being difficult to sell because reliability is usually noticed only when it fails.

Teams often tolerate unstable outputs during experimentation. The willingness to pay increases when the model becomes part of a customer-facing workflow, a regulated process, a revenue-generating feature, or an internal operation that cannot fail silently.

That suggests the most promising buyers may not be teams building generic AI prototypes. They may be teams already experiencing incidents, regressions, support complaints, evaluation debt, or costly manual review.

Instead of asking whether companies care about reliability, it may be more revealing to ask what they currently do when an output is wrong. Do they rerun it, review everything manually, add rules, switch models, or accept the risk?

The existing workaround often shows both the pain and the available budget.

Which type of LLM application becomes significantly more expensive or dangerous when reliability drops?

This feels like a real problem, but the way it is positioned will probably determine whether customers see it as essential infrastructure or optional technical polish.

Teams building LLM applications care about reliability, but they may describe the pain differently. They might say that outputs change unexpectedly, evaluations are difficult to maintain, prompts break after a model update, costs are unpredictable, or they cannot confidently deploy a new version without manually testing hundreds of cases.

A general “reliability layer” may sound important while still being difficult to purchase. A narrower promise could be easier to understand, such as preventing regressions before deployment, detecting unreliable outputs in production, or showing which model and prompt combination performs best for a particular task.

The best validation may come from asking teams about the last serious LLM failure they experienced. What happened, how did they discover it, how much did it cost them, and what process did they create afterward?

You may already have valuable technology. The remaining challenge could be identifying the failure that is painful and frequent enough for a company to pay to prevent it.

Which reliability problem are your current users most urgently trying to solve?

I think this is becoming one of the most important problems in the LLM space. Building a working demo is relatively easy, but making the system predictable, observable, and reliable enough for real users is a completely different challenge. The difficult part is that “reliability” can mean several things: reducing hallucinations, detecting failures, controlling costs, maintaining consistent outputs, or understanding why a workflow failed. I would be interested to know which of these problems your users care about most. Have you already spoken with teams running LLM applications in production, and what specific failure pushed them to look for a reliability layer?

This feels like a real problem, especially once an LLM app moves beyond a simple demo. What type of failure are your users most worried about: incorrect outputs, unstable behavior, or lack of visibility when something goes wrong?

The interesting opportunity isn't building another validation layer for LLMs—it's becoming the system teams trust when AI outputs carry real business consequences. I'd keep validating whether customers adopt Linden to catch malformed outputs or because it gives them enough confidence to automate decisions they previously couldn't. That's a much more defensible position.