RequirementAgent is a declarative AI agent implementation that provides predictable, controlled execution behavior across different language models through rule-based constraints. Language models vary significantly in their reasoning capabilities and tool-calling sophistication, but RequirementAgent normalizes these differences by enforcing consistent execution patterns regardless of the underlying model’s strengths or weaknesses. Rules can be configured as strict or flexible as necessary, adapting to task requirements while ensuring consistent execution regardless of the underlying model’s reasoning or tool-calling capabilities.
Core Problems Addressed
Traditional AI agents exhibit unpredictable behavior in production environments:- Execution inconsistency: Agents may skip critical steps, terminate prematurely, or use inappropriate tools
- Model variability: Different LLMs produce different execution patterns for the same task
- Debugging complexity: Non-deterministic behavior makes troubleshooting difficult
- Production reliability: Lack of guarantees makes agents unsuitable for critical workflows
Value of RequirementAgent
RequirementAgent ensures consistent agent behavior through declarative rules that define when and how tools are used, delivering reliable agents that:
- Complete essential tasks systematically by enforcing proper execution sequences
- Validate data and results comprehensively through mandatory verification steps
- Select appropriate tools intelligently based on context and task requirements
- Execute efficiently and safely with built-in protection against infinite loops and runaway processes
Quickstart
This example demonstrates how to create an agent with enforced tool execution order. This agent will:- First use ThinkToolto reason about the request enabling a “Re-Act” pattern
- Check weather using OpenMeteoTool, which it must call at least once but not consecutively
- Search for events using DuckDuckGoSearchToolat least once
- Provide recommendations based on the gathered information
How it Works
RequirementAgent operates on a simple principle: developers declare rules on specific tools using ConditionalRequirement objects, while the framework automatically handles all orchestration logic behind the scenes. The developer can modify agent behavior by adjusting rule parameters, not rewriting complex state management logic. This creates clear separation between business logic (rules) and execution control (framework-managed).
In RequirementAgent, all capabilities (including data retrieval, web search, reasoning patterns, and final_answer) are implemented as tools to ensure structured, reliable execution. Each ConditionalRequirement returns a Rule where each rule is bound to a single tool:
| Attribute | Purpose | Value | 
|---|---|---|
| target | Which tool the rule applies to for a given turn | String | 
| allowed | Whether the tool can be used for a given turn and is present in the system prompt | Boolean | 
| hidden | Whether the tool definition is visible to the agent for a given turn and in the system prompt | Boolean | 
| prevent_stop | Whether rule prevents the agent from terminating for a given turn | Boolean | 
| forced | Whether tool must be invoked on a given turn | Boolean | 
- Forbidden overrides all: If any requirement forbids a tool, that tool cannot be used.
- Highest priority forced rule wins: If multiple requirements force tools, the highest-priority requirement decides which tool is forced.
- Prevention rules accumulate: All prevent_stoprules apply simultaneously
Execution Flow
- State Initialization: Creates RequirementAgentRunStatewithUnconstrainedMemory, execution steps, and iteration tracking
- Requirements Processing: RequirementsReasoneranalyzes requirements and determines allowed tools, tool choice preferences, and termination conditions
- Request Creation: Creates a structured request with allowed_tools,tool_choice, andcan_stopflags based on current state and requirements. The system evaluates requirements before each LLM call to determine which tools to make available to the LLM
- LLM Interaction: Calls language model with system message, conversation history, and constrained tool set
- Tool Execution: Executes requested tools via _run_tools, handles errors, and updates conversation memory
- Cycle Detection: ToolCallCheckerprevents infinite loops by detecting repeated tool call patterns
- Iteration Control: Continues until requirements are satisfied or maximum iterations reached
Basic Rule Definition
Developers declare rules by creatingConditionalRequirement objects that target specific tools. The framework automatically handles all orchestration:
Complete Parameter Reference
Start with a single requirement and add more as needed.
Curious to see it in action?
Explore our interactive exercises to discover how the agent solves real problems step by step!
Example Agents
Forced Execution Order
This example forces the agent to useThinkTool for reasoning followed by DuckDuckGoSearchTool to retrieve data. This trajectory ensures that even a small model can arrive at the correct answer by preventing it from skipping tool calls entirely.
Creating a ReAct Agent
A ReAct Agent (Reason and Act) follows this trajectory:Think tool after every tool:
For a more general approach, use 
ConditionalRequirement(ThinkTool, force_at_step=1, force_after=Tool, consecutive_allowed=False), where the option consecutive_allowed=False prevents ThinkTool from being used multiple times in a row.ReAct Agent with Custom Conditions
You may want an agent that works like ReAct but skips the “reasoning” step under certain conditions. This example uses the priority option to tell the agent to send an email after creating an order, while callingThinkTool as the first step and after retrieve_basket.
Ask Permission Requirement
Some tools may be expensive to run or have destructive effects. For these tools, you may want to get approval from an external system or directly from the user. The following agent first asks the user before it runs theremove_data or the get_data tool.
Using a Custom handler for Human In the Loop Requirements
By default, the approval process is done as a simple prompt in terminal.
The framework provides a simple way to provide a custom implementation.
Complete AskPermissionRequirement Parameter Reference
If no targets are specified, permission is required for all tools.
Custom Requirements
You can create a custom requirement by implementing the base Requirement class. The Requirement class has the following lifecycle:- An external caller invokes init(tools)method:
- toolsis a list of available tools for a given agent.
- This method is called only once, at the very beginning.
- It is an ideal place to introduce hooks, validate the presence of certain tools, etc.
- The return type of the initmethod isNone.
- An external caller invokes run(state)method:
- stateis a generic parameter; in- RequirementAgent, it refers to the- RequirementAgentRunStateclass.
- This method is called multiple times, typically before an LLM call.
- The return type of the runmethod is a list of rules.
Custom Premature Stop Requirement
This example demonstrates how to write a requirement that prevents the agent from answering if the question contains a specific phrase:More Code Examples
➡️ Check out the following additional examples- Multi-agent system via handoffs.
- ReAct loop in a second.
- Generating structured output output.
- Advanced (detailed configuration).
Python
Explore examples in Python
TypeScript
Coming soon