Skip to main content
A guardrail in Mantle is not advice to the model. It is a rule the framework enforces itself, in the runtime loop, before and after the LLM ever gets a say. This is what lets you trust an agent with an expensive action: the guarantee doesn’t depend on the model choosing to follow it.

​
The division of labor

By default the LLM has full freedom. You write plain-language instructions and it runs the conversation. Every guardrail you add moves one specific decision out of the model’s hands and into the framework’s. Nothing else about the skill changes.

​
How each guardrail is enforced

Because enforcement happens in the loop, a guardrail isn’t something the model can argue its way past:
  • Gating (requires:). A tool whose condition isn’t met is removed from the LLM’s tool list. It can’t call a tool it can’t see. See Tool constraints.
  • Scoped instructions (if:). Non-matching paragraphs are stripped from the prompt, so the LLM never sees the wrong path. See Scoped instructions.
  • Ordered blocks. The framework holds a step pointer and won’t advance out of order. Deterministic steps run with no model call at all. See Ordered blocks.
tool_constraints are enforced regardless of who triggers the tool. A tool whose requires: is unmet is removed from the LLM’s tool list, and an ordered-block execute_tool: step runs the same gate before calling the function, holding the step until the condition holds.

​
Progressive control

The point of all this is that you don’t choose between “autonomous” and “scripted” up front. You start loose and tighten only where the business needs a guarantee. The more you add, the more is guaranteed and the less is left to the model’s judgment.

​
Reference

For the exact framework-versus-LLM boundary at each control level, plus the rules that govern how they interact, see the Constraint Table reference.