Explainer · Agents
How orchestration works in Lyre
Give agents clear jobs, choose where they run, and review the work they bring back.
Suppose you want to add a feature, test it and update its documentation. One agent can do all three. But an independent review could run while you try the app, and a separate documentation task might be ready before the implementation finishes.
Orchestration is how you coordinate that work: choose a main agent, give helpers clear jobs, follow their progress and bring the results together. Lyre lets you prepare those runs on one computer or across connected computers, with explicit model and workspace choices.
More agents are useful when they have independent work to do. They also add coordination, model usage and review time. A short question usually needs one agent; a task with separate implementation and review stages may benefit from helpers.
Who does what?
An agent uses a model and tools to work toward a goal. Its available tools and permissions decide whether it can read files, edit code or run commands.
The main agent, or orchestrator, plans the work and delegates useful pieces. Helpers, also called sub-agents, carry out those assignments. They may use different models or providers, but the main agent still needs to collect and check their results.
Routing answers “where should this model request go?” Orchestration answers “who should do each part of this task?” A routed model can participate in an orchestration run, but routing is not required.
Start from the conversation
See the Orchestrate task-mode guide for the current run controls.
Write your task in a conversation, then choose Orchestrate. You can also open the same sheet with /orchestration or /orchestrate.
The sheet first asks How should this run? Its three choices describe where the agent work happens:
| Mode | Project work |
|---|---|
| On this computer | The current chat's main agent starts helpers here. |
| Across computers | Each selected computer runs agents in its chosen workspace. |
| Remote agent here | Project tools run here; another computer serves the model. |
Opening the sheet starts no agent. Review the task, models and workspace choices, then use the action for that mode. Changing modes keeps the text you typed in the sheet. Cancel leaves the original conversation draft available.
On this computer
The current conversation stays the main agent. Choose the helper models for this run and use Start helpers. Lyre submits the task through the conversation's Multitask path, with guidance for the agent to delegate through the available Lyre tools or CLI workflow.
The host's saved helper models provide the starting selection. Changing them in the sheet affects this run; Save as default is a separate, explicit action. This is a request for the agent to coordinate helpers, rather than a promise that every task will use every selected model.
Existing composer attachments travel with the local run through their usual send and review flow. Wait for an active turn to finish before starting it. If an action is unavailable, the sheet explains the unmet requirement.
Across computers
Choose the computers doing the work, their models and their workspaces. When you use Coordinator plans, also choose the coordinator computer and model. It produces assignments for you to review before you explicitly run the plan.
Same task everywhere sends the same task to each selected computer instead. That is useful for separate checks, such as reviewing a project in different environments. Each selected model becomes a worker using that computer's assignment and chosen workspace.
Results keep successful workers visible alongside failures. If dispatch only partly succeeds, retry handles unfinished worker slots rather than deliberately starting the successful ones again. Closing the setup sheet does not stop agents that have already started; use their normal agent controls to stop them.
The computers must be connected and eligible for the selected projects. Pairing alone does not grant developer access. Each receiving host checks its current permissions and project access before executing work. An app-only viewer cannot use app access to start coding agents.
Remote agent here
This mode separates model serving from project execution. For example, an agent on your laptop can use a supported model served by your desktop while the agent's project tools run on the laptop.
The source computer must advertise an eligible model, be reachable and permit your connection to use it. Supported providers, host versions and sharing policy determine the available choices. A saved model name is not proof that it is available now.
Model input and output cross the connection, including project context supplied for inference. If the source uses an online provider, that provider also receives the request. Borrowing a model does not automatically transfer its credentials or grant the agent general access to the source computer's project tools.
Across computers and Remote agent here currently prepare text tasks in this sheet. If the conversation has attachments those paths cannot forward, the sheet explains the restriction and prevents a run that would silently omit them. Use the local mode for an attachment-carrying task, or remove the attachments before starting a text-only run.
Set the defaults once
Open Settings, select the computer, then choose AI & agents → Orchestration. Settings uses the same three labels:
- On this computer holds model orchestration, the orchestrator and helper choices, worker limits, Lyre tools, instructions and orchestration skills.
- Across computers holds connected-computer setup and incoming task access, with the existing Run a task entry.
- Remote agent here holds models you use from other computers and the controls for sharing this computer's models.
These are configuration destinations. Opening one does not start a run or create a permission grant. Controls depend on your host and access; model setup alone does not authorize a tool operation.
Give parallel edits their own workspaces
Two agents writing into the same checkout can overwrite or conflict with each other's changes. For independent code changes, create separate worktree workspaces and deliberately select the correct workspace for each worker.
A Git worktree is another working directory for the same repository, usually with its own branch. It separates edits; it is not a security sandbox. Agents still operate under their existing provider and host permissions.
The orchestration sheet does not automatically create a separate worktree for every worker. Several models assigned to the same workspace still share it. Repositories on different computers also need their own setup: Lyre does not automatically synchronize their files or merge the finished branches.
Review the diffs, run the relevant checks and try the app before merging. Agent completion means it returned a result, not that the code is correct.
A useful first task
Start with a bounded request: “Implement this small change. Ask a helper to review the diff without editing files, then summarize its findings and the checks you ran.” This gives the helper independent work without two agents competing to edit the same file.
Add computers or additional workers when the task has a concrete reason for them. Keep ownership, workspaces and the final review clear as the run grows.
See the Agents guide, Projects guide and Pairing guide for setup. For choosing where model requests go, read How routing works in Lyre.