{"id":94908,"date":"2026-04-01T08:00:00","date_gmt":"2026-04-01T15:00:00","guid":{"rendered":"https:\/\/github.blog\/?p=94908"},"modified":"2026-04-14T13:28:19","modified_gmt":"2026-04-14T20:28:19","slug":"run-multiple-agents-at-once-with-fleet-in-copilot-cli","status":"publish","type":"post","link":"https:\/\/github.blog\/ai-and-ml\/github-copilot\/run-multiple-agents-at-once-with-fleet-in-copilot-cli\/","title":{"rendered":"Run multiple agents at once with \/fleet in Copilot CLI"},"content":{"rendered":"\n

What if GitHub Copilot CLI<\/a> could work on five files at the same time instead of one? That’s where \/fleet<\/code> comes in.<\/p>\n\n\n\n

\/fleet<\/code> is a slash command in Copilot CLI that enables Copilot to simultaneously work with multiple subagents in parallel. Instead of working through tasks sequentially, Copilot now has a behind the scenes orchestrator that plans and breaks your objective into independent work items and dispatches multiple agents to execute them simultaneously. On different files, in different parts of your codebase, all at once.<\/p>\n\n\n\n

Want to learn more about how \/fleet<\/code> works, and more importantly, how to use it most effectively? Let’s jump in.<\/p>\n\n\n\n

How it works<\/h2>\n\n\n\n

When you run \/fleet<\/code> with a prompt, the behind-the-scenes orchestrator:<\/p>\n\n\n\n

    \n
  1. Decomposes your task into discrete work items with dependencies.<\/li>\n\n\n\n
  2. Identifies which items can run in parallel versus which must wait.<\/li>\n\n\n\n
  3. Dispatches independent items as background sub-agents simultaneously.<\/li>\n\n\n\n
  4. Polls for completion, then dispatches the next wave.<\/li>\n\n\n\n
  5. Verifies outputs and synthesizes any final artifacts.<\/li>\n<\/ol>\n\n\n\n

    Each sub-agent gets its own context window but shares the same filesystem. They can’t talk to each other directly; only the orchestrator coordinates.<\/p>\n\n\n\n

    Think of it as a project lead who assigns work to a team, checks in on progress, and assembles the final deliverable.<\/p>\n\n\n\n

    Getting started<\/h2>\n\n\n\n

    Start fleet mode by sending \/fleet <YOUR OBJECTIVE PROMPT><\/code>. For example:<\/p>\n\n\n

    \n
    \/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs\/auth\/ <\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
    That’s it. The orchestrator takes your objective, figures out what can be parallelized, and starts dispatching.<\/p>\n\n\n\n
    You can also run it non-interactively in your terminal:<\/p>\n\n\n
    \n
    copilot -p \"\/fleet <YOUR TASK>\" --no-ask-user<\/code><\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
    The --no-ask-user<\/code> flag is required for non-interactive mode, since there’s no way to respond to prompts. Now let’s look at what makes a good prompt.<\/p>\n\n\n\n
    Write prompts that parallelize well<\/h2>\n\n\n\n
    The quality of your \/fleet<\/code> prompt determines how effectively work gets distributed. The key is giving the orchestrator enough structure to cleanly break down your task.<\/p>\n\n\n\n
    A good way to do that is being specific about deliverables. Map every work item to a concrete artifact like a file, a test suite, or a section of documentation. Vague prompts lead to sequential execution because the orchestrator can’t identify independent pieces.<\/p>\n\n\n\n
    For example, instead of: \/fleet Build the documentation<\/code>, you could try:<\/p>\n\n\n
    \n
    \/fleet Create docs for the API module: \n\n- docs\/authentication.md covering token flow and examples \n\n- docs\/endpoints.md with request\/response schemas for all REST endpoints \n\n- docs\/errors.md with error codes and troubleshooting steps \n\n- docs\/index.md linking to all three pages (depends on the others finishing first)<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
    The second prompt gives the orchestrator four distinct deliverables, three of which can run in parallel, and one that depends on them.<\/p>\n\n\n\n
    Set explicit boundaries<\/h2>\n\n\n\n
    Sub-agents work best when they know exactly where their scope starts and ends. When writing your prompt include:<\/p>\n\n\n\n