Blog
Before and after the LLM: Dcision as a guardrail for an agent's answer
3 min read
The most common way to use Dcision is before the LLM: a typed decision classifies the message, picks the route and only calls a generative model when it's really needed. That decision costs a fraction of an LLM call and returns a probability with its answer.
The same idea works in a second place: after the LLM. An agent has just written an answer. Before it reaches the customer, something has to ask: can this be sent?
The trouble with generated answers
An LLM writes well, but not always correctly. The usual risks in a support or agent answer are:
- Not grounded: the answer claims something that isn't in the sources the agent was given.
- Data leak: an email, a document number or internal data shows up where it shouldn't.
- Unapproved promise: a discount, a deadline or a refund nobody approved.
- Harmful or off-topic content.
Asking another LLM to "review" the answer produces more text, and your code still has to interpret that text. What you want is a typed answer, with a probability, and an action.
The "LLM output guardrail" template
The new template takes three fields: the user's message, the generated answer and the sources the agent used. It asks four questions:
| Question | Type | What it measures |
|---|---|---|
grounded | Yes/no | Is the answer backed by the sources? |
data_leak | Yes/no | Does it expose personal or internal data? |
policy | Choice | compliant, promise, advice or off_topic |
harmful | Yes/no | Is there harmful content? |
Policies turn the answers into an action:
| Condition | Action |
|---|---|
data_leak at 50% or more | block |
harmful at 50% or more | block |
grounded below 50% | fallback (for example, send a safe reply or ask for more context) |
policy other than compliant | escalate (human review) |
| None of these | continue: the answer can be sent |
The template's sample shows the classic case: the agent promises "a 20% discount for the delay", but the sources say discounts need a manager's approval. The guardrail flags the promise and the decision escalates to a person instead of letting the message out.
Where it fits
message → [ Dcision: route ] → LLM or agent → [ Dcision: guardrail ] → customerBoth decisions are regular API calls. The guardrail takes the generated answer as its state and returns action. Your code only looks at that field: continue sends, block drops, escalate opens a review and fallback uses the safe reply.
Like any Dcision decision, the guardrail has versions, the Playground, a log of every run and the Overview tab. You can see how many answers were stopped, by which rule, and tune the thresholds with data. With destinations, the action can become a webhook to your review queue or a function in your SDK, with no glue code.
Which engine to use
The guardrail runs on any of the three engines: Jev, Laya or OpenAI Decisions. Use Compare engines in the Playground to see how each one judges your sample answers. Then turn on shadow mode to measure agreement on real traffic before you choose.
Summary
| When | Question | Typical action |
|---|---|---|
| Before the LLM | Where does this message go? Does it need an LLM? | Route, answer directly or call the model |
| After the LLM | Can this answer be sent? | Send, block, escalate or use the safe reply |
The LLM generates. Dcision decides what to do with what it generated. Create the decision from Templates → LLM output guardrail.