Wrap-up and next steps

Streaming with output guardrails finished the main implementation path. We built search and the agent loop, then added input and output guardrails. Along the way we covered multiple checks, cancellation, and streaming.

We close by reviewing which guardrail belongs where and deciding what to add to your own agent. We avoid one giant policy prompt and instead put small checks where they can prevent real harm.

Key takeaways

Take these rules into your own agent:

• Use input guardrails when the request shouldn't reach the main agent.
• Use output guardrails when the request is allowed, but the answer needs a safety check.
• Use multiple guardrails when policies have different owners or failure messages.
• Use concurrent execution when guardrail latency would hurt the user experience.
• Keep input and output guardrails separate, so input guardrails classify the request and output guardrails classify the answer.
• Wrap framework agents instead of modifying their internals. If a framework owns the tool loop, run guardrails before and after agent.run(...).

Framework agents

Many agent frameworks hide the loop that calls the model, calls tools, and sends tool results back to the model. That's fine, because we don't need to hook into the internal loop to add the guardrails from this workshop.

Treat the framework agent as a RunnableAgent:

guarded_agent = GuardedAgent(
    agent=framework_agent,
    input_guardrails=input_guardrails,
    output_guardrails=output_guardrails,
)

This works for the same reason the workshop code works. Input guardrails run before the framework agent starts. Output guardrails run after the framework agent returns an answer. The framework can keep its own ReAct loop or tool loop inside.

The same structure works outside Python. In TypeScript, the names change, but the control flow is the same. Start or await the guardrail task. Await the agent task. Then decide what to show.

Hallucinations

Output guardrails can catch some groundedness problems, but they aren't the main tool for fighting hallucinations.

A hallucination check usually needs more work than a simple classifier. It looks at the answer, searches the source material, and compares the answer with the retrieved evidence. That's closer to a verification or citation workflow than a single guardrail call.

For this workshop, the grounding guardrail catches obvious policy inventions. For a larger system, add tests around retrieval quality and source attribution, and add answer verification too. Don't expect one output guardrail to solve hallucinations.

When the evidence isn't enough, the answer should say that directly. A good fallback is "I don't have enough context to answer." If the system can tell what's missing, say which source or policy it would need to answer safely.

Next steps

To apply the workshop to your own agent:

• Write down the requests your agent should refuse.
• Decide which refusals belong before the agent runs.
• Decide which answers need a final safety check.
• Add test prompts for every guardrail decision.
• Measure latency before and after adding model-based checks.