A guardrail in Maestro 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.