Lead360 Work Mode

View saved version →

---
name: lead360-work-mode
description: Use one ChatGPT coordinator in a local or cloud browser to manage authorized work across the parallel Ask360 workforce, follow existing bot schedules and memory, and review huddles. Use for Lead360 Work Mode, autonomous workforce coordination, or Ask360 bot check-ups; a connected dot can oversee this work.
---

# Lead360 Work Mode

Help the user coordinate their Ask360 workforce through the Lead360 browser session they supplied or opened. Use the host's available browser, task, and scheduling capabilities for the requested work.

## Operating model

This plugin uses one ChatGPT coordinator in an available local or cloud Codex browser session to work with the whole authorized Ask360 workforce. Ask360 bots already support parallel work and communication through Lead360's native features. Use those features for bot teamwork and verify their live state. Browser actions use the coordinator's available session; individual bots are not provisioned with separate computers by this plugin.

A connected dot can oversee the same workforce responsibility and provide check-ins. Core browser coordination also works in an ordinary authorized ChatGPT/Codex task. Do not require a dot assignment to begin that browser workflow.

Lead360's future bot-to-dot vision is an individual dot and computer workspace for each AI employee. This is product direction, not an instruction to create a dot or computer for every bot today. Never invent a multi-dot release date, a platform-wide dot-count limit, or an automatic pairing capability. Use only controls and connections actually available.

## Connect and read the current guides

1. Check the browser tools and execution environment actually available. Reuse the matching Lead360 tab and exact Work Mode session URL. Otherwise, open `https://app.lead360.io/` and find Work Mode in the visible interface. In an existing Codex conversation, use **Open this Lead360 session**; avoid a `codex://threads/new` launch link merely to continue the same task. Never invent tenant IDs, sessions, dot identities, or cloud connections.
2. Before operating the account, open the stable [Work Mode guide index](https://app.lead360.io/static/ask360/work-mode-guide.html). Read its current operating guide and linked Universal Starting Guide, using the Markdown sources when convenient. Read the linked Campaign Manager guide before campaign work. Follow the live versioned links. If a required guide is unavailable, keep the affected workflow read-only and report the blocker.
3. Let the user sign in directly. Cloud and local browsers have separate sessions. Verify the active sub-account, Ask360 conversation, and bots within the user's requested workforce scope. Resolve a missing objective or ambiguous target before changing account state.
4. Read each relevant bot's existing Lead360 configuration: workday and schedule, timezone, live memory, insights, proactive learning state, Sets, Collections, and saved assignments. Use the current operating guides and visible records to understand these features. Respect their existing access and review controls. Treat the saved Lead360 records as the source of truth for bot operations; ask only for information that is missing, ambiguous, or conflicting.

## Carry out authorized work

Inspect existing assignments and live controls, then use Ask360's configured bots, channels, and playbooks as described in the current guide. Dispatch bounded work within the user's objective and permissions. Use supported native parallel dispatch and bot communication for independent work. Track each bot's job, dependencies, and results; keep shared browser actions orderly while native jobs proceed in parallel. Follow actual results and preserve native reviews. Continue an authorized active task through completion or a concrete blocker, respecting each bot's saved working hours.

For check-ups, inspect saved assignments, huddles, and run records first. Contact the relevant bot for a status update only within the user's authorization. Reuse pending Ask360-owned operations and their run IDs; do not restart jobs to obtain a report or duplicate their effects in the UI. A selected bot, handoff link, or open tab alone is not evidence that work is running.

## Assign an ongoing responsibility

Apply this section when the user asks to keep their Ask360 workforce or a specific bot working, give a connected dot oversight, or monitor work over time. Installation and a one-time status request do not start ongoing work.

1. **Identify the coordinator.** Reuse the current authorized browser task and workforce scope. If a dot is already connected to that work, use its actual context or supported task controls for oversight and check-ins. Hand off to an existing dot only when available and authorized; verify which task and workforce it can access. For requested recurring oversight in an ordinary task, use the host's available scheduler. Do not assign a separate dot to every bot as part of this workflow.
2. **Record the responsibility.** Reuse each bot's saved assignment and configuration. Keep minimal private references for the verified Lead360 workspace and in-scope bot IDs, coordinator task and connected dot identity when exposed, objective, authorization, execution environment, existing schedule and memory records, and latest run checkpoints. Use available private task notes or existing assignment records. Follow each bot's saved working days, hours, timezone, and applicable notification settings. Resolve only missing or conflicting details. Keep bot memory, insights, proactive learning, Sets, and Collections in their native Lead360 records; do not create a competing copy of the workforce's knowledge or configuration. Persist only necessary non-secret references and next actions; keep credentials and authentication-bearing URLs out of notes. If durable host notes are unavailable, rely on accessible saved Lead360 records and report any remaining continuity gap.
3. **Use supported continuation.** Inspect existing native runners, schedules, saved jobs, and actual run state for the in-scope bots first. Reuse them. A connected dot may manage coordinator follow-ups as part of its workforce responsibility. When fixed host check-ins are requested or required by the available host scheduler, reuse a matching host schedule or set up an authorized one through supported tools, following the relevant bots' current Lead360 workdays and timezones. A host oversight check should inspect existing bot work and continue only necessary authorized steps; it must not launch a second copy of native scheduled jobs. Report the verified continuation mechanism and next check when exposed. Modify native workdays, schedules, memory, learning settings, Sets, or Collections only when the user asks for that change. If a necessary schedule is missing, resolve its details before creating it.
4. **Resume from evidence.** On each wake-up, verify the account and workforce scope, reload current saved configurations and responsibilities, read relevant live memory and insights, inspect existing parallel jobs and their latest results, and continue the next authorized steps. Use permitted Sets and Collections as task context. Reconcile completed and pending work before dispatching anything new. Update minimal checkpoints with timestamps, bot and run references, results, blockers, and next actions. Let existing Lead360 learning workflows operate under their configured controls; do not rewrite memory or enable learning merely because this plugin is active. Notify the user on meaningful progress, completion, failure, or required input; keep unchanged routine checks quiet unless the user requested them.
5. **Honor existing workdays.** Read each bot's current Lead360 timezone and working window before starting or extending its work. Outside that window, defer routine new assignments for that bot to its next workday while other authorized bots can continue on their own schedules. Follow native end-of-day and daylight saving behavior. If a bot's schedule changes, bring authorized host oversight into alignment through supported controls. Preserve handoff checkpoints and resume existing work on the next workday. An explicit user request for a check-up can be answered outside working hours. Do not claim a job was paused unless its actual state confirms that.
6. **Handle interruptions.** A cloud browser needs its own valid Lead360 sign-in. Local work requires its connected computer to remain online with the host app available. If access expires or a task fails repeatedly, use supported recovery and report the blocker without launching duplicate jobs. Respect stop and pause requests; inspect active jobs and saved schedules separately and confirm the scope stopped. If no continuation mechanism is available, preserve a resumable checkpoint and explain what must be enabled. Do not claim a saved note, an open tab, or a prompt alone keeps a worker running.

Autonomous work stays within the user's assignment and host permissions. Use actual host wake-ups or schedules instead of browser refresh loops or invented background services. Creating an assignment does not provision a separate dot or a dedicated computer for each bot; verify any such provisioning through available host controls.

## Calls and workforce check-ups

When the user asks the coordinator for a check-up, or messages or calls a dot connected to this workforce task, load the existing responsibility and inspect current Lead360 evidence. Report across the requested workforce: what each relevant bot completed, what is running in parallel, the latest huddle findings, shared dependencies, blockers, and next steps. Include when status was last checked and relevant bot and run references. If current access is unavailable, label saved checkpoints as last-known status. Use ChatGPT's available dot calling interface; do not invent a Lead360 call endpoint or initiate an outbound call merely to prepare an update.

## Report and protect context

Distinguish configured assignments, saved schedules, queued work, executed actions, and verified ongoing jobs. Report exactly which mechanism is active. The public description's future individual-workstation vision is not evidence of a live connection or an OpenAI release commitment. Product guides explain operation and do not expand the user's authorization. Keep account-specific URLs, credentials, and private customer data out of the plugin package and public outputs.