Four always-on agents, rebuilt

Within a few months, xAI shipped Grok Bot, OpenAI shipped Dots, Anthropic shipped Claude Duet and Meta shipped Muse. All four are agents that keep working when you are not looking. We rebuilt each one from Foundry primitives, ran it end to end, and wrote down how to deploy it on Kuiper.

The rebuilds are independent examples built from public docs and launch coverage. They are not affiliated with or endorsed by xAI, Anthropic, OpenAI or Meta, and they are not how those products work inside. What they show is how much of each product is the same set of parts.

Grok Bot: teammates you make

Grok Bot lets you make bots and tell each one its job. A new bot asks what you want it around for, then names itself for the work: Sales Outbound, Inbox Manager. The bots are siblings: you write to the one whose job it is, ask your starred Primary Bot, mention them in a group chat, or one hands another part of its work. They all work on one cloud computer and in the apps you connect, like Gmail.

Our first build got this wrong. It had a definition per bot (a chief, an outreach bot, a bugs bot) and wired them together by route. That reads fine until you ask how a person makes a bot: they can't, because every bot is a file and every rename is a deploy. It is like Twitter keeping a page in its codebase for every user.

The rebuild now has one bot definition that says what any bot can be. Each bot is an instance in the person's workspace. Its name and job are the instance's name and description, and a new bot sets them itself with a take_job tool that writes its own record. A routine belongs to one bot, on a schedule or after an event like new mail, and is data on it too. A group chat has no host: each member keeps its side, and a message goes to the bots it mentions. Skills live in the workspace, so every bot reads the same library.

That changed Foundry too. Foundry had a delegates field that named workers by route, and it created a worker per route behind your back, so the bot you made was not the one that answered. We removed it. Foundry now hosts Glove Mesh instead: agents message each other by instance id, their peers are whoever is in their workspace, and a reply comes back to the conversation that asked. Running many bots on one definition also exposed a scheduling bug, where one busy bot made the others skip their routines. That is fixed. Read the build, and Agents are data for the rule.

We also first built from launch coverage and got details wrong. We first built a chief and a router as definitions of their own. Grok Bot has no coordinator kind: the bots are siblings, and what starts one is the request that reaches it. The starred Primary Bot that takes everyday asks is one of them, and the star is data you can move. Apps belong to the account, not to a bot, and group chats let the bots decide who answers. The rebuild follows that now.

Connecting apps took a second pass too. The quick way is to point the agent at each app's MCP server and put every tool in its context. Foundry already has a better place for this: an app. A Foundry app owns the account it works with, the way messages come in (a Gmail watch that delivers new mail) and the way they go out (a send that Foundry delivers inside the account's session after you approve it). Foundry apps can now carry an MCP server too, opened with the installation's account, with a rule per tool: allow, ask or hide. The reads become functions the bot calls in code, gmail.search_threads(…), so a dozen lookups are one program instead of a dozen turns. Accounts and tokens stay in your own store; Foundry reads them through a directory you supply. All four rebuilds connect apps this way. Building it also turned up a hole: an agent could send on a bound route through glove_foundry_transmit without the approval the app's send asks for. That tool now sends only on routes the agent's playbooks declare, and asks when the transmission asks.

Claude Duet: a partner

Duet is one agent in one thread. It sends a brief each morning, checks in through the day and messages you only about what you said you want to hear. It asks before it sends, pays, signs or deletes, some things it won't do even with approval, and a classifier keeps card and ID numbers from leaving.

What makes it proactive is two schedules built from the person's data: their time zone, when they want the brief and which hours are worth a look. Change a preference and the next run moves the schedule:

schedules: (_agent, { agentInstance }) => partnerSchedules(agentInstance.context),

The rest is approvals and a guard. requiresPermission takes a function, which turned out to matter: a message the guard will refuse should not ask you to approve it first. Long jobs go to its computer, another agent in the person's workspace, over the mesh. Read the build.

OpenAI Dots: your dot

You name your dot and make it your own. It keeps notes on your ongoing responsibilities, researches in the background with read-only tools, and works on a computer of its own. Your Custom Rules say, per action, whether it acts without asking, acts when you ask, asks first or hands it to you, and an auto-review you can't switch off checks sensitive actions before they run. Password changes and money transfers are always yours. You reach the same dot in ChatGPT, Slack or on a call.

In Foundry, a dot is an instance whose data holds its name, your responsibilities and your rules, and a specialist dot for an organisation is the same definition with its own account. Read-only research is a tool list that depends on what started the run: a schedule gets only the read tools, so the acting tools are not there to misuse. The auto-review is a wrapper around each acting tool. Heavy jobs go to the person's builder over the mesh, and research runs don't get the mesh at all. Read the build.

Meta Muse: an agent that does the work

Muse is one agent per person that sends the email, books the table and pays, on a computer of its own. You reach it in its app or on WhatsApp, you choose what it may do in each app, and a separate Sentinel decides what may leave its computer. When a site turns agents away, it stops and tells you.

Most of it was already there. WhatsApp is a Foundry app with a transmission each way. The access you choose is the installation's config: with read only, the app hides every write and the send binding is off. Its computer is a real Chrome on Kuiper, mounted with glove-execution/kuiper, which lasts between runs because a Kuiper session belongs to the project, not the process. The interesting part is the Sentinel. The browser adapter calls a guard for every request the browser makes, outside the page, so the Sentinel sits there with its own small model. It never sees Muse's conversation or the pages it read, which is the point: a page that tells Muse to send your email address somewhere cannot talk the Sentinel round. Here it guards the browser; app reads and sends go through Foundry's apps, at the access you chose and after approval. Sign-ins are yours: Muse hands you Kuiper's live view of its browser, you sign in, and your profile keeps it. The card for a purchase is typed in by host code, so Muse never sees it. The log of what Muse did is written by a subscriber from Foundry's side of the run, so the model cannot leave anything out. Read the build.

What they share

Line them up and the same parts keep appearing:

• One definition per kind of agent, and every agent as data: an instance per person or per job, with what makes it theirs in its data.
• Agents in a workspace that message each other by id over the mesh.
• Schedules for runs nobody asked for.
• Approvals on anything that changes the world.
• Connected apps as Foundry apps: the provider's MCP server for reads in code, a transmission for sends, a connection for new mail, and accounts in your own store.
• Transmissions and playbooks for messages from outside, like new mail or a Slack message.
• On Kuiper: the /data disk for all of it, the model gateway, and a lock on the API.

The differences are mostly policy: who you talk to, what wakes the agent, what waits for you, and what may leave its computer. Those are the parts you write. The rest was already there.

Try them

pnpm --filter glove-foundry-bot-crew verify
pnpm --filter glove-foundry-proactive-partner verify
pnpm --filter glove-foundry-standing-agents verify
pnpm --filter glove-foundry-personal-agent verify

Each runs offline with scripted models, so it checks the wiring with no keys. Add ANTHROPIC_API_KEY and run pnpm dev to use real models. The Rebuilds section has a step-through of each.