# The Workplace-first Proposal Status: Open Proposal V3 · living argument, not normative protocol ## Designing durable workplaces for humans and AI agents I reached this model through ordinary use. I worked with Codex and Claude across the same body of work, added instructions when context went missing, added Skills when a method deserved reuse and connected more repositories as the work expanded. Friends and colleagues described similar setups. Their environments combined rules, memory, scripts, hooks, runtimes and dashboards. Each addition addressed a concrete problem. The resulting systems could execute more tasks while leaving four questions open: - Who owns each instruction? - Which source represents current truth? - Which work should survive the session? - Which repository or service owns the delivered result? Memory can preserve information. It cannot decide who owns it or when it becomes truth. Tools can expose capabilities. They cannot assign ownership, authority or lifecycle to the information and results they handle. Workplace-first is the paradigm: it treats the durable place as a first-class design concern. Open Workplace publishes a shared, implementation-neutral responsibility model for that place and an independent experimental protocol, `open-workplace/0.2-draft`. ## Workspace and Workplace describe different boundaries A workspace often names an execution or editing scope. It may be a directory, repository, IDE project, mounted file set or provider sandbox. That scope helps an agent find files and determines which operations a host permits. A Workplace names the durable place that owns the work. It has an identity, responsibility boundaries, domains, reusable practices, time transitions and relationships to external truth. A workspace may expose a whole Workplace, one part of it or several candidate Workplaces. Visible roots provide evidence. They do not settle ownership. ```text Visible workspace Candidate Workplace repository roots → declared boundaries or external authorities provider instructions → Sources with owners and audiences Skills and scripts → reusable methods notes and memory → Material with unknown authority or durability remote services → Relationships to external authorities ``` An agent can inspect the left side and propose the right side. A human and a declared implementation establish the boundary and authority. ## Move the center of gravity Prompt-centric design shapes one interaction. Agent-centric design equips an occupant with memory, tools and instructions. Both remain useful. Workplace-first asks what the place must preserve when the prompt, agent, provider, runtime, method or repository changes. ```text Prompt-centric shape the interaction Agent-centric equip the occupant Workplace-first equip the place the occupant enters ``` The provider still owns model execution, tools, sandboxing and session state. The human keeps intent, judgment and consent. The Workplace owns durable context, placement and relationships. This separation can reduce provider configuration. Each provider projection can receive the Sources relevant to the current objective. The remaining Material stays in its owned place instead of travelling with every agent. ## A familiar place A developer joins a team and enters a place where projects, rules and systems already have owners. The developer does not carry the company in a personal notebook. They learn the shared constitution, work inside one domain, use the team's methods and reach product systems through known paths. An agent needs the same environmental clarity when the work must continue. Its execution may last one session. The Workplace remains after it leaves. Consider a small software studio: ```text Declared studio Workplace ├── Source · shared constitution · studio owner ├── Source · product direction · product owner ├── Material · retained research summary ├── Projection · provider entrypoint ├── Relationship → product repository └── Relationship → public website ``` Claude can resolve the Sources relevant to a launch objective and produce a candidate summary. Maya can retain that summary for review. Codex can enter a later session, resolve the retained Material and prepare a website change. Maya decides whether to accept the message and authorize an external effect through the website Relationship. The two providers need access to the owned Workplace sources. They do not need each other's private session memory. ## Five properties of a first-class Workplace ### Identity The Workplace has a name and boundary independent of one session, provider or repository. An occupant can leave while the place remains addressable. ### Ownership Each durable responsibility has a maintainer and correction boundary. Shared rules, personal preferences, domain decisions and product constraints keep distinct owners even when one projection presents them together. ### Composition Humans, agents, methods and external systems can participate without becoming the permanent center. The Workplace can change an interface or participant while preserving its durable organization. ### Time Execution produces candidates. Human-controlled transitions determine which results remain inspectable; currentness, acceptance, completion and external effects remain independent. ### Sovereignty Repositories, products and services keep their own history, permissions and truth. Relationships can reach them without absorbing their authority. ## The shared responsibility grammar | Responsibility | Question | | --- | --- | | Workplace | Which declared durable boundary owns the context? | | Workspace | Which execution or editing scope merely exposes evidence? | | Profile | How does one implementation represent the shared responsibilities? | | Source | Which owner establishes each claim? | | Projection | Which representation is rebuildable from its Sources? | | Material | Which addressable content has a known owner and durable state? | | Relationship | How is another authority reached without transferring ownership? | | Resolved Workplace Context | What is the smallest owned context sufficient for this objective? | | Provenance | Where did each claim come from, and who can correct it? | | Authority | Who may establish a claim or authorize an effect? | These responsibilities serve as design checks. Open Workplace does not assign one directory, service or screen to them. ## One concrete vocabulary, not a universal ontology Endroit, the first observed Profile, gives those responsibilities one concrete local-first representation. Open Workplace 0.2 does not require another Profile to use or translate it. | Endroit 0.10 binding | Durable responsibility | | --- | --- | | `WORKPLACE.md` | Workplace declaration and constitution | | Member, Desk and Room Documents | Human continuity at explicit scopes | | Equipment | Reusable Capabilities and provider surfaces | | Owned Documents and Fragments | Source authority and addressable structure | | Material and optional Artifacts | Durability plus useful validation contracts | | Site and Route Documents | External authority and declared Relationship | | Checkout | Derived local address, never ownership | | `ResolvedWorkplace` | Objective-bounded derived context and provenance | | Provider outputs | Rebuildable Projections | The Profile keeps its Sources and projections distinct: ```text WORKPLACE.md + owned Documents ─resolve→ ResolvedWorkplace ResolvedWorkplace ─builds→ provider Projections Desk ─declares→ Route ─relates→ Site Route ─resolves→ Checkout ``` The arrows describe responsibility and composition. They do not require filesystem containment. Equipment does not own the Material produced with it. A Site keeps its authority when a checkout sits inside a Workplace. ## Three planes, separate authorities ```text Execution plane provider · runtime · temporary state Workplace plane Sources · Material · Relationships · resolution External plane independent truth · permissions · observed effects ``` The provider or harness supplies execution and temporary state. The Workplace supplies durable context and organization. External authorities keep their own truth. The human crosses the three regions through direction, judgment, acceptance and delivery consent. An application can participate in more than one region. It should still state which responsibility it owns in each one. A desktop app may visualize owned domains and run agents. A memory system may retrieve retained Material. A runtime may coordinate several executions. Those capabilities do not transfer ownership of the Workplace Sources. ## Execution produces candidates Open Workplace separates Material durability from the other judgments and effects that may concern it: ```text durability ephemeral → retained → archived currentness current | superseded | withdrawn acceptance exact revision + human authority completion contract + revision + evidence external effect intended | attempted | partial | failed | observed ``` - Retained Material stays inspectable without becoming current truth. - Archived Material leaves the active working set without silent deletion. - Acceptance records human judgment on one exact revision. - Completion is relative to a contract, revision and evidence. - An external effect records observation; it never becomes a Material state. A transcript, provider history entry or generated file does not become durable by existing. The human chooses the transition and its owner. None of these axes advances another. Selective retention lets a Workplace compound. A later execution can resolve retained research, accepted decisions, reusable methods and verified Relationships without loading every earlier conversation. ## Orientation belongs to the place An agent needs a dependable entrypoint before it can use the model. The entry should identify the declared Workplace, Profile, relevant Sources, Material and Relationships. It should also expose missing or conflicting authority. ```text enter ↓ identify protocol and implementation profile ↓ resolve the declared Workplace and relevant Sources ↓ reduce to the objective-bounded context ↓ expose relevant Material and Relationships ↓ report limits before consequential work ``` The experimental [Open Workplace Protocol](protocol.md) specifies this interpretation. It can reach an agent through a local document, public URL, provider adapter or generated entrypoint. A CLI can validate the sources, but the protocol keeps static sources useful when that CLI is absent. The protocol defines semantic behavior. It does not control the model, sandbox, operating system or network. ## Several agents can share one Workplace Explicit ownership can support multiple agents without requiring a resident coordinator. ```text declared Workplace │ ┌──────────────┴──────────────┐ │ │ product Sources launch Sources execution A execution B Codex runtime Claude runtime │ │ product Relationship website Relationship ``` Each execution can resolve a separate working set and target a separate owner. Agents reduce accidental overlap when their Sources, Material and destinations differ. Ownership does not replace file locks, transactions or merge conflict handling when two executions write the same Source. A runtime may strengthen scheduling, cancellation and coordination. The static model remains useful before that runtime exists. ## Implementation profiles Open Workplace defines semantic responsibilities. An implementation profile discloses how one system represents them. A profile names its discovery rules, identity sources, object mapping, authority rules, projections, validation, degraded behavior and limits. It also states which model concepts it cannot represent. [Implementation profiles](profiles.md) remain agent-readable Markdown in this Working Draft. The corpus defines no registry, adapter API or required serialization. Endroit is the Workplace-first application framework and the first observed implementation. Its qualified local `endroit/0.10` release candidate targets `open-workplace/0.2-draft`; it declares a Workplace in owned Markdown, resolves its Sources and builds provider Projections without requiring a resident process for the static Workplace to remain legible. It has not yet been published or deployed. Endroit owns that file mapping and its operations. Work Resolution is one Endroit-owned extension for moving intent toward a verified effect. It is evidence of what an implementation can add, not an Open Workplace primitive or a requirement of `open-workplace/0.2-draft`. ## Recognition and transposition Many environments contain Workplace-shaped responsibilities before their owners name them. Repositories, instruction files, procedures, notes and external services can support a candidate map. The proposed transposition flow separates observation from application: ```text recognize → describe → map → propose → apply → verify ``` The human selects the roots an agent may inspect. The agent records observed evidence, marks inferences and exposes decisions that need confirmation. It can present several candidate Workplaces and recommend one. A selected candidate can then be compared with an implementation profile. The proposal must preserve provenance, ownership, authority and lifecycle, and it must name losses. Application requires a separate human authorization. A fresh session verifies the resulting Workplace without relying on the transposition conversation. [Workplace transposition](transposition.md) describes this direction. Endroit demonstrates one path into its own profile. Exchange between two independent implementations has not been tested. ## Evidence and limits The Endroit Workplace where this model emerged demonstrates that: - owned files can carry continuity across Codex and Claude sessions; - one Workplace can coordinate independent repositories while they keep their Git ownership; - static orientation can work without a daemon; - an agent can recognize approved roots and propose an Endroit map without moving the repositories. The evidence covers one evolving Endroit Workplace and one declared implementation. It does not show that every setup needs added structure, that the vocabulary improves model intelligence or that two implementations preserve the same meaning. The protocol, profiles and reference scenarios form the experimental `open-workplace/0.2-draft`. Usage should change them when an owner is missing, a rule creates needless friction or a legitimate environment cannot fit the model. ## Try the lens Map one environment you know. Identify the shared rules, personal continuity, durable domains, reusable methods, temporary work and external authorities. Stop if the extra structure adds no value. If the model helps, inspect where ownership became clearer. If it fails, describe the missing owner or the responsibility it distorts. Those cases can test the proposal before more implementations build on it. Continue with the [architecture](architecture.md), the experimental [protocol](protocol.md), the end-to-end [use cases](use-cases.md) or the smaller [reference scenarios](reference-scenarios.md).