An agent that works every day has to live somewhere: on a server, in a cloud service, or on a laptop. Where it lives decides what it can use, and who keeps what when its person leaves. This note proposes a framework from building management. Entities (an organization and its programs, as a parent company has its companies) and buildings (the places agents run) are two separate maps, joined by leases. Inside a building are suites for organizations, coworking space, and apartments; each person's agent, their Chief of Staff, has an office. The rule is that the building provides, the suite entitles, and the office holds. When a person moves, they take what they brought or made for themselves; what an organization gave or confided stays; the fittings stay. The framework builds on the working paper "The Agent as an Individual" 2 and is Early: it is being applied to the author's own organization's agents, with a first standard list of amenities.
Where should an organization's agents live, what should each place provide, and what should move with a person, or stay, when they leave?
The Knowledge Core and "The Agent as an Individual" argue that an agent is bound to one principal, a person or an organization, and that a person's agent and what it has learned are theirs to keep 12. That raises a practical question the books leave open: where does the agent physically run, and what does it lose when it moves?
Software engineering already has part of the answer. The Twelve-Factor App keeps an application's configuration out of its code and treats databases and other services as "attached resources," so the same code runs anywhere the resources are provided 3. The Model Context Protocol gives agents one standard way to plug into tools that others provide 4. In the European Union, the GDPR gives people a right, with limits, to receive the personal data they provided and take it elsewhere 5. What is missing is a frame that people who are not engineers can reason with, about agents rather than applications.
The framework. A building is where agents run, and it has its own staff: someone who keeps it running, secures its doors and lobby, and makes backups. An entity leases space in one or more buildings: a suite for the organization, offices for its people. Each person's agent has an office; the model behind it is the mind at the desk, and it can change. The organization's knowledge is a research service delivered to the desk, at the clearance of that office, rather than a place the agent walks to. The organization's own staff agents live in its management office, not in any person's office.
Building provides, suite entitles, office holds. Take a web browser: the building provides the browser and a private way to view it; the suite decides who gets one and on what rules; the office holds the person's own profile and bookmarks.
Moving. A principal, a person or an entity, takes what they brought or made for themselves; what an entity gave or confided stays; fittings stay. An agent's work moves with its person through declared needs, standard plugs, and keys referred to by name rather than copied, and on each move every need is checked against the new building as provided, substituted, or missing.
The standard amenities, version 1. Building amenities: a desk, a mind, sessions, a terminal, a browser, an address, a scheduler, a database, keys, and backup. Suite amenities: research, a front desk, a concierge, a mailroom, scheduling, publishing, human resources, and connectors to the organization's other systems.
How evidence is judged. By moves: when an agent moves between buildings, or a person leaves an organization, whether the check finds every need, how much has to be rebuilt by hand, and whether the outcome is one the person and the organization both accept. Because the author designed the framework and runs the organization applying it, findings are reported as a case.
The framework is new. The author has proposed a first standard list of amenities and is applying it to his own organization's agents. No move has yet been made under it, so there are no findings to report.
What is not yet known: whether the list is complete, whether people find the building vocabulary helpful or merely decorative, and how the rule for moving holds when what a person made and what the organization confided are mixed together in one piece of work.
What would count against the framework. If moves still need most of an agent's work rebuilt by hand; if the amenities list keeps growing with one-off items; or if people and organizations dispute who keeps what after the rule is applied, the framework is not doing what it claims.
The strongest objection. A metaphor can hide as much as it shows: a server is not a building, and an agent's memory does not sit neatly in one office. The framework is meant as a checklist people can reason with, not a claim that agents are tenants; it is judged by whether moves go better.
Open questions. Who should be the landlord when an organization runs its own building? How should the rule for moving treat an agent's learned habits, as opposed to its files? Should the standard amenities list be shared between organizations, so that agents can move between them?
What a person's agent holds in its office is private to that person 6; under this framework, what they brought or made goes with them 2. What an organization confided stays with the organization. The rule for moving is a proposal for discussion, not a statement of law: who owns work and data when someone leaves is decided by agreements and the law, and a lawyer should advise. This note names no one but the author, and describes no organization's keys, accounts, or systems.
Students who build agents in Building AI Agents learn to connect them to tools through one standard protocol 7; this framework is the next question for them: where their agent lives, and what it takes with it when they graduate.
List what your agents need by name, not by copy: their tools, their data, their keys. When a person leaves, could you say, for each item, whether it goes with them or stays?