How the coworkers platform works

The e2m envelope is the one contract every coworker binds to. Everything else — queues, mailboxes, peer messaging, approval gates — is built on top of it.

The e2m envelope

Every unit of work is a typed e2m (envelope-to-message) object: a task, an evaluator (how the manager will grade the result), and a state. One schema (cowork/schemas/envelope.zod.ts) is the source of truth; every language binding — TypeScript (@coworkers/e2m-ts), Terraform (e2m-tf), Rust (e2m-rs), Python (e2m-py), a CLI (e2m-cli), and the Swift app (e2m-swift, iOS/iPadOS/macOS) — is generated or bound from it, never hand-forked. That's the rule that keeps fourteen coworker plugins and six languages from drifting apart.

How work actually runs

The envelope is the contract; Dispatch is the engine. Cowork's own primitive — it "takes high-level instructions and carries them out in the background… breaks it into tasks, runs each one as a separate Cowork or Code session, and surfaces the results when they finish" (claude.com/docs/cowork/guide/dispatch) — is mechanically how a queue of typed e2m tasks becomes parallel per-coworker sessions and, on this operator's fleet, how 60+ verified deploys land in a working day: outcome in, gated waves out, the build system catching drift between them.

DurableTask queues, not a task list

Each domain owns a JSONL queue (engineering.jsonl, finance.jsonl, operations.jsonl, ...) and a mailbox. A coworker reads its mailbox, claims the highest-priority pending task, executes it atomically, and writes a state transition — pending → in_progress → completed / blocked / failed — back to the queue. Nothing is silently dropped: a failure that can't be resolved gets classified resolvable / unresolvable / requires_escalation and written back with a suggested_skill pointer, so the next session (or the next coworker) knows exactly where to pick up.

Peers, not a tree

A coworker can message any other coworker directly — product-management is the default router, but finance can message engineering without going through a manager first. Transport is a2a (tasks/send over an a2a-bridge, one per role) for peer-to-peer work and mcp for tool calls. Each role publishes /.well-known/agent-card.json listing its skills and gates, so peers know what it can do and what needs approval before asking.

Naming

Every coworker resolves to {device_surface}__{client_surface}__{coworker_enum} — for example macos__desktop_cowork__engineering_coworker (this Mac, Claude Desktop Cowork, the engineering role) versus cloud__docker_mcp__engineering_coworker (Anthropic's cloud inference, the Docker MCP Toolkit catalog, same role). Code written for one surface doesn't assume the other's tools are available.

Related

• Role taxonomy
• Approval gates
• Memory — what persists across sessions