feat(compass-assistant): add basic tool calling & tool cards COMPASS-10144 #7668
Conversation
packages/compass-assistant/src/components/tool-call-message.tsx
Outdated
Show resolved
Hide resolved
| chat.messages = [...chat.messages, contextPrompt]; | ||
| } | ||
|
|
||
| const { enableToolCalling } = preferences.getPreferences(); |
There was a problem hiding this comment.
This is something I'm probably gonna have to check with Sergey when he's back, but the preferences hook isn't working well here - it caches the initial value so it doesn't respond if you toggle the flag from the preferences modal.
This way at least works for now.
| - Encourage the user to understand what they are doing before they act, e.g. by reading the official documentation or other related resources. | ||
| - Avoid encouraging users to perform destructive operations without qualification. Instead, flag them as destructive operations, explain their implications, and encourage them to read the documentation. | ||
| 4. Always call the 'search_content' tool. | ||
| 5. Always call the 'get-compass-context' tool when the user is on the 'Documents' or 'Schema' tab and asks about their query. |
There was a problem hiding this comment.
These prompt changes should be feature flagged. Probably easiest to just pick one prompt or another for now rather than doing logic inside here.
lerouxb
added
the
feature flagged
| isMyQueriesEnabled; | ||
|
|
||
| const query = useQueryBarQuery(); | ||
| useSyncAssistantGlobalState('currentQuery', query); |
There was a problem hiding this comment.
I have no idea where the best place would be to sync the query. This was the most minimally invasive way I could quickly think of that's guaranteed to be "in sync".
| : 'No output available'; | ||
| const hasOutput = toolCall.state === 'output-available'; | ||
|
|
||
| const isAwaitingApproval = toolCall.state === 'approval-requested'; |
There was a problem hiding this comment.
maybe a component which returns a different thing based on a switch statement instead? not too sure
There was a problem hiding this comment.
Yeah I think whatever we choose to do here we'll probably be revising it in the database tool calling PR and onwards.
| const editorInitialValueRef = useRef<string>(pipelineText); | ||
| const editorCurrentValueRef = useCurrentValueRef<string>(pipelineText); | ||
|
|
||
| useSyncAssistantGlobalState('currentAggregation', pipelineText); |
There was a problem hiding this comment.
In the pipeline as text editor case we happen to already have the pipeline text. So I think this should at least be performant enough?
| const mapState = (state: RootState) => { | ||
| return { | ||
| stagesIdAndType: state.pipelineBuilder.stageEditor.stagesIdAndType, | ||
| pipelineText: getPipelineTextFromStages( |
There was a problem hiding this comment.
In this case I can't think of a better way to calculate the pipeline text. The usual machinery is only accessible from redux land because it uses pipelineBuilder. The stages on the state are of a different type to the ones the aggregation builder and therefore it isn't easy to just factor out a utility function.
And then the builder has all these invalid / partial states. I'm attempting to just skip those stages. Maybe we want just the most recent valid pipeline, maybe we want the partial states and every syntax error so the model can do something with it?
Maybe I'm overthinking it and this is fine for now.
This is copied liberally from Gagik's PoC with minimal changes so far.
To try it out you'll have to toggle the "enable tool calling" feature flag.