Skip to content

Conversation

@lorenzejay
Copy link
Collaborator

@lorenzejay lorenzejay commented Feb 2, 2026

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 from crewai) and deprecates reasoning/max_reasoning_attempts in favor of planning_config (with warnings and auto-migration).

Updates both execution paths to use a unified planning check (Agent.planning_enabled): legacy handle_reasoning() now appends Planning: to task descriptions, while experimental.AgentExecutor introduces a new initial generate_plan() phase that stores plan/plan_ready in executor state and (for now) also appends the plan to the task for compatibility.

Refactors utilities/reasoning_handler.py to support planning for both Task and kickoff() inputs, allow custom prompts/LLM/max steps/attempts via config, tighten function-call schema, and adds new planning i18n prompts (and simplifies existing reasoning prompts). 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.

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", "")
Copy link

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).

Fix in Cursor Fix in Web

self._state.iterations = value

@start()
def generate_plan(self) -> None:
Copy link
Collaborator Author

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

Copy link

@cursor cursor bot left a 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}"
Copy link

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.

Fix in Cursor Fix in Web

Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants