The "agent" function description is absurdly long #12272

What happened?

Currently is about 2000 tokens, and that – without the parameters descriptions, and without agents names/descriptions. It is absurdly long for something sent on every single turn. Nothing but a senseless waste of the token budget.

Launch a new agent to handle complex, multi-step tasks autonomously.
The Agent tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it. ...(list of agents names and their descriptions were omit here)... When using the Agent tool, specify a subagent_type to select which agent type to use. If omitted, the general-purpose agent is used. Top-level regular subagents run in the background by default and report their results through a completion notification; set run_in_background: false when you need a regular subagent's result inline before continuing. A fork (subagent_type: \"fork\") inherits the parent conversation context. A background fork's result arrives through a completion notification. Forks inherit the full parent conversation by default; set fork_turns to a positive integer string to limit inheritance to that many recent real user turns. Set fork_tools to restrict which of the still-visible parent tools the fork may execute, or fork_profile to load the same restriction from a project profile.\n\nWhen NOT to use the Agent tool:\n- If you want to read a specific file path, use the read_file tool or the glob tool instead of the agent tool, to find the match more quickly\n- If you are searching for a specific class definition like "class Foo", use the grep_search tool instead, to find the match more quickly\n- If you are searching for code within a specific file or set of 2-3 files, use the read_file tool instead of the agent tool, to find the match more quickly\n- Other tasks that are not related to the agent descriptions above\n\n\n\nUsage notes:\n- Always include a short description (3-5 words) summarizing what the agent will do\n- Delegate only concrete, bounded tasks that can run independently.\n- Keep immediate critical-path work local when your next action depends on it.\n- Do not duplicate work between the parent and subagents.\n- Run agents concurrently only when their tasks are independent. For code changes, give concurrent agents disjoint write scopes; launch them in a single message with multiple tool uses.\n- A background agent reports its result through a completion notification in a later turn. A foreground regular agent returns its result inline. Agent results are not visible to the user, so relay the relevant outcome in your response.\n- While background agents run, continue meaningful non-overlapping work. Wait for an agent only when its result blocks the next required step.\n- Reuse an existing background agent for related follow-up work instead of launching a duplicate: call list_agents to inspect the current roster, then call send_message with its task_id. Running agents receive the message at the next tool-round boundary; paused agents resume with it as their first continuation instruction; completed agents continue on their resident runtime when available and otherwise revive from their retained transcript. If the task is no longer retained or cannot be resumed or revived, launch a new agent.\n- Provide clear, detailed prompts so the agent can work autonomously and return exactly the information you need.\n- Regular subagents and named teammates start without parent conversation history. Only fork agents accept fork_turns, fork_tools, and fork_profile; omit fork_turns for the full conversation and omit both restriction parameters to allow every inherited tool except ask_user_question. Regular subagents do not receive that tool either.\n- Treat the agent's output as evidence, not as automatically correct. Verify factual claims, review code changes, and run relevant checks before integrating or relaying the result.\n- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent\n- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.\n- If the user asks for agents "in parallel", group independent launches in a single message with multiple Agent tool use content blocks. Do not parallelize overlapping code changes.\n- Top-level regular subagents run in the background by default. Set run_in_background: false when the current turn must wait for the result before continuing. Nested agent launches run in the foreground and return to their direct parent; an explicit run_in_background: true request is rejected because nested agents cannot receive background completion notifications. Unnamed caller-owned working_dir launches run in the foreground: an explicit run_in_background: true request is rejected, while a configured background default (background: true in a subagent definition) is rejected at the top level and downgraded to the foreground for nested launches; named teammates may use one, but must be shut down before it is removed.\n- You can optionally set isolation: \"worktree\" to run the agent in a temporary git worktree, giving it an isolated copy of the repository. The worktree is automatically cleaned up if the agent makes no changes; if changes are made, the worktree path and branch are returned in the result so you can review or merge them.\n\n## Working with background agents\n\nDon't peek. Do not read or tail a background agent's output file while it runs. You get a completion notification; trust it. Reading the transcript mid-flight pulls the agent's tool noise into your context, which defeats the point of delegating.\n\nDon't race. After launching a background agent, you know nothing about what it found. Never fabricate or predict its results in any format — not as prose, summary, or structured output. The notification arrives as a user-role message in a later turn; it is never something you write yourself. If the user asks a follow-up before the notification lands, tell them the agent is still running — give status, not a guess.\n\nDon't relaunch. A notification that has not arrived means the agent is still running, not that it was lost. Do not start a replacement agent for the same task; the result arrives under the original task_id. Use list_agents to check the roster and send_message to redirect a running agent.\n\n## When to fork\n\nA fork (subagent_type: \"fork\") inherits your full context by default. Set fork_turns to a positive integer string only when a bounded recent window is sufficient. A background fork reports its result through a completion notification; set run_in_background: true in interactive sessions when you need that result. Headless forks always use this background path. Omitting subagent_type does NOT fork.\n\nChoose a fork when the task needs substantial context from the parent conversation. Use a regular subagent when a fresh prompt provides enough context.\n\nForks are cheap because they share your prompt cache. Don't set model on a fork — a different model can't reuse the parent's cache. Pass a short name (one or two words, lowercase) so the user can track the fork.\n\nThe background-agent rules above apply to background forks unchanged.\n\nWriting a fork prompt. With the default full history, the prompt is a directive — what to do, not what the situation is. When fork_turns limits history, include any older context the fork still needs. Be specific about scope: what's in, what's out, what another agent is handling.\n\n## Writing the prompt\n\nBrief the agent like a smart colleague: make the delegated task, boundaries, and expected output explicit. Regular subagents have not seen this conversation; forks inherit all or the selected recent window.\n- Explain what you're trying to accomplish and why.\n- Describe what you've already learned or ruled out.\n- Give enough context about the surrounding problem that the agent can make judgment calls rather than just following a narrow instruction.\n- If you need a short response, say so explicitly.\n- For lookups, provide the exact target. For investigations, provide the actual question rather than an over-prescribed sequence of steps.\n\nTerse command-style prompts produce shallow, generic work.\n\nNever delegate understanding. Do not write prompts like "based on your findings, fix the bug" or "based on the research, implement it." Those phrases push synthesis onto the agent instead of doing it yourself. Write prompts that prove you understood the task: include relevant file paths, constraints, what specifically needs to be learned or changed, and what is out of scope.\n\nAfter launching an agent, do not fabricate or predict what it found before it returns. If the user asks a follow-up before the result arrives, provide status rather than guessing.\n\nExample usage:\n\n<example_agent_descriptions>\n"test-runner": use this agent after you are done writing code to run tests\n</example_agent_descriptions>\n\n\nuser: "Please write a function that checks if a number is prime"\nassistant: I'm going to use the Write tool to write the following code:\n\nfunction isPrime(n) {\n if (n <= 1) return false\n for (let i = 2; i * i <= n; i++) {\n if (n % i === 0) return false\n }\n return true\n}\n\n\nSince a significant piece of code was written and the task was completed, now use the test-runner agent to run the tests\n\nassistant: Uses the agent tool to launch the test-runner agent\n

What did you expect to happen?

A description like "Launch a subagent to autonomously handle a bounded, multi-step task. \n\nAvailable agent types: [...]" is more than enough. The schema already describes parameters, and when/how to use them.

Client information

$ qwen /about
  |Qwen Code                         0.24.1 (e443e2d238)                                            │                                                                                                      
  │ Runtime                           Node.js v22.23.2 / npm 11.19.0                                 │                                                                                                      
  │ LSP                               disabled                                                       │                                                                                                      
  │ OS                                darwin arm64 (25.4.0)                                          │                                                                                                      
  │                                                                                                  │                                                                                                      
  │ Auth                              OpenRouter                                                     │                                                                                                      
  │ Base URL                          https://openrouter.ai/api/v1                                   │                                                                                                      
  │ Model                             qwen/qwen3.8-27b                                               │                                                                                                      
  │ Fast Model                        qwen/qwen3.8-27b                                               │                                                                                                      
  │ Session ID                        031167af-242c-41e4-b249-9e4273564111                           │                                                                                                      
  │ Sandbox                           no sandbox                                                     │                                                                                                      
  │ Proxy                             no proxy                                                       │                                                                                                      
  │ Memory Usage                      230.3 MB  

Login information

No response

Anything else we need to know?

Same with other tools, they are incredibly verbose