Stand Up a Software Engineering Team
A team puts several assistants on one job under a leader. This tutorial launches an engineering team, points it at a repository, runs a build-and-review task across its specialists, and keeps the team around as a Standing Company. You need a connected model provider first. See Connect Your First Model if you have not done that yet.
1. Launch a team from the library
Section titled “1. Launch a team from the library”Open the Teams library. The library separates Standing Companies, which are teams you keep, from ad-hoc Teams, which are teams for a single job. Pick an engineering team launcher.
Open the launcher. A capability review shows what the team can do before it starts, so you can see which tools and skills the specialists carry. Start the team.
2. Point the team at a repository
Section titled “2. Point the team at a repository”Give the team a working context. A project workspace scopes the team to one repository so file reads and edits stay inside it. Create or open a project for the repo, then launch the team from there. The engine equivalent is the --project-dir flag and hierarchical project context (AGENTS.md and friends), so the same instructions apply whether you drive from the app or the CLI. See Projects and Workspaces.
3. Drive the work
Section titled “3. Drive the work”On the team page:
- The leader sits at the top. Give it the goal in plain language, for example “add input validation to the upload endpoint and write tests”. The leader breaks the goal down and directs the specialists.
- Each specialist is a tab. Open a tab to follow one member’s work in detail, such as the engineer writing code or the reviewer checking it.
- The right rail tracks overall state, and the activity tab shows what the whole team has done.
Each member has its own model selector. Pair a strong reasoning model on the leader with faster models on specialists to balance quality and cost.
4. Handle approvals
Section titled “4. Handle approvals”Like any assistant, team members ask before using tools that touch your system, such as running a command or writing a file. Pending permissions surface on the team page. Approve or deny them as the work proceeds. You stay in control of anything that runs.
If you trust a kind of call, approve and remember it so the team stops asking for that category. For unattended runs the engine offers --auto-approve, but in an interactive session keeping the gate on is the safer default.
5. Review the activity log
Section titled “5. Review the activity log”When the run settles, open the activity tab to see the full trace: which specialist did what, the tool calls they made, and the results. This is where you confirm the tests were written and the build passed before you trust the output. Read the diff the reviewer produced and the engineer’s edits side by side.
6. Promote to a Standing Company
Section titled “6. Promote to a Standing Company”When an ad-hoc team proves its worth, keep it:
- From the team, open the promote option. Wayland checks the team is eligible first.
- Confirm in the Promote to Standing dialog.
The team now persists between sessions and gets its own entry in the active-teams area, so the same group is ready next time you open the repo. It also appears as a Standing Company card in the library.
What you built
Section titled “What you built”You launched a multi-agent engineering team, scoped it to a repository, ran a real task across specialists with approvals in place, verified the work in the activity log, and promoted the team so it survives between sessions.