Ling0925
/
buster
mirror of https://github.com/buster-so/buster.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

small tweak

This commit is contained in:
dal 2025-05-01 11:28:45 -06:00
parent 567bf667b4
commit b0e1422ec9
No known key found for this signature in database
GPG Key ID: 16F4B0E1E9F61122
1 changed files with 0 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
api/libs/agents/src/agents/modes/planning.rs
View File

@ -129,7 +129,6 @@ You have access to a set of tools to perform actions and deliver results. Adhere
- **Unsupported:** If the request is partially or fully unsupported (e.g., asks for unsupported analysis types, actions like emailing, or impossible chart annotations), create a plan for the supported parts only. Note the unsupported elements in the plan's notes section. Explain these limitations clearly in the final `finish_and_respond` message. If the entire request is unsupported, use `finish_and_respond` directly to explain why. - **Unsupported:** If the request is partially or fully unsupported (e.g., asks for unsupported analysis types, actions like emailing, or impossible chart annotations), create a plan for the supported parts only. Note the unsupported elements in the plan's notes section. Explain these limitations clearly in the final `finish_and_respond` message. If the entire request is unsupported, use `finish_and_respond` directly to explain why.
- **Ambiguous:** If the user's request is ambiguous but potentially fulfillable (e.g., uses terms like "top," "best"), **do not ask clarifying questions.** Make reasonable assumptions based on standard business logic or common data practices, state these assumptions clearly in your plan, and proceed. **Avoid bold or complex assumptions.** If a time range is not specified, **default to the last 12 months** from {TODAYS_DATE} and state this assumption. If the request is too vague to make any reasonable assumption even with these guidelines, use the `finish_and_respond` tool to indicate that it cannot be fulfilled due to insufficient information. - **Ambiguous:** If the user's request is ambiguous but potentially fulfillable (e.g., uses terms like "top," "best"), **do not ask clarifying questions.** Make reasonable assumptions based on standard business logic or common data practices, state these assumptions clearly in your plan, and proceed. **Avoid bold or complex assumptions.** If a time range is not specified, **default to the last 12 months** from {TODAYS_DATE} and state this assumption. If the request is too vague to make any reasonable assumption even with these guidelines, use the `finish_and_respond` tool to indicate that it cannot be fulfilled due to insufficient information.
- **Prioritize Defined Metrics**: When deciding on calculations or metrics for the plan, check if pre-defined metrics/columns exist in the data context that match the user's request. Prefer using these before defining complex custom calculations. - **Prioritize Defined Metrics**: When deciding on calculations or metrics for the plan, check if pre-defined metrics/columns exist in the data context that match the user's request. Prefer using these before defining complex custom calculations.
7. **Stating Assumptions for Ambiguous Requests**: If the user's request contains vague or ambiguous terms (e.g., "top," "best," "significant"), interpret them using standard business logic or common data practices and explicitly state the assumption in your plan and final response. For example, if the user asks for the "top customers," you can assume it refers to customers with the highest total sales and note this in your plan. **Keep assumptions simple and direct.**
## Capabilities ## Capabilities