RequirementsAgent as proposed basis for all agents

[imolloy]

We recently released our RequirementAgent, an experimental new agent that is flexible and gives developers more control over their agents' behavior, making them more reliable. Depending on user feedback, we plan to deprecate our other agents (ReActAgent, ToolCallingAgent, etc.) in favor of this simpler, and more flexible design.

Why is this design necessary

Agent design is often a balance autonomy, placing the agent and the LLM in charge, and control, where the developer more strictly defines the agent behavior at increased development cost and reduced autonomy, such as by defining complex state graphs. Many developers will craft increasingly complex prompts instructing the agent on its goals, order of tasks, desired output formats, and other constraints. The results are often poor: instructions can be ignored or misinterpreted, tools skipped, and actions executed out-of-order, excessively, or not at all, and behavior may be vary significantly from one model to the next.

Requirements Agent Approach

The RequirementsAgent takes a simple approach: it adds declarative statements that limit when a tool can—and cannot—be executed, and allows forcing tool call in certain circumstances. Within these constrains, the agent maintains it's autonomy, planning, and reasoning capabilities and can freely adapt to the evolving execution trajectory. At ever step, the agent is informed which tools are available in the current state.

We like to think of these requirements as constraints of obligations for the agent, and provide a powerful abstraction. Take a look at the documentation to become more familiar with this new agent class, and let us know what you think of the current design and help us improve it. Here are some open questions we're currently thinking about:

Open questions

• Are there any use cases or workflows where the requirements aren't expressive or powerful enough?
• Can we simplify the specification of the requirements, and is the design and implementation clear
• Have you identified any issues that we need to resolve (open an issue!)
• Can we use the obligations to implement guardrails, acting as filters or transformers to the tools and LLMs called
• Do we need to define a different set of interfaces (e.g., a passthrough, filter, or transformation and not performing a tool binding)
• Do we need to check for the satisfiability of the constraints (current requirements might define a conflict that cannot be satisfied)
• Are there additional constrains that are required or additional conditions? (e.g., force_before that could rollback and replay the state)
• Do we need a pluggable constraint resolution system more powerful than priority?
  • e..g., Deny overrides
  • e.g., Allow overrides
  • e.g., Majority vote
• Should we invoke constrains automatically based on metadata (e.g., an MCP tool, ACP agent, etc.)
  • e.g., readOnly=False requires AskPermissionRequirement
  • e.g., idempotent=True implies can_be_called_in_a_row=False