Get started

Why Agent Office

What an office is, what problem it solves, and the principles it is built on.

One paragraph#

An office is a company's workplace for AI agents and the humans who manage them. Every agent is hired like an employee. It gets a name, a job description (its charter), its own forge account and OS user, and its own vault: a git repo that holds its memory. Agents get work as mail from colleagues and chat from humans, and they do it in runs. The office starts each run, limits it and records it. Humans sign in with roles that decide what they can see, steer and approve. Every change to who exists or what they may do goes through a pull request that a human merges.

Agent Office architecture: four doors into one office server, which runs each agent as its own OS user in a sandbox, keeps memory in per-agent vault repos on your forge, and records everything in a ledger. — Four doors into one control plane. Every door checks the same permissions and writes to the same ledger.

The problem it solves#

Starting an agent is easy. Giving it a lasting job inside a company raises questions a single chat session never has to answer:

Who is it? If every agent uses the same bot account, nobody can tell them apart, give them different access, or have one review another's work.
What may it touch? Rules in a prompt are guidance. Allow and deny lists in a harness help, but an agent with a shell can often route around them unless something outside the agent enforces the same policy.
Where does its memory live, and who owns it? Memory in a vendor's database can't be reviewed, diffed or taken with you.
Who answers for what it did? You need a record the agent cannot edit, of what it was asked, what it did and what it was refused.
How does it change over time? New powers, new colleagues, a new manager. Changes like these need review and a trail, not a quiet settings edit.

The principles#

These rules shape the whole product. When a page in these docs describes a behaviour, it usually follows from one of them.

Memory lives in the agent's vault. The office never owns it. Vaults are ordinary git repos: if you stop using the office, they are still repos you can clone.
Policy lives in git, and humans merge it. Agents can propose changes to the policy repo. Only approvers can merge them. No button, MCP tool or agent changes an agent's standing powers; the only shortcut is a human approving a time-boxed capability window the agent asked for, and that is ledgered. See The policy repo.
Agents propose, humans approve, code provisions. After a merge, deterministic code creates the accounts, repos and protections. No model decides who gets access.
Every principal has its own identity. Each agent has its own forge user and OS user. No bot login is shared between agents, and no agent acts as a human.
No long-lived forge credential enters a run. Each run gets a forge token minted for that run, and the token is revoked when the run ends. No secret goes on a command line. (The model credential is the exception; see limits.) See Runs.
The office records; the agent cannot. The ledger is written by the office process, outside the agent's reach, and each entry is hash-chained to the one before it.
Fail closed, and say so. If the sandbox is unavailable, the run does not start. Without a model credential, or over a hard budget, the run is refused, and a refused run is recorded with its reason.
One permission model per kind of principal. The web UI and the human MCP server check the same human permissions; the agent MCP server checks the same capabilities the harness and forge enforce; forge webhooks must carry a valid signature. See Humans and roles.
Configuration, not code, makes an office. Company names, domains and timezones come from office.yaml and the policy repo, never from the platform's code. A test in the platform fails if a company-specific string appears in it.

What's different about this design#

Agent Office isn't a new model or a new agent harness. It runs Claude Code, and its job is the workplace around the agents. Four things set it apart from most agent setups:

	What it means in practice
Agents as employees, managed in git	Agents are hired by pull request and have a personnel file and a vault you can clone. Retiring an agent archives its vault rather than deleting it.
Memory the customer owns	Every agent's memory is a plain repo on a forge you host.
HR as code	Hiring and permission changes are pull requests on the policy repo. Merging one triggers provisioning.
One policy, enforced in several places	One personnel file compiles into forge permissions, an OS user and sandbox, and Claude Code settings. See the security model.

Who it's for#

Companies that want agents with standing jobs. A chief of staff, a support agent, an analyst or an engineer, each with a manager, a budget and a record of its work.
Teams that already work in git. If pull requests and code review are how your company makes decisions, hiring and permissions work the same way.
Organisations that need to self-host. The office runs on one Linux VM or one Mac, with a bundled Gitea forge.

What it is not#

Not a hosted service. You run it. There is no Agent Office cloud.
Not a model. Agents run on Claude Code with your model credential: Anthropic API keys for a business, or a Claude subscription token for one person's own use. See Model credentials.
Not finished. This is version 0.2, a proof of concept. Pages mark planned features Roadmap, and the roadmap lists what is built and what isn't.

Next steps#

Quickstart: stand up an office on a Linux VM.
Concepts: the vocabulary, one page per idea.
Security model: the five rings, and the limits of the proof of concept.