Those objects do different jobs. The runtime exposes them through one familiar mechanism, so we give them one name.
The name changes how we organize agentic work. Once a method, instruction set, or knowledge package becomes a Skill, we install it where the runtime can find it: the current product repository.
The repository then collects the rest of the environment.
One reasonable addition at a time
A new project starts with product source:
product-repository/
└── src/
You add an agent:
product-repository/
├── AGENTS.md
└── src/
You install a methodology, preserve research, and try another Agent Runtime:
product-repository/
├── .agents/skills/
├── .claude/commands/
├── .planning/
├── research/
├── AGENTS.md
└── src/
Each file may belong there. Product-specific coding rules should stay with the product. A methodology may require native paths. A generated plan may be a product deliverable.
The collection raises a question: does this repository own the product and the whole way humans and agents work together?
Most setups answer through accumulation. The current working directory becomes the source of orientation, reusable methods, continuity, and generated work. Trying a tool leaves its conventions behind. Switching runtimes duplicates them.
I call this inherited model Target-first.
Target-first
A Target is a product destination: an application, API, documentation repository, or another independent body of work.
Target-first starts the agent inside that destination and lets the destination become its environment:
Agent Runtime → agent inside Target → local setup → work
Project-bound developer tools fit that topology. The repository already held code, tests, and automation. Keeping local instructions near the code made sense.
Agents changed the working unit. The same collaboration can involve an application, its API, research material, and a second prototype. The same method can serve several products. A person may use Codex for one task and Claude Code for another.
The collaboration spans those tools, yet its durable environment remains split between them.
You copy methods between repositories. Runtime-native files become canonical because no independent source exists. Research disappears into chat history or lands beside code without a declared owner. Another collaborator receives a folder and a setup guide instead of a coherent system of work.
Our language cannot carry the design discussion
I hit this problem when I discuss agentic systems with my CTPO and colleagues. We can name Skills, agents, MCP servers, prompts, and memory. Those terms describe mechanisms exposed by current runtimes.
They do not tell us whether a method and its model-facing Skill are the same object. They do not tell us who owns cross-project continuity, where reviewed research belongs, or which runtime files we can rebuild from an independent source.
Each person builds a private taxonomy around the tools they know. A discussion about system design drops into package formats and provider paths before the team has named ownership, lifecycle, or placement.
A shared grammar should let a product leader, domain expert, and agentic developer discuss the same environment without teaching everyone one runtime's file tree.
A hundred tips for rebuilding an environment
u/palo888 documented this work in “100 Tips & Tricks for Building Your Own Personal AI Agent.”. The post covers a constitution, memory structure, capability maps, Skills, agents, session protocols, authority, file routing, hooks, and automation. Together, those practices describe an agent work environment.
The author had to discover its parts and place each one because the ecosystem offers no shared ownership model for the whole. The post gives useful evidence. Agent power users keep reconstructing the same missing layer through experience.
Skill describes an invocation form
The open Agent Skills specification defines a useful package that can bundle instructions, scripts, references, and resources behind progressive disclosure. Runtimes can discover and invoke that package.
The problem begins when the Skill form becomes the identity of any method, role, knowledge product, or workflow behind it.
A research method may contain:
- instructions for the agent;
- a Command for a human;
- a validation script;
- domain knowledge and output templates.
Calling the whole method a Skill makes the model-facing entry point stand for the product. Another runtime may express the same method as a Command, Rule, Agent, or Workflow. If each expression becomes the source, the method fragments across providers.
I use Asset for the durable product behind those forms.
An Asset can own its source, purpose, lifecycle, and quality bar. It may project one Capability as a Skill for a model and a Command for a person. The runtime form can change while the Asset keeps its identity.
┌── Skill
├── Command
Agentic Asset ──────├── Agent
├── Rule
├── Hook
└── Workflow
This distinction still needs a place where the Asset can live without becoming part of one product repository.
Home-first
I propose Home-first as an ownership model for that place.
A Home is a canonical, owned, and portable environment where humans and agents share sources, conventions, and orientation.
Human
├── editor · terminal · review
└── Desk and curation
│
Agent Runtime → Home → Binding → Target
└── Access → External system
The Agent Runtime keeps running the session. The Target keeps owning the product. GitHub, Slack, and other external systems keep owning their data and authorization.
The Home owns the durable collaboration environment.
A Desk holds one collaborator's continuity. A Binding connects that Desk to a checkout of a declared Target. Product-specific instructions remain with the Target. Reusable methods, cross-project continuity, and runtime-neutral sources can remain in the Home.
The same pieces now have explicit relationships:
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
Home-first proposes ownership distinctions. It does not require this folder layout or these exact roles or terms.
A placement test
The model should help with a real file before it asks anyone to accept new vocabulary:
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 Artifact is a chosen result of work with an owner, state, and lineage. Research can remain a private Desk Artifact, become shared Home material, or move into a Target when it becomes product truth.
A Projection is a rebuildable runtime-native form. The Home owns the source; the runtime receives the shape it expects.
Home ≠ Target
Asset ≠ Artifact
Source ≠ Projection
Runtime ≠ Owner
MCP access ≠ Environment
Skill form ≠ Asset identity
MCP gives an agent access to another system. It does not give the whole work environment an owner. A runtime wakes and executes the agent. It does not need to own the methods and continuity the agent uses.
Shared conventions for humans and agents
I explained Endroit to a friend and asked him to repeat the simple idea back. He described a tool that unifies the way humans and agents work through shared concepts and methods, both between humans and agents and between humans.
That description captured the benefit before the architecture.
Ownership makes the shared convention durable. Humans can inspect the same sources the agent receives through runtime projections. Collaborators can review changes and hand work to one another without reconstructing the setup.
The Home can help a session recover after context compaction. Stable roles identify methods, decisions, temporary notes, and product facts. A later session can re-enter the owned environment instead of treating a compressed conversation as its only memory.
One implementation
I am building Endroit, an open-source framework and CLI that implements part of Home-first.
Its current capabilities, installation, and alpha limitations live in the product README, rather than in this article.
Endroit does not add intelligence to a model. It makes the conditions around the work inspectable and portable.
A proposal before a standard
The Home-first Proposal separates the model from the Endroit implementation.
I publish it so other people can challenge the ownership boundaries, rename the concepts, or implement the same model another way. A framework should not become the only authority on the paradigm it proposes.
The next time a tool calls a method, agent definition, or knowledge package a Skill, ask two questions:
- Which durable object sits behind this runtime form?
- Who should own it when the runtime or repository changes?
Those questions move the discussion from Skill taxonomy to environment design.