Not a fixed Planner / Executor / Reviewer
Planner, Executor, and Reviewer are common collaboration examples, not built-in templates in LoneAct. A project can have its own payments specialist, frontend lead, data analyst, on-call operator, or compliance reviewer; the team structure should follow project capabilities and work boundaries.
Divide by capability
Each role owns a clear responsibility, critical path, and deliverable, so several Agents do not repeat the same work.
Build from the project
The project's root role can read the code, identify capability boundaries, and propose a first version of the team structure.
Extend as needed
Add members, change responsibilities, adjust critical paths, or update the team when the project changes.
Role and Agent: the job is separate from the person
LoneAct manages teams with a two-layer model: Role defines what the job is, and Agent represents who does it. This separation lets teams reuse responsibility templates while long-term collaborators keep their own memory.
| Dimension | Role | Agent (digital employee) |
|---|---|---|
| What it is | A template for responsibilities, instructions, model, and skills | A long-lived instance working in one Role |
| Memory | Has no personal memory | Has its own directory, memory, and collaboration history |
| Reuse | Can be reused across several Agents | Identity persists and does not end when a Run ends |
| Best for | Stable, auditable job definitions | A partner that owns a domain long term and needs to accumulate experience |
In Settings → Agents, clicking Hire agent creates a long-lived Agent with a name, a Role, and its own memory directory. Delegate to it by name afterwards, and it continues with the same person's context.
After you hire an Agent, its Role does not switch automatically as tasks change. When the job changes, create a new Agent so the old Role's memory is not carried into new responsibilities.
Build or update a project team
Start with a project goal
The team works inside a project folder; the clearer the project, the easier role boundaries are to draw.
Build the team from code
In the Team panel, choose build and let the root role read the project and propose capability roles; each role should have its own critical path.
Review and revise by hand
You can edit role responsibilities, critical paths, models, and skills, and add members. A team is not a black box that cannot change after one generation.
Keep it current
Use Update from code or Rebuild after the project changes; an update keeps existing role memory where possible, while a rebuild reorganizes capabilities from the current project.
What a role can configure
Responsibilities and instructions
State in one sentence what the role owns, then use full instructions to define boundaries, checks, and delivery format.
Model
When empty, the role inherits the workspace default model; you can also assign a better fit to this role.
Skills
Load only the skills this role needs; when empty, the skills available in the workspace are used.
Delegation depth
Controls whether the role can delegate to sub-agents and how many levels deep it can go.
What digital employees can do
Engineering squad
A frontend lead, backend lead, test reviewer, and release manager collaborate over time.
Data and operations
A data organizer, report reviewer, and operations assistant share project context.
Support and on-call
A customer issue analyst, incident investigator, and knowledge base maintainer accumulate memory over time.
A team does not need to be large from day one. Starting with two or three roles with clear responsibilities and adding members once task boundaries settle usually works better than stacking many roles at once.