Command Categories

[Boostrix]

Duplicates

• I have searched the existing issues

Summary 💡

Question: Why don't we put certain/some commands into optional categories to free up the namespace / prompt?

The basic idea is to support putting commands into matching categories.
These categories would serve four main purposes:

• provide additional meta information to the LLM
• clean up the prompt by allowing the LLM to switch/cd into a certain category and select from its arguments
• use a namespace based notation to encode additional semantics to the LLM
• reduce the likelihood of hallucinations by narrowing down relevant commands

Depending on the step in question, the LLM might be in an excellent position to judge what sort of commands are relevant to it, so it could just as well "subscribe" to a list (category) of certain commands. Imagine this like a directory/folder in a file system, with individual commands being the "files".

This would allow us to neatly organize commands, while also reducing the default prompt significantly - at the mere cost of providing new commands to list/browse available categories and switch/cd into those.

Related:

• Adaptability Challenge : Dynamic prompting #3937

Examples 🌈

• when browsing, file system utilities might be completely irrelevant
• likewise, when working with files, web browsing related commands may be irrelevant
• the commands for inter-agent messaging are only relevant in multi-agent setups

We can probably free up quite a bit of space by coming up with dynamic categories of commands, and at the same time reduce hallucinations that way, too.

Motivation 🔦

@Pwuts asked for this to be tracked separately on github:

• https://discord.com/channels/1092243196446249134/1097204317125091328/1114975269149749431
• https://discord.com/channels/1092243196446249134/1097204317125091328/1115156144894246943
• https://discord.com/channels/1092243196446249134/1097204317125091328/1115992784294379620

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[Boostrix]

This would be one of those few issues that could help us make better use of the context window, while also offering a narrowed-down list of options to the LLM to pick from. We could basically encode/provide surrounding context to the LLM by reducing its set of options to certain command categories. This could possibly be dynamically adapted, based on the history/results of previously executed commands.

I would sugest to label this accordingly, because making better use of the context window should be one of topmost goals probably ?

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[Pwuts]

Related: #6271

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[github-actions]

This issue was closed automatically because it has been stale for 10 days with no activity.