--- title: "One Orchestrator Session per PersonaBot; Assignment Sessions are independent" version: "en" --- > Documentation Index > Fetch the complete documentation index at: https://botharness.ai/llms.txt > Use this file to discover all available pages before exploring further. # One Orchestrator Session per PersonaBot; Assignment Sessions are independent A PersonaBot is a person with several concurrent lines of work: one Orchestrator Session owns its Inbox and dispatches work, while every work item runs in an independent root Session that can live in its own Workspace. We rejected modeling Assignment Sessions as DSH continuable subagents of the Orchestrator: `childSessionMeta` hard-copies the parent's cwd and preset (a child cannot take a different Workspace), subagent-owned identities are fenced from generic resume and prompt by the session controller, the default activation budget is 8 live children per tree with no queueing, tool delegation depth defaults to 1, and a parent session-id change (fork/rollover) orphans children with no reparenting. Independent root Sessions keep first-class roster visibility and Workspace freedom. Cross-Session messaging is therefore BotHarness-owned: `plugin`-kind relay messages (`relay` / `notice` / `snapshot` forms), request/reply correlation, and bounded waiting. Assignment Sessions do not message one another directly in v1; they report or request through the Orchestrator, which performs any explicit forwarding. Cross-PersonaBot traffic also goes through the receiving Orchestrator. The Orchestrator Session keeps a stable session id (no rollover), wakes on Inbox batches instead of running resident, and manages context with the shipped `compaction-basic` policy. ADR-0045 deepens that control plane: the Orchestrator manages owned Assignment Sessions through a durable Assignment Directory and exact addressed Assignment Requests rather than relying on what its current context remembers. DSH `ctx.agents.create()`, `resume()`, `followup()`, `steer()`, `inject()`, and live AgentHandles remain implementation details behind the Host-lifetime Assignment Runtime. An Assignment Session is a runtime and domain identity for one Human-meaningful line of Assignment, not a Conversation the Human must create or manage. The Human talks only to the PersonaBot's DM; that input enters the Bot Inbox, the Orchestrator decides whether it can answer directly or dispatch Assignments, and only owned Assignment Sessions appear in the subordinate Assignments list. The Orchestrator itself is never presented as an Assignment. ## Considered Options - **Continuable subagents (native parent/child)** — rejected: the Workspace hard-copy alone is fatal; the UI/resume fence, per-tree activation budget, depth default, and orphan-on-rollover make it worse. - **Host policy only, no model orchestrator** — rejected: the PersonaBot must answer cross-project questions and choose dispatch like a person; policy alone cannot read a Session's state and answer for it. - **Fan the Inbox out to every running Session** — rejected: token cost and interruptions scale with chatter, not with work. - **One all-purpose PersonaBot Session** — rejected: unrelated work, group attention, and DM replies would serialize into one context with no independent Workspace, cancellation, recovery, or truthful per-Assignment state. - **Human-created Conversations as the only parallelism model** — rejected: it makes the Human organize execution before a personal PersonaBot can handle one natural-language request. Letta-style Conversations validate shared-Memory parallel contexts, but BotHarness assigns their creation and management to the Orchestrator. - **Use Work Session, Worker Session, or Executor Session** — rejected: Work and Worker are easy to confuse in speech and typing; `worker` also suggests a subordinate process identity, while the Agent—not the Session—is the DSH executor. Assignment is distinct from both the Orchestrator role and DSH Subagents. ## Consequences - We own relay durability, de-dup, request/reply correlation, timeouts, and completion notices. DSH provides the primitives (`agent.followup/steer/inject`, `agent/status`, `session/event`, `sessionQuery`, `tokenMeter`) but no adjacency guarantees between peer Sessions. - The Orchestrator is at most one active Session at a time per PersonaBot; its id must stay stable so routing survives context compaction. Zero or more Assignment Sessions remain independent roots. - A Host-lifetime runtime owner, not the Orchestrator's scoped Agent context, owns the live `AgentHandle`s for Assignment Sessions. An Assignment Session therefore survives Orchestrator teardown and is reconstructed from durable Session ownership after Host restart (ADR-0035). - Assignment inventory, addressed messaging, explicit continuity, autonomous dispatch, and durable Assignment Reports follow ADR-0045. - The Human-facing UI says Assignment and lists only Assignment Sessions by purpose and state. Chat is the Orchestrator's surface; the Orchestrator Session is not a visible Assignment row. - v1 has no peer Assignment-to-Assignment relay. The Orchestrator is the sole manager and forwarding point for independent Assignment Sessions. - Do not invent a novel message source kind: the v2→v3 Session migration validates a closed source set. Use `plugin` with `relay`, `notice`, or `snapshot`. - Facts verified against `deepseek-harness` `ddefc45` (2026-09-17): `packages/subagent/subagent/src/child-agent.ts` (cwd/preset copy), `packages/api/session-controller/src/agent.ts` (subagent fence), `packages/subagent/subagent/README.md` (activation budget, depth), `packages/subagent/subagent/src/continuation-activation.ts` (lineage, orphan behavior). Source: https://botharness.ai/dev/adr/0024-orchestrator-session-per-personabot/index.mdx