Thoughts on the new 'Guardrails' module? Is it more than just a prompt wrapper?

So everyone's buzzing about the new "Guardrails" module. The marketing line is it moves beyond simple prompt engineering to provide "enterprise-grade" safety and control. Having poked at it for a few days, my cynical take is that it's a moderately sophisticated prompt wrapper with some extra knobs, but calling it a new architectural layer feels generous.

The core of it seems to be a pre-processing and post-processing pipeline you can define with YAML. It does things like check for PII, enforce output schemas, and scan for policy violations. But let's be real—most of these are just LLM calls gated behind a declarative config. The "content moderation" guardrail is literally sending your input/output through another model (or a regex list) and checking for bad words. We built this internally two years ago and called it a "filter proxy."

Where it gets interesting, and where they might have a point, is the statefulness. It can maintain a history of violations per deployment and supposedly integrate that back. I tried to make it enforce a strict JSON schema on a code-generation agent. The config looks clean:

```yaml
guardrails:
- name: enforce_json_schema
type: output_schema
config:
schema:
type: object
properties:
code:
type: string
explanation:
type: string
validation_action: reject_and_retry
```

But when the agent hallucinated a non-JSON reply, the "reject_and_retry" just re-prompted the *main* agent with a system message append. It didn't trigger a separate correction pathway or switch models. The failure mode was a loop until max retries. This is the same old "hope the LLM listens better this time" pattern, just now a config block.

Is it more than a wrapper? Marginally. The centralized policy management and audit log are useful ops features we'd otherwise have to script. But if you're expecting it to magically solve jailbreaking or enforce complex business logic without writing more code, you'll be disappointed. It's a framework for your existing prompt hacks, not a replacement for them.

I'm curious if anyone has stress-tested it against actual adversarial prompts or used it to enforce something genuinely complex, like a multi-step approval chain before executing a tool. Does the "contextual grounding" guardrail actually pull in fresh RAG data, or is it another cleverly disguised system prompt?