TL;DR: A pre-gate runs before the agent and blocks work that should never start. A post-gate runs after the agent and blocks results that should never leave. The model handles the ambiguous middle. The harness protects both ends.
What Are Pre-Gates and Post-Gates in an AI Agent Harness?
One of the easiest mistakes in agent development is assuming the model should make every decision.
It shouldn’t.
Some decisions require reasoning.
Others are just rules.
If a customer has opted out of SMS, you don’t need an LLM to decide whether you’re allowed to send another message.
If an appointment API failed, you don’t need an LLM to debate whether the customer should be told they’re booked.
Those are deterministic facts.
This is where pre-gates and post-gates come in.
A pre-gate runs before the agent is allowed to reason or act.
A post-gate runs after the agent has done its work but before the result is allowed to become a real-world action or customer-facing response.
Together, they create hard boundaries around a probabilistic system. They are part of the agent harness, the runtime around the model.
What Is a Pre-Gate?
A pre-gate checks whether the agent should be allowed to proceed in the first place.
RuntimeInput
↓
Pre-Gates
↓
Agent
↓
Tools
↓
Response
Before spending tokens or giving the model an opportunity to act, the harness checks conditions that software can answer more reliably.
For a conversational agent, that might include:
- Has the customer opted out?
- Has a human taken over this conversation?
- Is the conversation already closed?
- Is consent required?
- Are we outside permitted messaging hours?
- Has a usage or messaging cap been reached?
- Is this action available in the current workflow state?
If one of those conditions blocks execution, the agent does not need to reason about it.
The harness already knows the answer.
Why Not Just Put Those Rules in the Prompt?
You can.
And for many rules, you should explain them to the model as well.
But instructions and enforcement are different things.
Consider this system prompt: never send another marketing message after the customer opts out.
That is a reasonable instruction.
But if your database already contains contact.opted_out = True, why ask the model to respect that fact every time?
Enforce it.
Pythondef pre_gate(state):
if state.contact.opted_out:
return {
"allowed": False,
"reason": "CONTACT_OPTED_OUT",
}
return {"allowed": True}
Now the rule does not depend on model interpretation.
The prompt can explain the policy.
The gate guarantees it.
Pre-Gates Save More Than Just Risk
Pre-gates also improve efficiency.
Suppose a conversation has already been handed to a human.
Without a gate, your system might build the full context, retrieve knowledge, call the LLM, let it select tools, generate a response, and eventually realize it shouldn’t send anything.
That’s wasted latency and cost.
A simple check can stop the entire runtime immediately.
This becomes meaningful when you’re processing thousands or millions of agent turns.
What Is a Post-Gate?
A post-gate checks the result after the agent has reasoned or acted.
RuntimeInput
↓
Pre-Gates
↓
Agent Loop
↓
Tool Execution
↓
Composer
↓
Post-Gates
↓
Send
Pre-gates ask: should this run?
Post-gates ask: should this result be allowed through?
That’s a different problem. It sits next to tool contracts: the contract says what a tool returns, and the post-gate decides whether that result may become a customer-facing claim.
A Simple Post-Gate Example
Imagine an agent tries to book an appointment.
The tool returns:
Python{
"ok": False,
"error": "slot_unavailable",
}
But the generated response says the customer is confirmed for Tuesday at 2 PM.
That’s a serious failure.
The agent intended to make the booking.
But intent is not evidence.
A post-gate can catch that.
Pythondef post_gate(response, tool_results):
claimed_booking = "confirmed" in response.lower()
booking_succeeded = any(
result.get("appointment_created") is True
for result in tool_results
)
if claimed_booking and not booking_succeeded:
return {
"allowed": False,
"reason": "UNVERIFIED_BOOKING_CLAIM",
}
return {"allowed": True}
The exact implementation can be much more sophisticated.
The principle is the important part: don’t let the model convert an intended action into a claimed fact unless the system has evidence that it happened.
Pre-Gates and Post-Gates Solve Different Failures
Pre-gates protect the entrance.
Post-gates protect the exit.
Pre-gates protect state. They prevent the agent from operating when the current conditions don’t permit it.
Post-gates protect outcomes. They prevent invalid agent behavior from escaping into the real world.
You generally need both. The loop is where the model decides. The harness is where those decisions are allowed to become action.
Common Pre-Gates for Conversational Agents
For customer-facing agents, some gates are especially useful.
Opt-out gate. If the customer has opted out, block messaging that is no longer permitted. This is much safer than relying on the model to interpret an opt-out flag buried somewhere in its context.
Human takeover gate. Once a human agent takes control, the AI should stop replying unless the workflow explicitly allows otherwise. Otherwise you get the unpleasant situation where the customer is receiving messages from both the person and the AI.
Business-hours gate. Some businesses want agents operating around the clock. Others don’t. If sending or performing an action is prohibited outside a configured window, that’s straightforward runtime logic.
Consent gate. Certain channels or use cases require consent before messaging or performing particular actions. Again, this is usually better treated as a hard condition than a suggestion.
Terminal-state gate. If the conversation is already completed, cancelled, closed, or otherwise terminal, don’t accidentally restart the workflow because the latest message confused the model.
Common Post-Gates for Conversational Agents
The exit side has a different set of problems.
No false completion claims. The agent should not say the customer is booked, the refund has been issued, the order has been cancelled, or the account has been updated unless the relevant action actually succeeded.
No contradictory calls to action. An agent can occasionally generate something like “I’ve booked you for Wednesday. Would you like me to book Wednesday?” That sounds ridiculous, but it’s exactly the kind of inconsistency a probabilistic system can produce. A post-gate can detect incompatible states before the message leaves.
No empty responses. Tool-heavy agent turns can occasionally finish without useful customer-facing text. A production runtime should not send an empty message just because the agent forgot to compose one.
No policy-breaking output. Even if the model successfully completes its internal work, the final output may still violate a business rule. A post-gate gives you one more opportunity to stop it.
Gates Are Not the Same as Guardrails
People often use these words interchangeably.
I think it’s useful to distinguish them.
Guardrails are the broader category. A guardrail might be prompt instructions, tool permissions, input validation, output moderation, verification, schema enforcement, pre-gates, or post-gates.
A gate is specifically a decision point that allows, blocks, or reroutes execution.
So every gate is a guardrail.
Not every guardrail is a gate.
Gates Should Be Deterministic Whenever Possible
The whole value of a gate is that it reduces unnecessary model judgment.
A bad gate asks an LLM whether this customer should be allowed to receive another message when your database already contains the answer.
A better gate is the opt-out check above: if the contact opted out, block.
Use an LLM when the decision genuinely requires semantic understanding.
Use code when you already know the rule.
This is one of the most important design principles in a good agent harness.
Don’t Turn Every Business Rule Into a Gate
The opposite mistake is making the entire agent deterministic.
Then you’ve rebuilt a workflow engine.
The customer says: can we do sometime later next week instead?
Figuring out what that means may require context.
The agent might need to reason about which appointment they’re discussing, what “later” refers to, which dates count as next week, and whether another preference was mentioned earlier.
That’s where the model is useful.
But once the system has resolved the intended appointment and time window, deterministic software can enforce availability and booking requirements.
Good agent architecture uses AI where ambiguity exists and deterministic logic where certainty exists.
Where Gates Sit in Myna’s Harness
In Myna, the agent loop is deliberately surrounded by deterministic controls.
RuntimeChannel
↓
State Builder
↓
Pre-Gates
↓
Agent Loop
↓
Tool Execution
↓
Response Composer
↓
Verifier
↓
Post-Gates
↓
Send
That architecture is intentional.
We don’t want the model to be responsible for policing itself at every stage.
The agent gets freedom inside defined boundaries.
The harness owns the boundaries. The runtime reference is that turn written out: context, policy, approved tool calls, confirmed state, then a reply.
Why Pre-Gates Matter Before the Model Runs
There is another subtle benefit here.
A rule can influence the model simply by being present in context.
Sometimes you don’t even want that.
If a human takeover is active, there is no reason to send the entire conversation to the model just so it can generate a message that will never be used.
Stop earlier.
The fastest and safest model call is sometimes the one you never make.
Why Post-Gates Matter Even With a Verifier
Myna also uses verification.
So why have post-gates too?
Because verification and deterministic enforcement solve different problems.
A verifier can evaluate more nuanced behavior. Did the response match policy? Does the answer conflict with evidence? Did the agent fulfill the objective?
A deterministic post-gate can enforce absolute invariants. No successful booking tool result means no booking confirmation.
There is no reason to ask another model to debate that.
This layered approach matters.
You don’t want one safety mechanism responsible for everything.
Gates Make Agent Failures Easier to Understand
Another advantage is observability.
Instead of seeing “agent failed,” you can see PRE_GATE_BLOCKED with reason HUMAN_TAKEOVER, or POST_GATE_BLOCKED with reason BOOKING_NOT_VERIFIED.
That makes production debugging significantly easier.
It also lets you measure why conversations are being stopped or rerouted.
Don’t Hide Gate Failures From the Customer
Blocking an action does not mean the conversation should become robotic.
Suppose the customer requests something your policy doesn’t permit.
Internally, the harness might produce ACTION_BLOCKED_POLICY_17.
The customer should not see that.
The composition layer can turn it into something appropriate: I can’t make that change directly, but I can create a ticket for the team to review it.
This is why the separation between execution and composition matters.
The gate protects the system.
The composer protects the customer experience.
Pre-Gates and Post-Gates Make Agents More Autonomous, Not Less
At first, deterministic restrictions can sound like you’re limiting the intelligence of the agent.
I think the opposite is true.
The more reliable your boundaries are, the more freedom you can safely give the model inside them.
If your agent literally cannot issue an invalid refund, you can be more comfortable letting it reason autonomously about when a refund is appropriate.
If it cannot confirm an unsuccessful booking, you can let it handle the scheduling conversation more naturally.
Good constraints create usable autonomy.
The Short Answer
Pre-gates run before the AI agent and block actions or execution that should never begin.
Post-gates run after the agent and prevent invalid results from reaching the customer or real world.
Use pre-gates for opt-outs, consent, human takeover, hours, and terminal states.
Use post-gates for false success claims, invalid tool outcomes, contradictory calls to action, empty replies, and hard output-policy violations.
The agent handles the ambiguous middle.
The harness protects both ends.
That’s one of the simplest ways to make a probabilistic AI system behave like reliable production software.
Related:
