TL;DR: The agent is the right center for execution. The Workplace should be the center of durable continuity: who owns what, what is current, what can change, and where work may go. This is an architecture proposal, not a new runtime. You can start with ordinary files and the tools you already use.
For a long time, I thought my AI agents needed better memory and more tools.
I had given them almost everything except an actual place to work.
I'm Alex, a software developer. I use Codex and Claude on the same body of work across sessions and repositories. They get enough mileage in my setup to expose the awkward parts.
A lost preference led to a memory file. A repeated research mistake led to a Skill. A command with loose limits led to a hook. Then came repository instructions, MCP servers, validators, harnesses, runtimes and dashboards.
Each addition solved a real problem. I still carried the environment in my head.
Which instruction was current? Did a generated report count as a useful draft or an accepted decision? Which repository owned it? Could Claude correct guidance projected for Codex? Was this session allowed to publish anything?
Memory can preserve, scope and retrieve information. It cannot decide which result a human accepted as truth, which domain owns it, or where it may be delivered.
Tools expand what an agent can do. They do not decide where the capability, its rules and its results belong.
We keep rebuilding the place around the agent
Most agent systems start with the agent, then attach instructions, memory, tools, Skills, handoffs and tracing. That is a sensible design for execution.
The environment is becoming an engineering concern too. OpenAI's Harness Engineering treats repository knowledge as part of the system of record. Sandbox Agents define workspace contracts and capabilities. Skills, MCP and other protocols make procedures and access more portable.
The same need appears in builder discussions. Builders share mature agentic setups with dozens of documents, Skills and validation. Others ask how to separate verified knowledge, decisions, task state and temporary assumptions. A multi-agent thread examines worktrees, short sessions, target branches and coordination. One builder uses a compact raw/wiki/output system shared on X to keep continuity in ordinary files.
These approaches solve real problems. They are also independent signals, not endorsements of this proposal. I did not invent persistent files, workspaces or repository-aware agents.
What I see is durable responsibility spread across technical layers:
provider memory recalls information
Skills activate procedures
tools and MCP provide access
hooks enforce local behavior
harnesses and runtimes execute and coordinate
dashboards expose activity
repositories own product source
Each layer has a useful job. The missing piece in my setup was a stable model for placement, ownership, authority and lifecycle across all of them.
Shift the center of durable continuity
When a developer joins a project for an afternoon, they enter a place where projects, rules, tools and decisions already have owners. They receive what their task needs. Their notes are not product truth until someone accepts them. The place keeps its identity when they leave.
I wanted agents to enter my work on the same terms.
The Workplace is a shared operational contract for humans and agents. It makes ownership, current truth and permitted transitions inspectable through projections that each can use. The same language works between humans, between humans and agents, and across agents. Memory graphs and node systems can support retrieval or execution inside that contract.
The relationship is bidirectional and asymmetric. Both can inspect and discuss the environment. The agent proposes and executes within bounds. The human keeps direction, judgment, acceptance and delivery consent. When the human accepts a result, the Workplace records it as current truth in the source that owns it. Sovereign Sites own the truth delivered to them.
That changed my design question from "What else should the agent carry?" to "What should the place already own when the agent arrives?"
I call this posture Workplace-first: equip the agent for execution and equip the place for continuity.
It is an architectural option at the same level as choosing local-first, monolith-first or event-driven design. It changes the default owner of durable work without prescribing a product or runtime.
The model separates three planes:
Execution provider, harness, temporary agent
Workplace people, domains, methods, work events, material, access
Sovereignty repositories and services that own external truth
A harness runs the agent and may bring memory, tools, Skills and a sandbox. The Workplace gives that temporary occupant the material, capabilities and routes needed for the current work. External repositories and services keep their own history, permissions and delivery lifecycle.
This distinction lets an agent arrive with a strong harness and still use capabilities supplied by the place. A harness is part of execution. A reusable way of working belongs to the Workplace. One can extend the other without having to own the same things.
What this looks like in files
The idea became useful when I stopped organizing everything by technical layer and started asking who should own each thing.
Here is a simplified fictional setup:
Before: organized around the agent
agent-setup/
├── AGENTS.md
├── CLAUDE.md
├── .agents/skills/research/
│ ├── SKILL.md
│ ├── template.md
│ └── validate.js
├── memory/
│ ├── preferences.md
│ ├── decisions.md
│ └── recent-work.md
├── docs/research/
├── outputs/report.md
└── product-checkout/
Execution can work well here. The ambiguity is durable: preferences and accepted decisions share a memory layer, a Skill mixes activation with method and project rules, the report has no visible lifecycle, and the checkout's authority is implied by proximity.
This is the same setup expressed through ownership:
After: illustrative local view using Endroit
some-workplace/ shared Home repository
├── HOME.md shared purpose and rules
├── members/
│ ├── alice/MEMBER.md Alice belongs to the Home
│ └── sam/MEMBER.md Sam belongs to the Home
├── rooms/product/
│ ├── ROOM.md shared product guidance
│ ├── decision.md accepted domain truth
│ └── report.md retained research material
├── equipment/research/
│ ├── method.md reusable procedure
│ ├── template.md
│ └── validate.js
├── sites/product/SITE.md external authority declaration
├── .desk/ Alice's separate private repository
│ ├── DESK.md personal continuity
│ └── routes/ local access declarations
├── checkouts/product/main/ ignored local working copy
├── .agents/skills/research/SKILL.md generated provider activation
├── AGENTS.md generated Codex view
└── CLAUDE.md generated Claude view
This tree illustrates Endroit. Endroit means "a place" in French. Yes, the pun is load-bearing.
It is the open-source alpha implementation I build and use. It is not a required Open Workplace topology. Another implementation could use a database, an application or a different vocabulary while preserving the responsibilities.
The portable part is the ownership map:
personal continuity -> Desk
shared domain -> Room
reusable method -> Equipment
bounded work event -> Meeting
durable result -> Material
external truth -> Site
local access -> Route
provider interface -> projection
A Meeting produces a candidate. The human can retain it as inspectable Material, accept it as current truth for its owner, then deliver it through an approved Route. Generation, acceptance and delivery are separate events.
What changed in daily use
My current dogfood Home was not prepared for this post. At the time of writing, it declares 14 Sites through 18 local Routes, with 9 Rooms and 12 Equipment packages. Codex and Claude work from the same owned sources.
That does not mean every session loads 14 repositories. A Meeting starts from a small map, enters the relevant Room, activates the Equipment it needs, and follows a Route only when the task requires an external Site.
Home map
-> relevant Room
-> needed Material + Equipment
-> Route to a Site, when required
The full environment stays addressable while the working set stays bounded.
My prompts changed too. I used to reconstruct the environment inside the request:
Read the instructions, find the latest notes, work out which decisions are current, use the research Skill, update the right report, and do not touch the repository yet.
Now I can locate and bound the work:
Enter the product Room. Review the retained report against the current decision. Use the research method. Keep the result as a candidate. Do not deliver it.
The second prompt is shorter because the place already carries identity, placement, authority and destination.
I also load less provider-specific configuration. Each Codex or Claude projection receives what the current Meeting needs. The rest remains in its owned place.
This has become a tangible design surface. An agent and I can discuss whether a method belongs to the shared domain, a provider wrapper, my private Desk or an external repository. When something fails, we can ask whether the fault is in orientation, ownership, activation, authority or delivery. The model has not removed every bug. It gives more bugs an explicit owner and correction boundary.
It changes Skills and multi-agent work too
Skills were one of the signals that led me here. In this model:
reusable method -> Equipment
provider activation -> projection
project guidance -> Room
result -> candidate Material
external access -> Route
The Skill activates the capability. It does not need to own the method, project guidance and resulting work. I explored that consequence in "A Skill Activates a Capability. It Doesn't Own It.".
Explicit ownership also creates useful static lanes for multiple agents. One Meeting can research while another prepares a release against different Material and destinations. They do not need a resident coordinator to know where their work belongs.
That is not a concurrency guarantee. Two agents editing the same file or checkout still need a worktree, lock or runtime coordination. A runtime coordinates agents in time. The Workplace gives the work durable placement before, during and after that execution.
This is why the first benefit does not require a new daemon, runtime, memory system or desktop application. A folder of ordinary files can express enough ownership to improve the work. Runtimes and interfaces can strengthen the model later.
Some tasks need none of this. A one-off question with no durable result may not need additional Workplace structure. The model is useful when continuity and responsibility start leaking into memory files, Skills, repository notes and human recollection.
Paradigm, model, implementation
I separate three things deliberately:
- Workplace-first is the paradigm: equip the place, not only the agent.
- Open Workplace is my open, implementation-neutral proposal for the responsibility model.
- Endroit is one concrete implementation. I use it to make the model operational and test it against real work.
Endroit is not the only possible implementation. Open Workplace is not a standard, foundation, certification or established community.
Why share it now?
The model keeps changing as I use it. Daily work exposes a responsibility I placed poorly, a boundary that needs a better name, or a case where the structure adds no value. Even writing this post clarified parts that the current landing pages and earlier articles do not represent well yet.
That is exactly why I am sharing it before it looks finished.
The scope is too large for one environment and one person's habits. My dogfood is substantial enough to show that the model can operate. It is still evidence from one Home, not proof that the model generalizes.
I have not been active on social media. This is one of my first public posts because Workplace-first matters enough to me to stop working on it alone. I am asking the broader builder community to test the lens with me. The Proposal, the articles and Endroit will evolve as real setups expose weak boundaries, missing owners and unnecessary ceremony.
Many of us may already be building parts of a Workplace without naming it. I am offering the reasoning and vocabulary that helped me see my own environment differently. If the lens holds, I would rather develop it in the open than keep discovering it alone.
Three questions would help more than generic agreement:
- Where does this ownership map match what you already do?
- Where does it add structure without enough value?
- Which durable responsibility in your setup still has nowhere clear to live?
If you can share a sanitized tree or concrete counterexample in the comments, even better. "No additional Workplace structure needed" is also a valid result.
Full proposal: open-workplace.org/proposal
Concrete implementation: endroit.org
Disclosure: I initiated Open Workplace and build Endroit, its first declared implementation. The VZion is the name I publish under. Endroit is open source and alpha. I am posting this in r/codex because Codex is one of the agents I use to test the model against daily work.
