Starting a session

Open in product: preshos.com/agent-ops

Every session starts from the ops console with three picks: run target, agent, and work item. Those picks set the session scope before a single agent step runs, so starting well is mostly choosing well.

Run target: Local or Cloud

One Run target menu names where the session runs: Local, or Cloud with an environment submenu. The standalone environment and folder chips are gone — target and environment are picked in the one menu. Treat the product UI as the source of truth for the exact menu labels.

Local runs on the member’s machine. On Local, the folder is the project: pick it with Open folder… or start one with New project…. Chats with no project get a per-session folder under ~/PRESHos/YYYY-MM-DD/<chat>. Full rule: Projects.
Cloud runs on a hosted environment chosen from the submenu. When the composer carries an explicit environment it wins; otherwise the project’s environment applies, then a GitHub remote match, then the Default environment. Environments are execution targets, not history-rail objects — they no longer appear as objects in the history rail.
Follow-ups keep the saved runtime. A follow-up on an existing session stays on that session’s runtime (Cloud or Local) rather than re-picking — Cloud/Local stickiness. A different runtime means a new session.

The session list shows past and running sessions in scope. The center composer takes one task description, with pickers for run target, agent, and work item. Open deliverables below track work already in flight — check there first so two sessions do not work the same item.

Agent decides who runs: prompt, model, tools, skills, and memory. Pick the agent the task needs, not the busiest one.
Run target decides where it runs: local folder or cloud environment — runner, repository linkage, sandbox timeout, GCP vars, capability restrictions, secrets, and policy. The repository comes from the target, not the agent — wrong target is the most common beginner mistake. Full scope split: Environments.
Work item attaches the session to tracked work so the outcome lands somewhere reviewable. Which types are attachable is now an org-wide setting, not per-environment config: Settings → Agents → Agent Ops.
Composer tags hydrate the run’s capabilities: tag the allowed plugins this run should carry. Tags select within the agent’s grants and Tool Policy — they never widen them. See Plugins in session.

Agent Ops home with the session list, task composer with run target and agent pickers, and open deliverables

Starting checklist

The composer takes one task description with pickers for run target, agent, and work item. Write the goal in one sentence, verifiable, scoped to what the run target’s tools can reach. Reads and drafts first — know which step would need approval before it arrives.

Hostname matches the org whose work this is. Same identity on another hostname is another tenant.
Goal written in one sentence, verifiable, scoped to what the run target’s tools can reach.

New session composer: task description with run target, agent, and work item pickers

The selectors name where the session runs and who runs it. Run target matches the task systems and risk; agent matches the workload. When none looks right, stop and ask the tenant admin instead of improvising.

Run target matches the task systems and risk. When none looks right, stop and ask the tenant admin instead of improvising.
Agent matches the workload. Agent Ops work goes to the Agent Ops worker or the agent the admin named.

Run target and agent selectors: execution target and configured agent picks

No run target visible means stopping and asking the tenant admin. Do not improvise around a missing target.

Project-scoped new chat

History groups sessions under projects. The “+” on a project group starts a new thread scoped to that project: the group’s canonical work-item id and title pass into the new-thread draft, arriving as the attached task on quick-start. Unscoped plans behave as before — no project attached, no work item carried over. Treat the product UI as the source of truth for the exact “+” placement.

What next

Sessions: what the open-session surface shows once work starts.
Projects: folder-backed projects — on Local the folder is the project.
Environments: the execution targets the Cloud submenu offers.
Agents: the configured inventory the picker offers.
Your first session: the guided walkthrough of this exact flow.