That environment is not absent. It forms accidentally from repository instructions, provider settings, chat memory, copied methods, plans, and notes. Each piece may be useful, but no system necessarily owns the whole.
I use the unowned agent environment problem as a name for this ownership gap, not as a claim that nobody else has identified its parts. We can equip an agent with a better model, more tools, and more capabilities while leaving it to work in a storage closet: everything is reachable, but the room was never designed or maintained as one workplace.
I call that inherited model Target-first. I propose Home-first as an architectural paradigm for agent environments and, more specifically, as an ownership model for the durable workplace shared by humans and agents.
The accidental environment
Open an Agent Runtime inside a product repository. The runtime gets a working directory and the product gives it local context.
Then the setup grows:
product-repository/
├── .agents/skills/
├── .claude/commands/
├── .planning/
├── research/
├── AGENTS.md
└── src/
Each addition solves a real need. A methodology adds instructions. A runtime adds its native files. Research and plans need somewhere to land. A later session needs memory.
AGENTS.md and CLAUDE.md are useful front doors. The storage closet is not
necessarily messy: it can contain excellent, well-organized material. The
problem is that a product repository inherited responsibility for a transverse
workplace that was never designed or governed as one system.
The repository now owns two systems: the product it delivers and the environment through which humans and agents work. Product ownership was a choice. Environment ownership followed the working directory.
Name the current default: Target-first
A Target is a product destination: an application, API, library, documentation repository, or another independent body of work.
Target-first makes that destination the center of the agent environment:
Agent Runtime → agent inside Target → local setup → work
This topology remains useful for a short task inside one product. It served project-bound developer tools well. The ownership gap appears when agentic work needs to survive or cross the Target boundary.
The same collaborator may use one research method across several products. One decision can affect an application and its API. A team may use Codex for one task and Claude Code for another. A durable method should keep its identity when a runtime projects it into a Skill or Command.
Target-first duplicates the shared environment across Targets. Product repositories collect copied methods, provider files, and collaboration history that they cannot govern as one system.
Interactive model
Same tools. Different ownership.
Target-firstEach product becomes an accidental environment.
Copied methods, runtime files, and work history follow whichever repository happens to be open.
A Binding connects the owned environment to each independent Target.
The ownership rule
Home-first begins with one rule:
The human-agent work environment needs an owner independent of the Agent Runtimes that execute it and the Targets it acts on.
The Target owns product truth, product constraints, and delivery.
The layers solve different problems:
- the model supplies learned reasoning capability;
- the Agent Runtime wakes or hosts the agent and executes the session;
- data and context layers, including MCP, provide access to systems;
- the interface carries the interaction;
- the Home owns orientation, continuity, and shared working material.
Capabilities equip work with repeatable methods, knowledge, or actions. None of those layers alone necessarily owns the durable environment in which the work is oriented and retained.
Memory can help an agent remember information. Plugins, MCP servers, and other integrations can give it access to systems. Neither necessarily tells the agent where it is, what matters now, which source has authority, or where a durable result belongs.
External systems own their data and authorization.
The collaborator or organization owns the durable human-agent workplace that orients those layers.
Give the environment a Home
A Home is the canonical, owned, and portable environment where humans and agents work from shared sources, orientation, and retained material.
Human
├── editor · terminal · review
└── Desk and curation
│
Agent Runtime → Home → Binding → Target
└── Access → External system
The editor, runtime, methodology, and repository can remain in place. Home-first changes which system owns each part.
A runtime gives the agent a working directory. A Home gives the work an owned environment.
A Home does not merely equip an agent and drop it into another folder. It invites the agent into a workplace whose sources, boundaries, and destinations the human can inspect and govern.
The shared material is concrete: system Maps, retained decisions, methods, Documents, Artifacts, and explicit relationships to Targets. A Map can orient a conversation or narrow the next inspection. It never replaces the Target or the live system before a mutation.
A Desk holds one collaborator's continuity inside the Home. A Binding connects that Desk to a local checkout of a declared Target. The Target stays independent and keeps its product-specific instructions.
A concrete before and after
Target-first
project-a/.claude/
project-a/AGENTS.md
project-a/research/
project-b/.codex/
project-b/copied-methodology/
Home-first
owned-home/
├── shared orientation
├── durable subjects
├── reusable capabilities
├── retained decisions and results
└── routes to independent Targets and external systems
project-a/ product source + product-specific instructions
project-b/ product source + product-specific instructions
The example illustrates ownership. Home-first does not require these roles, folder names, or a filesystem implementation.
The placement test
The model earns its vocabulary when it helps place real material:
Does it define this product?
→ Target
Should it survive a change of Target or Agent Runtime?
→ Home
Does it equip future work?
→ Asset
Did the work produce it?
→ Artifact
Is it a runtime-specific derived form?
→ Projection
An Asset is a source-owned product for work: a method, tool, knowledge package, runtime, or another reusable capability behind a stable contract.
An Artifact is a chosen, inspectable product of work with an owner, state, and lineage.
A Projection adapts canonical source into a form expected by a runtime. A Skill can expose a capability to a model. A Command can expose the same capability to a person. Neither form has to become the identity or source of the Asset.
Home ≠ Target
Asset ≠ Artifact
Source ≠ Projection
Runtime ≠ Owner
Interface ≠ Environment
MCP access ≠ Environment
Skill form ≠ Asset identity
A shared system of work
Humans and agents need common conventions when they collaborate. Collaborators need those conventions when they hand work to one another.
A Home makes that system inspectable. Humans can read its sources, review its changes, and decide which results deserve promotion. Agents can enter through runtime-native forms and recover the same owned structure.
The human keeps direction and judgment while the environment keeps ownership, scope, and destinations visible.
Don't trust your agent blindly. Give the collaboration shared material you can inspect, correct, and trust.
Different interfaces. Different runtimes. Same place. Same material.
Stable semantic roles can help a new session recover after context compaction. The session can reconstruct its environment from owned sources instead of treating a compressed conversation as its only memory.
Adjacent work, a different ownership question
Home-first does not claim that environment design, progressive disclosure, or session artifacts are new.
OpenAI’s Harness Engineering describes repository knowledge, maps, and plans that make an agent’s working environment legible. Anthropic’s long-running agent harnesses use an initializer and structured artifacts to preserve continuity across sessions. Agent Skills defines a portable format for packaging capabilities with progressively disclosed instructions and resources. MCP standardizes how applications expose and discover tools, resources, and prompts.
Those efforts solve important parts of agentic work. Home-first asks a different question: who owns the durable environment that connects those parts when work crosses runtimes, repositories, and external systems?
Home-first does not prescribe a platform
Home-first proposes ownership distinctions, not a universal folder convention. Implementations may choose different names, stores, and interfaces. The proposal asks whether they preserve the boundaries.
It leaves room for:
- different Agent Runtimes and model providers;
- different interfaces for collaborators;
- professional or personal Homes with their own methods;
- external systems that retain their data and authorization.
MCP, APIs, and sync still serve live data, authorization, and remote actions. Access to another system does not establish ownership of the work environment.
A future Notion, Slack, or other interface could present a reconstructible view of Home material. That view would not become the canonical environment, and Home-first does not imply a new connector platform.
One implementation: Endroit
Endroit is the open-source framework and CLI I use to materialize one Home-first implementation with ordinary files and Git. Its current capabilities and limits belong to the product README, not to this proposal.
Another framework could implement Home-first with different contracts, stores, and interfaces.
An open proposal
I built Endroit because I wanted this environment for my work. I publish Home-first separately because one implementation should not define the model.
Engineers are natural early adopters because they can materialize this environment with files, Git, and existing developer tools. The paradigm is engineer-first, not engineering-only: domain experts should still own the rules, decisions, and retained work of their domain.
The vocabulary can change. The boundaries can fail under workflows I have not tested. Another implementation may express the ownership model better. Home-first is an open proposal, not an established industry convention.
Three questions can test the proposal:
- Does Target-first describe how your agent setup grew?
- Which material belongs to your agent environment but not to a product repository?
- Which Home-first distinction breaks under your workflow?
Read why a Skill should not become the identity of every agentic object.