Keep the toolset small: the hierarchical action space

A natural instinct is to give the agent every tool it might possibly need. Both Manus articles argue against this. Providing an LLM with 100 or more tools leads to context confusion: the model starts hallucinating parameters or calling the wrong tool. Tool descriptions also consume valuable tokens.

Manus solves this with what Part 2 calls a hierarchical action space, organized into three levels:

• Level 1, atomic functions: the model sees a small set of around 20 core tools, such as file_write, browser_navigate, bash, and search. These are stable, which keeps them cache-friendly.
• Level 2, sandbox utilities: rather than adding a dedicated tool for every utility, the model is instructed to call command-line programs through the Bash tool. For example, to use ffmpeg, it runs it on the command line instead of having a special ffmpeg tool. Manus exposes MCP tools through a CLI the agent calls the same way, which keeps those tool definitions out of the context window.
• Level 3, code and packages: for a chain of dependent steps (for example, "fetch a city, get its ID, then get its weather"), do not make three separate model round-trips. Provide a library or function that handles the chain, and let the agent write a short script that calls it.

The thread running through all three levels is the same: keep the number of definitions the model has to reason over small, and push complexity down into the sandbox and into code.