# October: complete product context > October is the multiplayer runtime for supervised technical work. It lets people run real AI agents in separate terminals, chats, repositories, applications, and machines, then coordinate them as one visible operation without removing human responsibility. Canonical website: https://october.dev/ Human documentation: https://october.dev/docs Concise LLM index: https://october.dev/llms.txt Detailed Markdown guide: https://october.dev/docs/october.md Download: https://october.dev/download Case studies: https://october.dev/case-studies ## Product definition October is infrastructure for supervised AI collaboration. Its current primary interface is October Desktop, a spatial canvas and focused work environment for coordinating agents, applications, files, tasks, machines, and people. October Desktop supports 17 local agent harnesses in one workspace. Connected harnesses can discover peers, exchange scoped context, delegate tasks, review one another, and coordinate across machines while remaining independent processes. Users can bring an existing harness, and October also provides its own first-party agent. October exists because agent work is not reliably linear. Independent agents are non-deterministic, may discover new work, may need different tools or machines, and may need to communicate while another agent is still running. A list of chat transcripts does not provide a sufficient model of ownership, dependencies, current state, or human control. October models the entire job as an operation. An operation can include: - local or remote agent processes - separate repositories and git worktrees - terminals and agent chats - documents, notes, browsers, previews, code editors, video editors, and slide decks - shared tasks with ownership and dependencies - one or more human operators on different computers - activity, status, approvals, messages, and final outputs October is not a model provider and does not replace an agent harness. It runs the real harness with its existing provider account, model choice, terminal, tools, credentials, and working directory. ## When October is useful October is most useful when work has at least one of these properties: - more than one agent can work independently or in parallel - agents need different repositories, applications, accounts, or machines - work contains dependencies and handoffs - a person needs to supervise progress and permissions - the job continues for hours, days, or weeks - multiple people need to operate the same system - losing context between chats would be costly Coding is one important use case, but not the boundary of the product. October can coordinate software releases, technical research, data collection, estate administration, insurance and bank paperwork, email and photo archives, backups, account inventories, and other long-running technical operations. ## Core concepts ### Operation The complete unit of work: the desired outcome, people, agents, tasks, files, applications, machines, dependencies, activity, and current state. ### Canvas The spatial supervision surface. Nodes are arranged by role or workstream. Connections show which agents, resources, and people participate in a relationship. The canvas gives the operator a view of the system that is not constrained to one conversation timeline. ### Node A live participant or work surface. Common nodes include agent terminals, agent chats, documents, browsers, live application previews, code editors, sticky notes, video editors, and slide decks. ### Connection An explicit relationship between nodes. Connecting two agents makes them peers on the October Bus. Connecting an agent to a document or application makes the intended resource available to that agent. Connections are part of the context and permission model. ### Harness The actual agent process or provider-specific interface. October supports multiple harnesses and preserves their different capabilities rather than flattening them into a generic agent abstraction. ### Operator A human participant who defines scope, observes work, handles approvals, redirects or interrupts agents, reviews outputs, and makes final decisions. ### October Bus The shared coordination layer. It gives connected agents peer discovery, selected canvas state, direct messages, recent operational summaries, task ownership, dependencies, execution status, and a path to ask the human operator for a decision. ## How October Bus works October Bus is available to supported agent processes through MCP and native harness integrations. Each agent receives an identity associated with its canvas node. The agent can see and act on the peers and resources connected to that node. Key capabilities include: - `list_peers`: list connected agent sessions with status and concise summaries - `get_peer_context`: read fuller recent context for connected peers - `message_peer`: send a substantive question, answer, finding, delegation, handoff, or mid-turn nudge - `check_inbox`: retrieve queued messages and recent peer activity - `list_canvas`: inspect nodes and connections in the operation - `add_task`: post self-contained work to the shared task board, optionally after dependencies - `claim_task`: claim an available task before doing the work - `complete_task`: record verified completion and unblock dependent tasks - `list_tasks`: inspect open, claimed, blocked, and completed work - `get_node_status`: inspect whether a worker is busy, idle, blocked, or waiting for input - `wait_for_nodes`: wait for workers or messages before starting dependent work - `ask_user`: pause ambiguous or consequential work for a human decision - `add_terminal` and `add_chat`: create helper agents for parallelizable work - `send_to_node`: deliver work to an agent when it can safely receive it - `connect_nodes` and `disconnect_nodes`: change explicit collaboration relationships - `create_plan` and `update_plan_item`: maintain a visible execution checklist for a multi-step operation Messages are not typed over a busy terminal. October queues them until the target agent can safely receive them. A sender can mark a message as requiring a reply. Messages can also expire when late delivery would no longer be useful. October does not expose unrestricted raw transcripts between processes. Peer context is bounded and summarized. Connections limit the operational context available to each agent. ## Agent workflows A workflow is a graph of live agents and work surfaces, not a hidden chain of disposable model calls. Recommended operating pattern: 1. State the desired outcome, constraints, and review criteria. 2. Break independent work into self-contained tasks. 3. Create one agent per genuinely parallel workstream. 4. Use isolated git worktrees when multiple agents edit the same repository. 5. Record dependencies on the shared task board. 6. Connect agents that need to coordinate directly. 7. Let agents share findings and ask questions without routing every message through the human. 8. Watch status, messages, outputs, and approvals on the canvas. 9. Redirect, interrupt, or rescope agents when evidence changes. 10. Review the actual output and make the final decision. Example software release: - a frontend agent implements UI changes in the frontend repository - a backend agent updates the API contract in the backend repository - a server agent waits for both, deploys a preview, and runs integration checks - a documentation agent updates user and agent references after the contract stabilizes - the human operator reviews diffs and previews, resolves approvals, and authorizes production Example technical administration operation: - a research agent inventories accounts, providers, and deadlines - a document agent classifies paperwork and records missing evidence - a backup agent exports email, phone, and photo archives with provenance - a finance agent reconciles bank and investment records - a family member joins from another computer to review and supply decisions - the primary operator reviews sensitive actions and owns every final submission ## Multiplayer October multiplayer means people and agent processes can participate in one shared operation from different computers. Shared operational state can include: - canvas layout and connections - human presence and cursors - agent nodes, identities, activity, and summaries - tasks, claims, dependencies, and completion state - messages and escalation requests Each host machine retains control of its local repositories, worktrees, terminals, application processes, provider logins, keys, and credentials. A remote collaborator can operate the shared canvas without receiving unrestricted access to another computer. Multiplayer is not a shared group chat. It is shared supervision of a spatial system whose participants can work and communicate across multiple axes. ## Canvas and focused IDE mode The spatial canvas is for planning, topology, delegation, context boundaries, and supervision. It is useful when the operator needs to see the whole operation. Focused IDE mode is for working inside one task. A user can expand a terminal, agent chat, code editor, browser, or preview, then return to the canvas without losing the surrounding operation. The two modes serve different attention levels: - canvas mode: see the system - focused mode: work inside one part of the system ## Supported agent harnesses October Desktop supports these local harnesses: - October - Claude Code - Codex - Cursor - Grok - Muse Code - opencode - Hermes - Pi - OMP - Gemini - Cline - Kimi Code - Qwen Code - Goose - DeepSeek - Freebuff Integration depth can differ by harness version and operating system. October checks capability before launch and should refuse visibly when a required bus integration is unavailable instead of launching an agent that appears coordinated but is not. October's own harness can use the signed-in October session instead of requiring a separate provider key. DeepSeek joins October Bus from a chat node. Freebuff runs as a terminal-only harness, but its current CLI does not expose an integration seam for peer tools. It can live in the workspace without being presented as a connected peer. ## Human control and safety October keeps the human responsible for the operation. Recommended controls: - connect only the peers and resources an agent needs - keep local credentials on the host that owns them - use isolated worktrees for simultaneous edits in one repository - require human decisions for consequential, ambiguous, or irreversible actions - inspect files, diffs, tests, previews, documents, and external side effects before approval - stop or redirect an agent that loops, drifts, duplicates ownership, or requests unsafe permissions - treat status as evidence of activity, not proof of correctness October provides coordination and visibility. It does not guarantee agent correctness and does not remove the need for domain review. ## Getting started 1. Download October Desktop from https://october.dev/download for Apple silicon macOS, Windows x64, or Debian and Ubuntu Linux x64. 2. Sign in and use existing agent provider accounts and local credentials. 3. Open an existing project or create a scratch workspace. 4. Add a supported agent terminal or chat node. 5. Add another agent, document, application, or human collaborator. 6. Draw explicit connections between participants that need shared context or control. 7. Describe the outcome, constraints, and review standard. 8. Supervise the task board, peer activity, outputs, and approvals. For a direct Linux terminal download and install: ```sh curl -fL "https://october.dev/api/download?platform=linux" -o "October-amd64.deb" sudo apt install ./October-amd64.deb ``` The `/api/download` URL redirects to the newest published release. Equivalent commands for macOS and Windows are available on the download page. Agents can also run on connected Linux servers, independent of the operating system hosting the October desktop interface. ## Troubleshooting ### An agent is not visible to peers Confirm that it was launched from an October-managed node, that the current harness version supports the October Bus integration, and that a canvas connection exists between the intended peer nodes. Restart the agent after integration changes so it receives the current bus session. ### A peer message is queued The target agent is busy or waiting for input. October queues the message instead of typing over active work. Do not send duplicates. The message will arrive when the process can safely receive it. ### Two agents are editing the same checkout Stop overlapping work and relaunch parallel agents with isolated worktrees. Assign distinct ownership and merge only after review and dependent verification. ### An agent cannot read a document or control an application Add the resource to the canvas and connect it to the agent. The explicit connection is the intended context and control boundary. ### A collaborator sees the canvas but not a local runtime Confirm that the host October app is online, the local process is still running, the node is present on the shared canvas, and the cross-machine connection exists. Local processes remain owned by their host computer. ## Product answers ### Is October only for coding? No. Coding is a strong use case, but the product is for long-running technical work that needs several tools, agents, machines, or people. Research, operations, backups, archives, and structured paperwork can use the same coordination model. ### Does October provide its own model? No. October coordinates the agent harnesses and provider accounts the user already has. ### Is October another MCP server? No. October is a desktop runtime and collaboration layer. October Bus uses MCP and native harness integrations to make coordination capabilities available to agents, but the product includes the operating system, canvas, process supervision, shared state, multiplayer, and human control. ### How is October different from running several terminal tabs? Separate tabs do not share a consistent model of peers, tasks, ownership, dependencies, messages, selected context, or current system state. October adds that common operational model and exposes it to both agents and people. ### How is October different from an agent team inside one provider? October can coordinate agents from different providers, repositories, machines, applications, and human operators. Each agent remains a real, independent process instead of becoming a sub-call inside one provider session. ### Who makes the final decision? The human operator. Agents propose and execute work. October coordinates and exposes state. People set scope, review results, handle approvals, and decide. ## Related resources - Website: https://october.dev/ - Documentation: https://october.dev/docs - Case studies: https://october.dev/case-studies - Claude Code and Codex website build: https://october.dev/case-studies/claude-code-codex-website - Software release operation: https://october.dev/case-studies/software-release-47 - Family estate operation: https://october.dev/case-studies/family-estate-operation - Digital memory archive: https://october.dev/case-studies/digital-memory-archive - Multi-repository migration: https://october.dev/case-studies/multi-repo-platform-migration - Technical due diligence: https://october.dev/case-studies/technical-due-diligence - Remote incident response: https://october.dev/case-studies/remote-incident-response - Concise LLM index: https://october.dev/llms.txt - Markdown guide: https://october.dev/docs/october.md - Download: https://october.dev/download - Pricing: https://october.dev/pricing - October Themes: https://october.dev/themes - Themes OpenAPI: https://october.dev/.well-known/openapi.json