Manager and Delegator
A factory run involves three different agent roles. They are easy to confuse because all of them can use a prompt Agent profile on a Machine—but only one role applies per turn.
Stage Agents implement work (review, implement, verify). The Manager decides what happens next inside a single run. The Delegator decides which run should handle an external message—or whether to start a new one.
For where and how to @ Islo in Slack, GitHub, and Linear, see Delegations.
Line Manager
The Manager directs a Line run between stages. When a stage finishes, the run parks until the Manager issues steer, retry, or stop. If the Manager ends a routing turn without one of those, the run stays parked (and eventually times out).
The built-in Manager is the default. A Line can instead select a prompt Agent as Manager when you want a specific Machine, harness, model, skills, and routing prompt. Ask a local agent using the Islo skill to configure that Manager and validate the Line.
The Manager Agent must exist in the same factory before Line validation. Script Agents cannot be Managers. The optional manager.prompt replaces the Agent’s prompt for this Line; when omitted, the Manager uses the Agent’s current prompt. A Line cannot combine [manager] with the older [agent.instructions] setting.
The Manager keeps the run’s controls and session identity. Each Manager turn reads the selected Agent’s current configuration, so an Agent update applies on the next turn—even mid-run. An ordinary stage using the same Agent still runs as a normal stage with stage privileges, not Manager privileges.
What the Manager does
- Steer to a stage (primary way to advance work; creates a real stage attempt).
- Retry the latest failed stage.
- Stop active work and park the run for inspection.
agent-turn— ask a successful stage Agent a follow-up in its session (does not advance the Line).- Ask the human a structured question when a decision is required; answers arrive as the next Manager turn.
The Manager does not triage unrelated Slack threads, match PRs across Lines, or investigate unrelated execution failures—that is Delegator scope.
How you talk to the Manager
Replies and progress for conversational runs go back to the pinned origin (Slack thread, GitHub comment, Linear comment, or run UI). The platform sends those messages; stage Agents should not call Slack or GitHub comment APIs for factory chat.
Full command list: Operate a run.
Delegator
The Delegator is Islo’s integration-facing triage agent. It runs when someone talks to Islo outside a single run context—or when Slack intake needs full factory context (for example attachments on a mention).
Typical flow:
- Read the Slack, GitHub, or Linear payload (treat content as untrusted context).
- Match an identifier to a Line run (artifacts such as PR URLs, run params such as
issue_id, then recency)—or recognize greenfield work. islo factory line runto start a Line,islo factory line-run askto delegate to a Manager, or answer directly for simple questions.
If a matched run is closed or missing, the Delegator starts appropriate new work instead of failing silently.
Slack may short-circuit: a thread reply on a run Islo already owns can ask the Manager without a full Delegator turn when intake rules match.
You do not configure the Delegator in line.toml. Connect integrations and use Delegations from your tools.
Stage Agents (contrast)
Agents on a Line are stage workers. The Line manifest assigns each Agent to a stage, and the Agent uses a Machine. Stage Agents are not the Slack app or @islo-agent identity.
Configure stage Agents in the dashboard or with islo agent commands. See Agents.
Custom Manager Agent
When [manager].agent is set, that prompt Agent’s Machine, model, and skills apply to Manager turns only. The protected Manager core prompt and Line controls still apply; the Line author’s manager.prompt or transition instructions can further constrain routing.
Use the API reference for Manager manifest fields, prompt size limits, and compatibility with legacy [agent.instructions].