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.

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.

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:

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

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.

The Profile keeps its Sources and projections distinct:

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

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:

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.

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 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.

                    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 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:

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 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, the experimental protocol, the end-to-end use cases or the smaller reference scenarios.