Write it once. Your AI and your team share it.

A shared second brain for any AI, with agent permissions. Permissions attach to folders and inherit down the tree. Agents reach it over MCP and see only what the principal behind them may see.

No. Signing in creates a personal workspace. Creating an organization is optional.

Name it and add files in one flow. A folder comes into existence with its first content. Permissions, history and audit all scope to the folder you are standing in.

Folders and files, nesting like a filesystem. Underneath is a content-addressed git object model in Postgres. Every document carries its own line of versions, and every past permission state is queryable.

Anything that speaks MCP. The console has ready-made steps for nine clients: Claude Code, Claude Desktop, Cursor, the two Codex surfaces, ChatGPT, Gemini CLI, VS Code and Cline. Every other client takes the same endpoint.

The plugin, where there is one. It registers the same server and brings the skills that explain what you can reach, plus the slash commands on Claude Code, so it is one step instead of two. Claude Code, Claude Desktop, the Codex CLI and the Codex app can install it. Every other client adds the server directly, and connects exactly the same way.

Not for yourself. A person signs in through the browser over OAuth. Tokens are for agents your application runs, which have no browser to redirect.

List folders, list and read documents, and search everything it can reach. It writes and edits where it holds an editor grant.

browse · read · search · brief_me · doc_create · doc_update · doc_delete

By meaning where a vector index exists, and by text where it does not. The authorization filter runs in the SQL WHERE clause before ranking. Content you cannot reach never enters the candidate pool.

Write to contact@agentlefs.com with your client, what you ran and what came back. A person reads every message.

Yes. An agent claims a document or one of its sections before it edits, and another agent's write into that claim is refused until the claim is released or expires. Agents ask each other things with typed messages, addressed by name or by what an agent is responsible for. When two agents edit the same document at once, one edit lands and the other is refused and told to re-read.

coordination_write claim · message_write send · doc_update expected_commit

Both, over the same authorization. It covers documents, folders, renames, moves, search and grants. The OpenAPI spec is served from the API itself.

GET /v1/documents · POST /v1/grants · GET /v1/openapi.yaml

Yes, and that is what the REST API is for. Give each of your users a principal, and every read you make for them returns only what they may see. Your own code manages access with POST and DELETE on /v1/grants.

No. A path they cannot reach returns 404, and so does a path that does not exist. The two are deliberately the same status and the same body.

NOT_FOUND · 404 · absent, OR present and not yours

No, /v1 refuses a token minted for MCP. Mint a separate key for your application code.

A create carries an Idempotency-Key, so a retried request is the same request. An update carries If-Match, so a stale write returns 409 instead of overwriting a concurrent edit.

Idempotency-Key · If-Match

Three roles, named as in Google Drive, each containing the one below: Viewer, Editor, Manager; there is no fourth. A Manager can share and manage access, and edit, at or below where it holds the grant. An Editor edits and, as in Drive, can share as Viewer or Editor unless the owner or a Manager turns off “Editors can change permissions and share” (on a folder it covers everything inside); only a Manager makes a Manager. Ownership is separate: every file and folder has exactly one Owner, whoever made it or was handed it, shown first on its access screen.

No. A credential authenticates a principal. What that principal can do in a folder is derived at request time from its live grants.

credential → principal → groups → grants → files

Nothing that reveals the document exists. Denied content is never returned, listed, matched or counted. From outside, refused and absent look identical.

Yes. A folder grant reaches content added after it. A grant on a single file reaches only that file.

Yes, and that is the normal case. Each grant is independent, so one folder serves a manager, an editor, a viewer and an agent at once. A grant on a path inside the folder can only widen what the folder already gives.

No. Access only ever adds, so there is no deny rule and no exception list. Keep the sensitive path outside every broad grant instead, which is why a grant's scope is a path rather than a folder. A subtractive rule was removed on purpose: it broke the monotonicity the read filter depends on.

Yes, and a group nests at any depth. A grant to a group reaches every current member, so adding someone to the group is how you grant them. Removing them from the group is how you revoke.

Yes, both are principals and take the same grants. The only difference is how they authenticate: a person signs in through the browser, and an agent carries a minted token. Nothing in the authorization model knows which is which.

No. Labels drive search and filtering only. Access comes from grants on the file and the folders above it.

Yes. Ask it, and it calls access_read with who_can_read, which lists the people and groups that reach a folder or document, directly or by inheritance. It names people and never shows their content. It only answers for something the asker can already reach.

access_read action=who_can_read

Yes. On the folder's Access page, under “Someone in another organization”, enter their email and Viewer or Editor. They accept it into their own organization, at the top level or in a folder they choose. Nothing is copied, and when you withdraw it, it leaves their side too.

Only the person you shared it with, and the AIs that act for them. Their colleagues and admins never read it, whatever they are granted there. They can only put it where nobody else sees it, and it is listed under Shared with me.

They're invited. They get an email naming you, your organization, the folder and their access, and nothing of its content. When they sign up with that address the folder is theirs to open. You also get a link you can send them yourself.

Yes, if the address is the one they sign in with and they are a member here. It becomes the same grant as picking them from the list.

Yes. The share form shows what is in it as you can see it. It also says how many files are withheld from you.

Yes. On its Access page, Anyone (public) shows every file before you approve it, and a folder holding SKILL.md is published as a skill. Each new version is shown and approved again. Whoever approved a version can unpublish it.

Yes, unless you pin it. Add it to a folder of yours and each new version is applied, its row saying latest. Pin it when you add it, or later from its right-click, to keep one version. Editing your copy stops the updates.

No. An agent proposes and its person approves, in Approvals for a share and on an approval page for a publication. An AI you connect as yourself shares as you.

Yes. The editor is live, and an agent's write arrives in the page you are reading without a reload. Every write is still its own version, so you can see exactly what the agent changed and restore an earlier one.

Text and markdown documents, and binary files. Documents get a collaborative editor and their own version history. A dragged-in directory lands as one commit.

Every document keeps its own line of versions, and editing one never rewrites another. History opens from the editor and diffs a version against the one before it. Restore this version puts that text back as the newest version.

The agent's write becomes a version of its own, and the version before it is still there. Open the document's history and restore the older one, or ask your AI to: it can list a document's versions and restore one too, with the same Editor access. A restore is a new version on top, so nothing is lost. The audit trail names which principal made each write.

A connector mirrors a repository or a Drive folder into a folder of its own, created where you add it, and keeps it current. That folder is read-only here because upstream owns it. Stored credentials are encrypted and never returned to the console.

No, content is live the moment it lands. Uploading grants you the file, and a connector grants the readers you chose at install. Nobody else reaches it until you widen that.

Yes. The REST API reads any document you can reach.

Two independent walls. Postgres row-level security separates organizations. A relationship-based authorization graph decides who reaches what inside one.

Every retrieval, navigation, write, grant, token mint and policy change, including the ones that were refused. Each record carries a hash of the one before it. A removed entry breaks the chain.

record_hash = sha256(payload + prev)

Immediately. Revoking a token or a grant is a database change, and the next request sees it. There is no cache to wait out and nothing to re-mint. Someone with the document already open in the editor loses it too.

Revoke their grants and their tokens, and the next request sees it. Their principal stays, because the audit trail refers to it and a deleted principal would leave unattributable records. Content they wrote stays where it is, under its own history.

No. Not our models and not anyone else's, and your content is never included in a training set. agentleFS calls no model to answer your questions. To search by meaning, it sends document text and your searches to Voyage AI, which keeps none of it after processing and never trains on it.

The answering happens in the client you connect rather than here. We serve that client the documents you have given it access to, and it decides which model reads them. Point it at a model running on your own machine and no model provider is in the path.

Yes. Delete hides a document or folder everywhere and keeps it recoverable by you. Delete forever destroys its content, every version, its comments, its name and what agents attached to it, and nothing brings it back. A manager of it does both from the console, and you can delete your whole account forever from the menu.

A folder or a document, a manager of it removes from its menu in the sidebar tree or on the folder page: Delete forever shows what would go and asks for its name. Your whole account, with your personal organization and everything in it, you remove from Account in the menu: Delete account forever, which signs you out at once and becomes final after seven days unless you sign back in and cancel. What you own in an organization you share with others stays with that organization. Deleting a shared organization itself is on request: write to the address on the privacy page.

At /privacy, linked from the footer of every public page. It carries the long version of the model-use answer above, what we store, and how to get it deleted.

/privacy

Yes, and that is the intended shape for anything unattended. Give it its own principal and grant it only the folders it needs. Mint its token with an expiry.

admin mint-token --principal=<id> --roles=<subset> --ttl=<secs>