kundan_s__r

Hi HN,

For those running LLMs in real production environments (especially agentic or tool-using systems): what’s actually worked for you to prevent confident but incorrect outputs?

Prompt engineering and basic filters help, but we’ve still seen cases where responses look fluent, structured, and reasonable — yet violate business rules, domain boundaries, or downstream assumptions.

I’m curious:

Do you rely on strict schemas or typed outputs?

Secondary validation models or rule engines?

Human-in-the-loop for certain classes of actions?

Hard constraints before execution (e.g., allow/deny lists)?

What approaches failed for you, and what held up under scale and real user behavior?

Interested in practical lessons and post-mortems rather than theory.

I’ve been working on Verdic Guard, a validation layer for production LLM systems where prompts, filters, and monitoring aren’t enough.

In many real deployments (fintech, enterprise workflows, agentic systems), the failure mode isn’t latency or cost — it’s hallucinations that sound confident and pass surface checks. Prompt engineering helps, but it doesn’t scale once systems grow long-running, tool-using, or multi-agent.

Verdic takes a different approach:

Define an explicit intent + scope contract for what the model is allowed to output

Validate LLM outputs before execution, not just inputs

Block or flag responses that drift semantically, contextually, or domain-wise

Keep enforcement deterministic and auditable (not “best effort” prompts)

It’s designed to sit between the LLM and your application, acting as a guardrail rather than another model.

This is still early, and I’m especially interested in feedback on:

Where this breaks down in real systems

How teams currently handle hallucinations beyond prompts

Whether deterministic enforcement is useful or too restrictive in practice

Site: https://www.verdic.dev

Happy to answer questions or share implementation details if useful.

I’m building Verdic Guard to explore a problem I kept seeing with LLMs in production.

Models often behave well in demos and short interactions, but once they’re embedded into long, agentic, or real-world workflows, outputs can drift in subtle ways. Prompt tuning, retries, and monitoring help, but they don’t clearly define or enforce what the system is actually allowed to do.

Verdic Guard treats AI reliability as a validation and enforcement problem, not just a prompting problem. The idea is to define intent, boundaries, and constraints upfront, then validate outputs against those constraints before they reach users or downstream systems.

This is early and opinionated. I’m sharing to get feedback from people who’ve dealt with:

LLMs in long-running or agentic workflows

Production reliability vs demo behavior

Guardrails beyond prompt engineering

Project: https://www.verdic.dev

Happy to answer questions or hear critiques.

— Kundan

I’m building Verdic Guard, an experiment around a problem I kept running into while working with LLMs in production.

LLMs usually behave well in demos and short interactions, but once they’re embedded into long, multi-step or agentic workflows, they can drift in subtle ways. Prompt tuning, retries, and monitoring help, but they don’t clearly define or enforce what the system is actually allowed to do.

Verdic Guard explores a different approach: treating AI reliability as a validation and enforcement problem, not just a prompting problem. The idea is to define intent, boundaries, and constraints upfront, and then validate outputs against those constraints before they reach users or downstream systems.

This is still early and opinionated. I’m sharing it to get feedback from people who’ve dealt with:

LLMs in long-running workflows

Agentic systems that accumulate context

The gap between “it worked in testing” and “it’s safe in production”

I’d especially love to hear where this framing breaks down, or if you’ve seen better ways to think about output reliability.

Project: https://www.verdic.dev

Happy to answer questions or learn from critiques

We’ve been working on production LLM systems and noticed a recurring issue: even well-crafted prompts fail under real-world conditions.

We wrote a technical breakdown of the failure modes (intent drift, hallucinations, modality violations) and why monitoring alone doesn’t prevent them.

Would love feedback from people running LLMs in production.

We built Verdic (https://www.verdic.dev/ )after repeatedly running into the same issue while deploying LLMs in production: most AI failures aren’t about content safety, they’re about intent drift.

As models become more agentic, outputs often shift quietly from descriptive to prescriptive behavior — without any explicit signal that the system is now effectively taking action. Keyword filters and rule-based guardrails break down quickly in these cases.

Verdic is an intent governance layer that sits between the model and the application. Instead of checking topics or keywords, it evaluates:

whether an output collapses future choices into a specific course of action

whether the response exerts normative pressure (directing behavior vs explaining)

The goal isn’t moderation, but behavioral control: detecting when an AI system is operating outside the intent it was deployed for, especially in regulated or decision-critical workflows.

Verdic currently runs as an API with configurable allow / warn / block outcomes. We’re testing it on agentic workflows and long-running chains where intent drift is hardest to detect.

This is an early release. I’m mainly looking for feedback from people deploying LLMs in production, especially around:

agentic systems

AI governance

risk & compliance

failure modes we might be missing

Happy to answer questions or share more details about the approach.