Tasks, agents and sessions.
A task describes an outcome. An agent describes a role. A session is a particular native conversation on a particular device.
| Concept | Meaning | Example |
|---|---|---|
| Project / workspace | The work context: repository, working folder and relevant board. Native and Desktop project placement are separate mappings. | A repository and its worktrees on a selected worker. |
| Board | The primary place for project tasks, assignment and status. | A project delivery board. |
| Task | A bounded goal with acceptance, an owner and evidence. | Verify reconnect preserves saved progress. |
| Agent | A configured role and permitted behavior. The role may outlive a conversation. | A delivery owner or a reviewer. |
| Session | A native provider conversation identified with participant, host, provider and native identity. | A Codex review conversation on a worker. |
| Device / client | An enrolled PC or worker reporting within its approved scope. | A Windows PC with approved project roots. |
| Receipt | Evidence that a specific stage occurred. | Request stored, native reply received, or Desktop opened. |
One task can need several sessions
A developer and reviewer can contribute separate sessions to one outcome. A successor session can take over a bounded slice after a durable handoff. Changing the conversation does not change the task’s acceptance criteria or automatically complete it.
Assignments reference sessions; the same session may be linked to more than one task. A task assignment is not permission to start inference. Folder names, titles and process IDs do not uniquely identify a session.
Keep four kinds of state separate
- Connectivity: when the server last accepted a device report.
- Native runtime: whether the native provider has supported evidence of active work, a question, an approval wait or an ended turn. Often unknown for discovered sessions.
- Session disposition: whether a conversation was handed off, parked or finished for its current purpose.
- Task acceptance: whether the requested result and checks satisfy the work.
Where truth lives
The DELEGATOR board is primary for tasks, assignment and recorded acceptance. Native tools own native execution, authentication and permissions. GitLab merge requests, commits and pipelines provide external change evidence; issues are fallback references. A successful pipeline or merged change does not by itself mark a board task done.
Summaries, project suggestions, model labels and UI status are projections of evidence. If evidence is missing, stale or ambiguous, “unknown” is a useful result.
Concrete example
“Fix reconnect” is a task. A delivery agent starts a Codex session in the project folder; a reviewer uses another session. Both are linked to the task. The client later reconnects and reports fresh metadata. The task remains in progress until the owner records the actual fix, review and verification. Neither reconnection nor a completed provider turn supplies that proof.