How AGI For Us works

AGI For Us is designed to turn one always-on Mac or Linux machine into a multi-user Claude Code host for a household. In the design, each adult gets their own OS account, their own Claude Code and their own Claude subscription, and a memory service decides what each person's assistant may know about the others. You'll install it with your own Claude Code and run it on your own hardware; we operate no servers. Our own code will be released under BSD or a similar permissive license, and components keep their own licenses.

Nothing here is released yet. This page describes the design and what we've built and tested so far, and marks which is which:

• Tested: a proof of concept was built and run.
• Decided: in the design, not built.
• Open: not decided.

Phones

• AGI For Us app (not built)
• Telegram bot

Household machine (Mac or Linux)

Member A

OS user, 0700 home, own Claude Code, own Claude login

Member B

OS user, 0700 home, own Claude Code, own Claude login

Assistant-to-assistant messages

Memory service (MCP) Tested as a prototype

Every read checked per fact and per recipient

Administrator

Their own Claude Code on the host, narrow privileged helpers, a request queue

Optional components

Voice, local models (GPU, native)

Anthropic, under each member's own account

The architecture

One Claude Code per person, one OS user per person Status: Decided; isolation Tested in an Ubuntu 24.04 container

In the design, every adult member is a separate OS user with a 0700 home and a 0700 Claude Code config directory. Plugins and MCP servers a member installs run under that member's own account, as children of their Claude Code. Claude Code itself protects only its credentials file (0600). Settings, MCP configuration (where tokens for things like an email connection live) and session transcripts follow the directory's mode, which is why separate OS users are the default. Giving each member a different CLAUDE_CONFIG_DIR under one shared OS account would isolate nothing.

In our first proof of concept, every attempt by one member to read another member's home, config, token or shell history was refused. A secret passed on a command line turned out to be readable by every local user, so tokens live only in files. An idle Claude Code instance at its first screen, before signing in, used 152.9 MB.

Whether each conversation gets a fresh session, with the relevant memory injected, or each member keeps one long-running instance isn't decided. The design leans toward fresh sessions.

Signing in: each person, through Anthropic's own flow Status: Decided; Tested once

AGI For Us never sees how a member signs in to Claude, and Claude Code itself writes the long-lived credential. The unmodified claude binary runs its own login. The member gets a link on their phone, signs in to their own Claude account on Anthropic's page, and Anthropic's page shows them a code to paste back. The binary writes the credential, at mode 600 in that member's config directory. Only the single-use authorization code, which is dead within minutes, passes through AGI For Us.

We ran this end to end with the founder's own account. The phone sign-in worked, a real turn ran on the host, and a containerized Claude Code ran real turns against the same credential. Two things went wrong on the way:

• A sign-in link opened inside Telegram's built-in browser looped back to the start, and the same link worked first time in Safari.
• Our first capture of a long sign-in URL was silently cut off at the terminal's edge. Captured URLs are now checked for every required parameter before anyone sees them.

Not tested yet: two members on two separate paid plans on one machine, which needs a second subscription; and a non-technical person going through the flow without help.

Not decided: whether members use Claude Code's normal sign-in, which has to be renewed from time to time, or its one-year token, which needs renewing once a year but which AGI For Us would then have to store.

Memory is a service, not a folder of files Status: Decided; Tested as a prototype

In the design, the family's shared knowledge lives in a memory service rather than in files every member's assistant can read. A filesystem has no single point where a rule like "use this to help him, but never tell him" can be applied; a service does. Each member's Claude Code reaches it as an ordinary MCP server, with a token issued to that member when the account was created.

Everything the service stores is a belief tied to a source: "A believes B", never a bare fact. A doctor's report is the doctor's belief; a form with a typo is the form's. The service keeps a current view, which is what the assistant treats as true now, on top of an append-only log that keeps everything.

Our prototype sent every read through one policy function, whether automatic injection, search, fetch by id, crawl or history. Guidance meant to steer the assistant's help without being shown ("use, don't disclose") was delivered only by automatic injection, never returned by search, fetch or crawl. Records that were secret, or denied to the person asking, were returned by none of them. A denied record and a nonexistent one returned the same "no such record".

The prototype also checked the kernel's record of which OS user owns the connecting socket, so a stolen token was refused when presented from another member's account. That check works only when the member's session and the service are on the same machine.

Our attack suite later found ways this prototype still gave things away (see What we've built so far).

Who may know what Status: Decided in principle; Tested as a prototype

This is the hard problem a shared family assistant has to solve, and the part we care about most.

In the design, every fact carries a policy for each person: tell them, use it to help them without telling them, or behave as though it isn't known. Members also hold standing rules: what they share by default, what they keep back, and arrangements one member proposes and the other accepts, such as one sibling being kept up to date on another's travel plans. A rule written about "my family" resolves to the named people in it on the day it's set, so a new member is covered by nothing until each person says so. Changing your mind stops future sharing; it can't take back what was already said.

One rule governs everything the assistant says about privacy: it has to be sayable when there's nothing to hide. A refusal that appears only when something exists tells the asker that something exists. So the assistant declines at the level of a category, the same way every time. In our consent prototype, four pairs of responses that should look alike came back identical, byte for byte, apart from a request id in one pair. One pair compared a refusal over an empty category with the same refusal over a full one; another compared a hidden fact with no fact at all.

When it's unclear who a new fact may reach, the assistant is designed to ask the person who told it, at the time.

Assistants talk to assistants Status: Decided; the protocol is Open

In the design, a member's own assistant is the only thing that ever talks to that member. When information should reach someone else, one member's assistant messages the other's, and both apply their person's rules before anything is said. The protocol between them isn't designed.

A proof of concept showed two ways to deliver a message into a running Claude Code session without anyone typing: an MCP channel notification, and a hook that picks up queued messages when a turn ends. It showed one way to interrupt a session, by driving its terminal. It also lost a message when two readers raced for it, and its delivery gives no acknowledgement.

The administrator Status: Decided; one piece Tested

In the design, the person who owns the machine is the one super admin. They install AGI For Us with their own Claude Code, from a plugin that describes the end state (paths, owners, modes, what must be running) and finishes with a check the install has to pass. Privileged work goes through narrow helpers with a fixed set of operations. These are installed 4750 with an admin-only group, so no other family member can run them. Family messages never reach a privileged tool directly. A member's request reaches the administrator's assistant as quoted text, and the administrator approves anything privileged.

Members ask for things, such as connecting an email account or installing a plugin, through a request queue. Anything that could harm someone who didn't choose it starts strict: by default members can't install plugins themselves, and can ask instead. The administrator can loosen that for each member, to approving installs beforehand, reviewing them afterwards, or leaving members free. Admins live under the same privacy rules as everyone else, and the design gives them no tool for reading anyone's data.

Our first proof of concept built the narrowest helper, which creates and removes members at scoped privilege. A non-family account on the same machine was refused when it tried to run it.

Phones Status: Decided; the app's path is Open

In the design, AGI For Us will ship two optional ways to reach the household's assistant, and the administrator picks at least one.

A Telegram bot. The administrator creates the family's bot, and each member presses Start once, because a bot can't open a conversation. Telegram needs no open port anywhere: the machine polls Telegram over an outgoing connection. Bot chats aren't end-to-end encrypted.

The AGI For Us app. It is planned and not built. For households whose home internet can't accept incoming connections, the current plan is a small relay that each household runs for itself on a rented server, at about EUR 4-6 a month, carrying only end-to-end encrypted traffic. That plan isn't final.

We don't use Anthropic's Remote Control.

Components: a short, curated list Status: Decided

In the design, the core is Claude Code and the multi-user layer, the same on every install. Everything else is a component you choose: voice, local models, the app, Telegram. The machine never switches anything on by itself because it happens to have the hardware.

The maintainer chooses the components; there is no community marketplace. We prefer components that already install cleanly upstream, that ship for both NVIDIA (CUDA) and Apple Silicon, and that change least over time. Each one gets a label saying what it needs. We tell you what's missing on your machine. We don't write installers or compatibility patches for other people's software.

Where the administrator allows it, ordinary Claude Code plugins install the usual way. They don't know about the multi-user layout, so they may write where they shouldn't.

Where it runs Status: Decided; Linux placement Open

In the design, AGI For Us runs on macOS and Linux only; there is no Windows support, and we won't test it. GPU components target NVIDIA CUDA and Apple Silicon; an Intel Mac has no GPU acceleration for local models. The design treats three setups as first class:

• a Mac at home;
• a Linux machine at home;
• a cloud server built from a published image.

On a Mac, the multi-user system runs inside a Linux container, and GPU components run natively beside it. On Linux, whether the multi-user layer runs on the host or inside the same container is open. Hardware minimums aren't set.

A machine at home is the default. Cloudflare sometimes challenges sign-ins to Anthropic from datacenter address ranges, and two public bug reports about it were closed as not planned. So on a rented server, a member's re-sign-in can fail for reasons they can't see.

Updates Status: Decided

Claude Code ships new versions several times a week. In the design, AGI For Us holds each household on the last version we tested, and moves only when a newer one passes our checks. If a machine can't reach the list of tested versions, it changes nothing and tells the administrator there haven't been updates in a while.

Everything we ship comes as best effort, and we say where that effort can fall short. Our testing may fall behind, which leaves you on an older version. A component we recommend may carry a bug we missed. Our list of tested versions may go stale.

The full trust list Status: Decided

Every party below can do what it says, whatever its terms promise.

• The administrator's machine can read everything stored on it: every member's conversations, memory and credentials. AGI For Us gives the administrator no tool to do it and doesn't help.
• Anthropic receives every prompt and response, under each member's own account.
• Telegram, if you use it, can read every bot chat.
• The relay, if you use one, sees when and how much each phone talks to the household's machine, but not what is said.
• A backup remote, such as a private GitHub repository, holds a copy of the family's structured data. Encrypting it before it leaves the machine is the intent; how isn't designed.
• Each component you add sees what it processes. A local voice model hears every member who uses voice.
• AGI For Us itself runs on intelligence plus a few hard checks. It can be wrong, and it can be tricked by text it reads, including a message one family member wrote. A model can piece together a secret from facts that are each fine to share. A member who can see their own assistant's tool output can read guidance that was meant only to steer it.
• Any member can have the assistant keep something from you, or tell you something that isn't so.
• Leaving doesn't take back what you told it: what you shared stays with the household, under the rules you set.
• If the administrator stops, nobody else can run the system yet. A second administrator is planned for a later version.
• Nothing expires. The current view forgets; the log keeps everything. Assume a court could see it.

Why each person signs in themselves Status: Decided

Anthropic's Claude Code legal page sets the line we design around. It says:

"Anthropic does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users. Moreover, developers may not collect, store, or intermediate Claude.ai credentials or session tokens — sign-in to a Claude account must complete through Anthropic's own flow."

Two sentences later, it says:

"Nor does it prevent an end user from signing in to the unmodified Claude Code binary with their own Claude subscription, including where a platform hosts Claude Code as described under Can customers offer Claude Code in their products? above."

We read this as allowing several people, each on their own account, to use one machine, and as ruling out one account serving several people. So AGI For Us:

• runs the unmodified Claude Code binary;
• has each adult sign in through Anthropic's own flow, under their own plan and billed to them;
• never pays for, resells or routes anyone's usage;
• runs no servers of its own.

Before the first release, we'll also have to accept Anthropic's Commercial Terms, which the legal page requires of any product that runs Claude Code.

Each person needing their own plan, their own sign-in and regular renewals makes a household setup hard, and that difficulty is why AGI For Us exists.

What we've built so far

We built seven proofs of concept, each to answer one question the design depended on. Each comes with a record of its decisions and of the failure cases it found and left unfixed on purpose; most also record the ideas they didn't pursue. They are prototypes, not the product, and nobody outside the project has tested them yet.

What testing taught us

• Access control decides which records you see, not which fields. Our own attack suite found the history call returning a record's full sharing rules. Every read path needs the same output filter, not just the same permission check.
• The hard leak is inference. Facts that are each harmless can add up to a secret. The best place to defend is the moment someone marks something secret: warn them which visible facts give it away.
• A check for leaks has to judge meaning. In our tests a model let a sealed secret out in a paraphrase that matched none of the phrases we were scanning for.
• A store that can't retire a corrected fact serves both versions. Recording caught every correction, but the prototype store had no way to mark the old version as replaced. That is the first gap the store has to close.
• Search has to work in every language a household uses. An English-only embedding model ranked a question in another language at chance, so a multilingual model belongs on the list of requirements.
• Check what you scraped. A sign-in URL read off a terminal was silently cut at the screen's edge and cost two failed sign-ins before anyone noticed. Captured URLs are now validated before use.

What we haven't decided Status: Open

These are open, and the answers will change how parts of AGI For Us work.

1. How long a member's session lives. A fresh session per conversation, or one long-running instance per member?
2. Where the multi-user layer runs on Linux. On the host, or inside the same container macOS uses, so every household runs the same thing?
3. What the memory store is made of. A database inside the service, or plain files only the service can read, with git as the backup?
4. Whose rule wins. If a parent has a standing request to be kept aware, and their adult child wants to keep one topic back, does the child's choice always hold, or only where the arrangement allowed for it?
5. What happens to a fact nobody classified. Should it stay private until someone decides?
6. How the app reaches the house. A small relay run by each family is the current plan, and it isn't final.
7. How far isolation between members goes. Should members be able to see that the others exist, or see their running processes?
8. How members prove who they are to the memory service. Is a token enough, or should it be tied to the member's OS account?
9. How members sign in to Claude. The normal sign-in, renewed from time to time, or a one-year token that AGI For Us would store?
10. Whether members' requests travel with family messages. One channel for both, or a separate path to the administrator?
11. What gets recorded. Everything that might matter, or only decisions, facts and open loops?
12. A check on what the assistant says. A second pass that reads a draft reply for anything it shouldn't reveal and has it rewritten. It's proposed, and not designed yet.
13. What the machine needs. Minimum hardware for each setup.

How we build it

• Start with intelligence. Rules and guidance travel with the information, and the model applies them. Chris King, the founder: "start with intelligence as the default solution, and then patch the holes where it's really worth adding something on top." The clearest case for a hard check is a mistake the model can't see from inside: a setting that was silently dropped, a missing fact, a secret it doesn't know it could rebuild.
• State what each party can do, not what it promises. A list of capabilities stays true when someone changes their terms; a summary of promises doesn't.
• One way to do each thing. If one implementation can serve every case, we build only that one, even where a second would be nicer on some machines, because the path few people use is the one that quietly breaks.
• Anything that differs between households is data, not code.
• Strict where a default can hurt someone who didn't choose it; opinionated everywhere else.
• Script what we create, describe what we find. Parts that must come out the same everywhere, such as a fresh relay server, are scripted. On a machine that already exists, we describe what a component needs, and Claude on that machine does the fitting.

Follow along

AGI For Us will be published at github.com/AGI4us. To hear when there's something to try, leave your email on the home page.