Parallel agents

Run separate lines of work as separate agents, each in its own Git worktree or a managed copy of the repository, so unfinished work does not alter the main files. Watch them from a single dashboard and merge only what you trust.

Agent workspaces

Use another workspace when work can happen independently: one agent can handle the interface while another investigates tests or infrastructure. Vector sets no cap on how many of its own agents run at once; coding agents you installed yourself run up to four at once.

1. 1
   Create a workspace

   Name the responsibility and send its first request.

2. 2
   Keep working

   Switch between workspaces while they stream activity independently.

3. 3
   Review and merge

   Inspect the diff and checks before bringing selected work into main.

An isolated agent gets a Git worktree on its own branch only when the folder is a Git repository and the working tree is clean. Without one — no repository, uncommitted changes, or a worktree that cannot be created — Vector provisions an isolated copy instead and records which it used in the workspace log.

Two agents should not intentionally edit the same lines at the same time. Split work by responsibility to reduce conflicts and make review easier.

Change an agent's branch

The session header shows the branch the agent's checkout is on. Click it to switch that checkout to another local branch, or type a new name and choose Create branch to make one from the current commit. Vector runs an ordinary git switch: it never stashes or discards your work, so a switch that would overwrite uncommitted changes is refused with git's reason. Branches already checked out in another agent's workspace are shown but cannot be picked, and Vector refuses to switch while one of its agents is running in that checkout. In an agent workspace Vector manages, you can create a new branch but not switch to an existing one, because that workspace merges back from the commit it started on.

Coordinated runs: one objective, a team of agents

Instead of naming each workspace yourself, choose Coordinate agents in the launcher and give Vector the objective. A planner model reads the repository and writes a plan: tasks with roles — explore, implement, debug, test, review, security, docs — and the dependencies between them. Each task becomes its own agent in its own workspace, routed to a model by tier, and tasks run as soon as the ones they depend on finish. Explore, debug, test, review and security tasks go to the matching subagent specialist; implement and docs tasks run on the general agent.

You set the strategy (economy, balanced or quality), the most agents that may run at once, and how many run in parallel. The run reports as one board — planning, running, needs review — and nothing reaches your main checkout until you look at the combined diff and merge it.

Teams can be wired everyone-to-everyone, coordinator-to-workers, or any pairing you set. A message to a teammate you have not linked is refused and told so, rather than dropped where the sender never finds out.

The Agent Dashboard

Every agent in the workspace on one board: Running, Needs you and Done. Open it from the workspace rail. Switch to a list for a denser view of the same three groups.

• Needs youMerges failed with needs-review, including a finished run that reported an error. Both are stopped and waiting on a person.
• Filters that composeStatus, Team, Pull request and Agent. Two values in one menu means either; values in two menus means both.
• Pull request stateOpen, merged, or never opened — merge state wins, so a merged run does not sit under "open" forever.
• Teams as a unitAgents sharing a team or swarm filter together, and the board shows the messages they sent each other mid-run.

Two agents holding uncommitted work on the same file are reported as a clash. Merging both will conflict — review one before merging the other.

Agent workspaces are not subagents. Subagents work inside one session's checkout and report to its main agent; see Subagents and subagent specialists.