The Tasks Manager Agent

Pro Only

The Tasks Manager is an AI agent session that runs the Tasks tool's queues for you. You write tasks on the Plan tab and mark them Ready; the Manager decides which queue each one goes to, in what order, and which can safely run at the same time. It starts the work, answers or passes on the questions that the working agents ask, and lines up the results on the Review tab -- or commits them, if you allow that.

To watch the Manager and its queues at work on example projects, see the demos on Wingware's website.

Whether and when to use the Manager is up to you. Many people start by working with a single agent, and turn on the Manager once they trust the results and want to hand over more of the work; others use it from the start. Either way, the Manager helps because:

  • It figures out what can run concurrently and what can't. The Manager reads each task and the code it names, and keeps tasks that are likely to touch the same files apart, while running unrelated work side by side. Closely related tasks are run one after another in the same session, so later tasks keep the context of earlier ones.
  • Questions and answers are in one place. Tasks run autonomously: instead of stopping in the middle to ask, each one works as far as it can and ends with a report of the decisions it made and any questions it still has. Everything waiting on you -- from every queue -- is collected on the Tasks tool's Questions tab, where you answer it in place. There is far less to read through and respond to than when you watch several agent sessions yourself.
  • Problems found along the way are never lost. When an agent notices a real problem outside the task it is working on, it files it as a draft task in a Found goal on the Plan tab, where you can review it, have it researched, and queue it when you're ready.
  • The Manager is a mentor as well as a scheduler. It is an agent you can talk to. Ask it why a task is being held, what a queue is doing, how a part of the Tasks workflow works, or to sort out a workflow problem -- a stuck queue, a commit that was refused, a task that should be split -- and it explains or fixes it.

The Manager never edits files itself. The work is done by ordinary agent sessions in ordinary queues (the worker queues), which you can watch, talk to, and review exactly as you would without the Manager. Every change the Manager makes to your tasks is listed, and any one of them can be reverted (see Manager Decisions below).

Turning On the Manager

Note that not all AI agents are well suited to run the Manager. See the table in AI Agent Safety for details.

Two separate controls govern the Manager:

  • Whether it is used -- A project set up for an agent in the New Project or Set Up for AI Agent dialog already has the Manager on, since their Autonomous Tasks Manager checkbox is checked by default, and their Autonomous Commits checkbox sets its Commits to Commit Automatically. For other projects, press the Turn On button in the Manager's bar at the top of the Tasks tool's Execute tab. That bar is where the Manager lives: once it is on, the bar shows what the Manager is doing and holds its controls. The same switch is also Use Tasks Manager Agent in the Options menu (the ⋯ button) at the top right of the Tasks tool, which is where you turn the Manager off again, and Task Scheduling on the AI Agent tab of Project Properties, where it is a choice between Manual Queueing and Tasks Manager Agent. Changing any one of these changes the others.
  • Whether it is running or paused -- Once it is on, the cog to the left of Manager on its bar halts all work, pausing the Manager, and resumes it. It stays on (checked in the Options menu) while paused. See Halting and Pausing below.

While the Manager is on, every task runs autonomously, as described above: it works without stopping to ask, and ends with a report and any questions. While it is off, tasks that you queue with their Q buttons run interactively, as described in The Tasks Tool.

The first time you press Turn On, Wing asks for the Manager's settings; a project set up with the Manager on starts with their defaults. These can be changed later with Tasks Manager Settings... in the Options menu, the settings icon on the Manager's bar, or the Settings... button next to Task Scheduling in Project Properties, also while the Manager is off. The settings are on three tabs: Scheduling, Permissions, and Commits.

While the Manager is on, its Permissions and Commits settings are used for all of the project's agent work, in place of the Preapprove settings, Commit Mode, and Show Summaries on the AI Agent tab of Project Properties. This covers its workers, the sessions and tasks you start yourself, the Fix features, and every commit. They start from the values on the AI Agent tab, so turning the Manager on without changing them keeps the same permissions and commit behavior, except as noted for Edits for below. See Configuration for details.

The Scheduling tab holds these settings:

  • Agent -- Which agent runs the Manager's own session. This defaults to the agent the project is set up for; the worker queues use their own agents as usual. Some agents (Codex, Cursor, goose and other agents run over ACP, and OpenCode) cannot be technically prevented from editing files, so for them the Manager's read-only role is only an instruction. Wing warns about this but lets you use them anyway. Wing also warns when an agent (such as Antigravity or Cursor in their own terminal interfaces) does not tell Wing that it has stopped to ask for approval: the Manager or a worker waiting on such a prompt shows as running, with nothing on the Questions tab, so you will need to interact directly with its session if it stops making progress.

  • Decisions -- How autonomous tasks handle decisions they would otherwise ask you about:

    • Decide and Report makes the judgement call, records it, and carries on, asking only when the work truly cannot go on. Every decision is listed with the task on the Review tab so you can object to any you disagree with.
    • Ask Me First does everything that doesn't depend on your answer, then asks before any significant decision and waits for you.

    This is only an instruction to the Manager and the workers, and you can refine it by talking to the Manager -- for example, "ask me about anything that changes a file format".

  • Maximum writing workers -- A ceiling, not a target, on how many worker queues may be changing files at once. All queues share one working copy, so the Manager raises concurrency up to this limit (five by default) only when it judges that the tasks touch different files. Read-only research tasks don't count against the limit. With more than one writing worker, which task changed which file can occasionally be unclear on Review. With one, the next writing task waits until the last one's changes are committed, so each commit holds one task's work.
  • Concurrent agent test runs -- How many agents' test runs may go at once (four by default). A run beyond this waits for one to finish, as does a run of the same files as another agent's or your own live run. Time spent waiting counts toward the run's time limit, and its result tells the agent how long it waited. This limits only agents' runs: your own runs in the Testing tool never wait for it. See Running Tests.
  • Resume previous Manager session -- When checked, turning the Manager on again continues its earlier session and context. Uncheck it to start each time with a fresh session.

  • Start found tasks -- Which of the tasks the Manager proposes and the bugs agents find it may mark Ready, so that they run right away instead of waiting for you:

    • Never leaves them all as a Draft for you to decide on.
    • Related Tasks Only starts only those closely related to the task they came from, for example a test that the task's change broke, a bug found in the code the task worked on, or the plan of research you ran. This is the default.
    • Always starts any the Manager judges you would want run, leaving bugs in unrelated code for you.
    • As Described: lets you write your own policy in the box below it, such as "Start fixes for failing tests and bugs in code my tasks changed, but leave new features and refactoring for me". The Manager applies it to each task, and leaves a task for you when it is unsure.

    Each task the Manager starts is listed under Decisions, where you can undo it.

  • Maximum found tasks started per hour -- A last-resort limit on how many found or proposed tasks the Manager marks Ready in any hour. Past it, they stay a Draft for you.

  • Split mixed or broad tasks -- Whether the Manager splits a Ready task into separate tasks, so that each is reviewed and committed on its own and work on different files can run at the same time. It splits a task that holds independent pieces of work, such as a fix with an unrelated request added at the end. A request too broad to carry out as written is researched first, and once its plan is accepted the Manager carries it out as one task or files its steps as separate tasks. The original task goes to History, marked as split.

    The Manager decides whether the new tasks are Ready or Draft. Parts of a task you wrote out in detail are usually Ready, as are the steps of an accepted plan, except optional ones, which are a Draft for you to decide on. The new tasks go in the original task's goal, another of your goals, or a new goal the Manager makes for large new work. The Manager removes a goal it made once its tasks are done, and never removes your goals.

    • Always splits without asking. This is the default.
    • Ask Me proposes each split on the Questions tab first.
    • Never runs each task as written.

    Each split is listed under Decisions, where you can undo it until one of its tasks starts.

  • Research notes directory -- Where Research This writes its notes on found problems (see below). Blank uses the private .TASKS/notes directory, which version control already ignores.

The Permissions tab has two sections. See Configuration for how these reach each agent.

Preapprove sets what agents may do without asking, in sessions that ask for approval:

  • Edits for -- All Project Directories lets agents edit files in the project's directories that are under version control. Nothing (Prompt Each Time) makes them ask before every edit. There is no list of chosen directories here, so a project whose AI Agent tab uses Only These Directories starts with Nothing (Prompt Each Time).
  • Running commands -- Whether agents may run any shell command without asking.
  • Revision control commands -- Whether agents may run hg, git, and other revision control commands, such as status, diff, and log, without asking, even when running other commands is not preapproved. This only affects whether agents ask first. Whether the Manager's workers commit is set on the Commits tab.

Allow Tools lists capabilities that agents in the project may use while the Manager is on. Unchecking one keeps every agent from it: Wing launches every session without it, and the Manager can't give it to a task. A change takes effect as each session next starts. The capabilities are web search and fetching web pages, driving a web browser, outside services linked to the agent's account, publishing shareable pages and designs, timers, cron jobs, cloud routines, and push notifications, and pushing to remotes with git or hg.

Pushing, when unchecked, is refused whenever an agent runs a push command, in any session, starting at once. A script or alias that pushes is not detected, so this does not replace the access controls on your remote repositories.

Only the capabilities the Manager's agent can be kept from are listed: for Codex, web search, timers, and pushing; for Copilot, Cursor, and Antigravity, only pushing. OpenCode can't be kept from any of them, so the section is hidden.

The Commits tab holds these settings:

  • Commits -- Review/Commit Manually leaves finished work on the Review tab for you to review and commit. Commit Automatically lets the Manager commit each queue's work once its tests pass; the committed tasks still go to Review, marked Committed, so you can look them over and mark them complete. Describe Policy: lets you write your own rule in the box below it, such as "Commit code automatically, but leave documentation changes for me to review". The Manager applies the rule itself to each commit: it commits the files the rule allows and leaves the rest uncommitted, with the tasks that changed them still on Review. When it is unsure whether the rule allows a file, it leaves it for you. This decides when the tasks the Manager runs are committed, and its workers don't commit on their own. Until you commit or discard work left for you, a queue whose tasks changed the same files starts no task that may write files. Plan-mode tasks, and queues working on other files, go on.
  • Commits in sessions you start -- How work in sessions and queues you start yourself is committed, and who writes the message for every commit you start, including commits of the Manager's tasks. It has the same choices as Commit Mode. In the two choices where Wing writes the message, agents end each task with the summary Wing builds it from.

To turn the Manager off, uncheck Use Tasks Manager Agent in the Options menu, or set Task Scheduling to Manual Queueing in Project Properties. Its session is closed, and your queues and tasks are left as they are.

Running Tasks with the Manager

Tasks on the Plan tab carry a Ready / Draft pill. A task you type starts as a Draft, so nothing picks it up while it is half written; click the pill to mark it Ready when you're done. Editing a Ready task makes it a Draft again. A goal's pill marks all of its pending tasks at once. Drafts belong to you: the Manager never runs one, except for found tasks as described under Start found tasks above.

While the Manager is running, it picks up Ready tasks as they appear. Run Ready Tasks, which is in the Options menu only while the Manager is on, asks it to schedule every Ready task right away, resuming it first if it is paused.

Ready means something only to the Manager: nothing else runs a Ready task that is not in a queue. While the Manager is off, the pill is just a note to yourself about which tasks are finished being written.

The Manager fills its queues only a task or two ahead, so Ready tasks may wait on the Plan tab for a while. Each one shows a short note from the Manager saying when it will run, such as "Next on Test discovery" or "Held: overlaps task T7", or Seen by Manager when the Manager knows about it and will queue it when it fits. Before a task starts, the Manager may add a dated note to the end of its text with context the worker will need; you see this note too.

The Manager's Queues

The Manager works only in queues that it creates itself, named for the work they run (for example Test discovery), and removes them again when they are no longer needed. Read-only queues that it uses for research are named Research: followed by the topic. Closely related tasks are usually run one after another in the same queue and session, so that later tasks keep the context of earlier ones. A task that follows up an earlier one may be run in that earlier task's session even if the session is no longer open, provided the agent can find and resume it. Either way, each task keeps its own report, changes, and Review entry.

Queues you create yourself remain yours. The Manager never assigns work to them, starts, pauses or commits them, or answers their tasks' questions. Thus you can still run a particular task yourself, alongside the Manager, by right-clicking on it on the Plan tab and selecting one of your own queues from its Queue submenu. The Manager does take the tasks running in your own queues into account when it decides which tasks, and how many, can safely run at the same time.

While the Manager is on, the tasks' and goals' Q buttons are hidden. The Manager decides whether a task is researched before it is carried out. To have it researched first in any case, check Research First in the task's right-click menu.

When a worker queue uses Claude Code or Codex, the Manager chooses which optional tools its session loads for each task: artifacts, bundled skills, browser control, web search and fetching, connectors, workflows, and scheduling (timers, scheduled jobs, and phone notifications). A task gets only those it needs, which reduces the agent's token use. Codex leaves out only its bundled skills, web search, and goal and sleep tools, since it lacks the rest or they cost nothing. A worker that finds it needs more asks Wing for them, and Wing restarts its session with them added, resuming the same conversation without asking you. Tasks in your own queues, and sessions you start yourself, load the full set.

While a worker is running, the Manager can send it a message, for example to point out that another task has just changed a file it is working on or to give it details gleaned from another task just marked as Ready. Wing delivers the message as soon as the worker's agent can take it, prefixed with "Wing, relaying the Tasks Manager:". When the Manager sees that a worker is wasting effort, it can also interrupt the worker and redirect it.

The Manager's Bar

The top of the Execute tab shows the Manager's bar:

  • Its state -- Starting..., Waiting for its session, Planning..., Idle, Waiting for you, or Paused -- followed by counts of running workers (out of the allowed maximum), Ready tasks, and items waiting for you. Waiting for its session usually means the Manager's agent is asking something at startup, such as whether to trust the folder or to sign in; click the show (eye) icon to answer it.
  • A line with the Manager's latest note on what it decided and why, such as "Holding 'Refactor dispatch' until the Test discovery queue finishes: both change tasks.py". The Manager also puts short notes on individual Ready tasks on the Plan tab, as described above.
  • Decisions, which lists every change the Manager has made to your tasks (see below).
  • Icons to Hold / Resume new work, Show its session in the AI Agent tool, and open its Settings. Hover over an icon to see what it does.
  • A Tell the Manager... field. What you type there goes straight to the Manager as an instruction or question, same as if you type it directly into the Manager's session. It is disabled while the Manager is paused.

You can also talk to the Manager in its own session in the AI Agent tool, like any other agent. This is the place to ask it to explain what is going on, change its plan ("run the documentation tasks last"), or help with a workflow problem. Click on the show (eye) icon or the Manager's name in the Manager area of the Execute tab to show the Manager, or select it from the AI Agent tool's session selector.

Holding New Work

To let running tasks finish without starting any more, for example before restarting Wing, click the pause icon at the right of the Manager's bar. Each queue pauses once its current task is done, and the Manager starts and queues nothing new. It keeps running, so it still commits finished work as its Commits setting allows, and answers questions. The hold stays in place across a restart. Click the resume icon to let the queues go on and the Manager schedule work again.

Halting

To stop all work at once, click the cog to the left of Manager on its bar. Wing interrupts every agent that is working on a task, holds new work as the pause icon does, and pauses the Manager. Interrupted tasks stay where they were, and their queues show Halted. Click the cog again to resume: the queues go on, and each interrupted agent continues its task where it stopped. The cog on a halted queue's line continues only that queue's task.

You do not need to halt or hold work before closing your laptop or putting your computer to sleep. Work stops while it sleeps and goes on when it wakes.

Pausing

The Manager pauses when you halt work with the cog, when you interrupt it with Esc in its session, and when its session ends, fails, or does not become ready. The reason is shown on its bar on the Execute page of the Tasks tool. While the Manager is paused, it schedules and commits nothing and answers no questions, but queues that are not held go on with the tasks already in them. What happens meanwhile is passed to the Manager when it resumes. Click the cog again, or tell the Manager to continue, to pick up where it left off.

The Manager also pauses when it stops at its AI usage limit. Its bar then shows when the limit resets, and Wing resumes the Manager at that time.

You can still talk to a paused Manager in its session in the AI Agent tool. It answers questions, and carries out what you ask it to do in that conversation, but schedules nothing on its own until it is resumed.

A Manager that was running when Wing quit or the project was closed resumes automatically when the project is opened again. One that you paused or turned off stays that way.

Manager Decisions

The Manager changes your tasks in a number of ways: queueing them, adding notes, rewriting unclear found tasks, ordering the Found goal, merging duplicate findings, retiring findings that are no longer worth doing, splitting tasks, proposing new draft tasks, and making follow-ups Ready. Each such change is recorded, and a task that the Manager revised or made Ready says so on its row, with the details in its tooltip. Decisions on the Manager's bar lists them all, newest first. Select a change to see it in full in the area below the list, along with the text of its task and whether the change can still be reverted. Click Revert to undo the selected change, as long as the task is still as the Manager left it. A change that can no longer be reverted is shown greyed out, for example because it was reverted already, its task has since run or been edited, or the task is gone; the details area says why. Double-click a change to show its task on the Plan tab. Undo in the Tasks tool also reverts the Manager's latest changes in turn. The window keeps its size and layout if you close and reopen it while Wing is running.

A task that the Manager retired or merged into another goes to the History tab, where Restore to Plan puts it back on the Plan tab as a Draft. The Manager notices when you revert one of its changes, and does not make that change again without asking you.

The Questions Tab

The Questions tab, between Execute and Review, lists everything that is waiting on you, most blocking first, with an orange count on the tab. It includes:

  • Task questions -- A task that ended with questions waits for your answers. Each item starts with the task's number, which you can click to show the task, and lists its questions with the options each offers; pick one, type your own answer, or click Let Agent Decide. Hover over the task's title to see its queue and the summary it reported. Send Answers sends them into the task's session and the work continues. A task that is still planning shows Implement Plan and Revise Plan instead, with a box for comments, as described in The Tasks Tool. A waiting task counts against Maximum writing workers only if it has uncommitted changes, so other work can go on while it waits. If you answer while all the writing slots are taken by other tasks, the item leaves the Questions tab and the task resumes by itself once that one finishes. Its status in the queue reads Answer sent; waiting for a writing slot until then. An answer that keeps the task in plan mode is never held. Review comments, which you write with Revise... on the Review or History tab, are the Manager's to have addressed, whichever queue the task first ran in. It decides whether the task's own session, a follow-up task, or no change addresses each one. A comment it sends to the task's session waits for a writing slot in the same way as answers. Until the comment is taken up, the task's status on the Review tab reads Revision pending and says what it waits for, and Mark Complete asks before it drops the comment unaddressed. Wing runs it in a queue of the Manager's, which it schedules and commits like its own. If the task's session is still the current one of a queue you started yourself, Wing waits until that queue is idle and then moves the session to the Manager's queue. Your queue stays yours and starts its next task in a new session. Move to Review, here and on stopped tasks, stops the task waiting and puts it on the Review tab with whatever it changed, where you can review, commit or complete it.
  • The Manager's own questions -- Decisions the Manager wants you to make, and worker questions it has passed on to you, often with context or a suggested answer. This is also where the Manager asks you to do something the queues are waiting on, such as signing in to an agent. In Decide and Report mode the Manager answers many worker questions itself; those answers are recorded as decisions you can review. While it is still working on a question, the item says so, and if you answer first, your answer wins.
  • Permission prompts -- An agent waiting for your approval to use a tool, answerable with Allow or Deny. When you deny, you can say why, or what to do instead.
  • Agents waiting on you -- Sessions waiting mid-turn for input, with Show Session to answer them there.
  • Stopped tasks -- A task that finished without changing any files and left a message, or that reported it was blocked or gave up. Reply to it to go on, or mark it complete.
  • Tasks sent to other machines -- A task whose peer can't be reached, declined it, or ended it unanswered, or whose returned changes touch files with unsaved changes or could not be applied here. Changes that only conflict go to a merge task instead. See Sending Tasks to Other Machines for the choices each offers.

Every item has Show Session if you want to see the whole conversation, but most of the time the item itself has all you need to answer. Answers you sent recently are listed at the end of the tab.

Autonomous decisions at the top of the tab switches between Decide and Report and Ask Me First. Alert Me When Questions Arrive in the Options menu (on by default) bounces or flashes Wing's icon when something new arrives while you are working in another application.

Found Problems

Agents working on a task are asked to report real problems they notice outside that task, rather than silently fixing them or forgetting about them. Each one becomes a Draft task in a Found goal on the Plan tab, and the Plan tab shows an orange count of new ones. Each shows which task found it, and offers:

  • Research This -- Have an agent research the cause and propose a fix, without changing any code. Its notes go into a file in the research notes directory, which the task then points to. The research runs in a queue named Research, which Wing creates for you the first time. Research Further continues the research. Research that finishes with only its notes moves to History. Research that plans work, changes files, or cannot finish waits on the Review or Questions tab.
  • Discuss -- For a finding that came out of research, resume the research session to talk it over before deciding.
  • Dismiss -- Delete the finding (Undo restores it).

When a finding is worth doing, edit it as needed and mark it Ready for the Manager to schedule. New findings, and the tasks the Manager proposes, are also listed in the Incoming view of the Plan tab; see The Tasks Tool.

The Manager also looks after the Found goal: it merges duplicate findings into one task, keeps them in a sensible order, rewrites one that is unclear or wrong, retires one that is no longer worth doing (for example because other work made it moot), and may propose tasks of its own as Draft tasks there. When you ask it to research findings, it does so in a research queue of its own. Research runs in plan mode, where it cannot change files, and does not count against Maximum writing workers. When you answer a research task's questions by choosing a run mode, it goes on to carry out its plan in the same session, and from then on counts as a writing worker.

When research in one of the Manager's queues reports a plan, the Manager either accepts the plan and carries it out, or asks you on the Questions tab to accept it. It accepts a plan itself only in Decide and Report mode, and only one that is simple and leaves nothing to ask you; a large plan, or one you asked to review first, waits for you. No tasks are made from a plan until it is accepted. Once it is, the Manager decides whether it goes on as the same task or as separate tasks, without asking. To change the plan instead, answer its question with what to change.

When research revises its plan, the tasks made from its earlier plan that have not started move to History, including any you edited, and those already started stay. Each move is listed under Decisions, where you can undo it.

Apart from the follow-ups described in Turning On the Manager, it leaves every finding a Draft for you to decide on, flagging those you haven't reacted to with an orange dot on the Plan page.

Reviewing the Results

Finished work arrives on the Review tab as usual. Each autonomous task shows its report: a summary of what it did and the judgement calls it made on your behalf, each with the reasoning and the alternatives it considered. Read these before you commit; if you disagree with one, send the task back with a comment, or queue a follow-up task.

With Commits set to Commit Automatically, the Manager commits each of its queues' work once its tests pass. With Describe Policy:, it commits what your rule allows the same way, and leaves the rest on Review. The commit runs in that queue's own session, which knows the work best. While it runs, queues whose uncommitted work touches the same files wait before starting another writing task. When two queues' work depends on each other, so that neither can be committed alone, the Manager commits them together. If a commit fails, its tasks stay on the Review tab and the queue stays paused until the cause is fixed.

Writing the Journal

The Manager writes the project's Journal, which Export History... includes. Once a sitting of work ends, it names the sitting's phases, such as "Implement the dashboard" or "Fix false positives", from the events Wing recorded. Wing gives each phase the time of the event where it began, so the Manager's labels give no times. When a task done here for another machine goes back, the Manager also writes one sentence on it for that machine's Manager. See The Journal in The Tasks Tool for details.

Task Labels

Every task has a short label, such as T12, shown at the right of its row on every tab. Click it to copy the task's full id. Agents and the Manager name a task by its label and the start of its id, as in "task T12 (6d810aca)", and such names in the Tasks tool are links to the task. You can use the label to refer to a task when talking to the Manager or any other agent.

Tips

  • Write each task so it can be done without follow-up: say what done looks like, and mention the files or features involved. This helps both the worker and the Manager's judgement of what can run in parallel.
  • A task can also be a high-level specification, such as a new feature or a whole application described in a few paragraphs. Ask for it to be researched and broken into tasks: the Manager runs the research, and the resulting implementation tasks appear on the Plan tab. Parts of what you asked for may be marked Ready and run right away; others wait as Draft tasks for you to look over.
  • Use goals to group related work. Tasks in one goal are often done in sequence, while tasks in different goals are the likeliest to run side by side.
  • Set Maximum writing workers to one if you'd rather see one change at a time until you're comfortable with how the Manager splits work. Research and review tasks still run alongside the writing worker.
  • When something about the workflow surprises you, ask the Manager. It sees the state of every queue and task, and can usually explain it or put it right.

« 4.3.1. Sending Tasks to Other Machines
Table of Contents
4.5. Configuration »