-
Notifications
You must be signed in to change notification settings - Fork 5.9k
feat: introduce PlanningConfig for enhanced agent planning capabilities #4344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: lorenze/feat/plan-execute-pattern
Are you sure you want to change the base?
feat: introduce PlanningConfig for enhanced agent planning capabilities #4344
Conversation
This update adds a new PlanningConfig class to manage agent planning configurations, allowing for customizable planning behavior before task execution. The existing reasoning parameter is deprecated in favor of this new configuration, ensuring backward compatibility while enhancing the planning process. Additionally, the Agent class has been updated to utilize this new configuration, and relevant utility functions have been adjusted accordingly. Tests have been added to validate the new planning functionality and ensure proper integration with existing agent workflows.
This commit modifies the Agent class to conditionally call the handle_reasoning function based on the executor class being used. The legacy CrewAgentExecutor will continue to utilize handle_reasoning, while the new AgentExecutor will manage planning internally. Additionally, the PlanningConfig class has been referenced in the documentation to clarify its role in enabling or disabling planning. Tests have been updated to reflect these changes and ensure proper functionality.
| self.state.plan = None | ||
| self.state.plan_ready = False | ||
|
|
||
| self._kickoff_input = inputs.get("input", "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated state reset code in invoke and ainvoke
Medium Severity
The state reset logic (clearing messages, resetting iterations, plan state, etc.) is duplicated verbatim in both invoke (lines 1030-1040) and ainvoke (lines 1117-1128) methods. This should be extracted into a helper method like _reset_state(inputs).
| self._state.iterations = value | ||
|
|
||
| @start() | ||
| def generate_plan(self) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greysonlalonde most of the work goes here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| # Backward compatibility: append plan to task description | ||
| # This can be removed in Phase 2 when plan execution is implemented | ||
| if self.task and self.state.plan: | ||
| self.task.description += f"\n\nPlanning:\n{self.state.plan}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generated plan not used in kickoff execution path
Medium Severity
When using agent.kickoff() with planning enabled, the generate_plan() method generates a plan and stores it in self.state.plan, but the plan is never incorporated into the task execution prompt. The condition if self.task and self.state.plan: fails because self.task is None for the kickoff path. This results in an extra LLM call being made to generate a plan that is then discarded and never used to influence the actual task execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
intential for now. we are progressing this through smaller prs - the goal here was to focus on the generated plan


This update adds a new PlanningConfig class to manage agent planning configurations, allowing for customizable planning behavior before task execution. The existing reasoning parameter is deprecated in favor of this new configuration, ensuring backward compatibility while enhancing the planning process. Additionally, the Agent class has been updated to utilize this new configuration, and relevant utility functions have been adjusted accordingly. Tests have been added to validate the new planning functionality and ensure proper integration with existing agent workflows.
Note
Medium Risk
Modifies agent pre-execution planning flow and prompt content across both legacy and experimental executors, which can change LLM behavior and downstream task prompting. Backward-compatibility shims help, but plan injection and new planning state fields may affect existing integrations and tests.
Overview
Adds configurable agent planning via new
PlanningConfig(exported fromcrewai) and deprecatesreasoning/max_reasoning_attemptsin favor ofplanning_config(with warnings and auto-migration).Updates both execution paths to use a unified planning check (
Agent.planning_enabled): legacyhandle_reasoning()now appendsPlanning:to task descriptions, whileexperimental.AgentExecutorintroduces a new initialgenerate_plan()phase that storesplan/plan_readyin executor state and (for now) also appends the plan to the task for compatibility.Refactors
utilities/reasoning_handler.pyto support planning for bothTaskandkickoff()inputs, allow custom prompts/LLM/max steps/attempts via config, tighten function-call schema, and adds newplanningi18n prompts (and simplifies existingreasoningprompts). Extensive tests and VCR cassettes are updated/added to cover planning config, backward compatibility, and plan generation behavior.Written by Cursor Bugbot for commit b7d5a4a. This will update automatically on new commits. Configure here.