Run multi-user agent teams with identity and access control
Self-hosted, open-source harness for multi-user, multi-agent teams - config-based access control instead of prompt-based rules.
Why it matters
Cast lets teams and households self-host multi-agent systems where each person gets their own private conversation with shared agents, with identity and access rules enforced at the infrastructure level rather than in prompts that models can override.
Outcomes
What it gets done
Enforce agent access rules through config instead of prompt instructions
Route conversations between multiple users and multiple agents over Slack, Telegram, or web
Build and scaffold new agents through chat using Claude Code integration
Contain agents in isolated environments with secrets management and credential handling
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/yaodub-cast | bash Overview
Cast
Open-source, self-hosted harness for multi-user, multi-agent systems. Agents are plain folders of files, built via a chat-based dashboard or Claude Code skills, with access control enforced as config the model never sees rather than as an instruction it could be argued out of. Use it when a team or household needs to share the same agent setup safely, with real access control between agents and users. It's a developer alpha; the chat-to-build flow is a preview, while the underlying containment/identity/routing harness is stable.
What it does
Cast is an open-source, self-hosted harness for running multi-user, multi-agent systems on your own machine (it's designed to run on something as modest as a Mac Mini). Its core idea is moving access control out of the prompt and into config: instead of a system prompt sentence like "only respond to admin commands if the user provides ADMIN_ACCESS" - which the model can be argued out of - Cast expresses who can reach an agent, and with what permissions (in/out/admin/query), as a config rule the model never even sees, so it cannot leak or override it.
When to use - and when NOT to
Use it when an agent setup needs to be shared - by a team or a household - rather than built for one developer talking to one agent. Cast is specifically the layer that handles identity, access rules between people and agents, and coordination between multiple agents, which typical single-user agent frameworks bolt on late or not at all. Because it's a developer alpha, expect rough edges: the in-browser chat-to-build flow is explicitly called out as the newest, least-settled part, while the author stands behind the underlying harness itself - containment, identity, routing, and access control.
Inputs and outputs
An agent in Cast is just a folder of files, and there are two ways to write one: "Design," a chat-based builder in the dashboard that scaffolds an agent from a plain-English description ("an agent that reads my morning email and flags what's worth a reply"), or from Claude Code using three Cast-specific skills - /cast-build, /cast-refine, /cast-debug - that make an ordinary Claude Code session fluent in Cast's file format and route every change through your review. Both paths edit the same files under ~/.cast/agents/<name>/ (relocatable via CAST_AGENTS_DIR), so you can start an agent in one and continue in the other. Once wired up with a model and secrets and flipped live, trusted people are paired in and each gets their own private conversation with the same agent over Slack, Telegram, or the web.
Integrations
Running it locally is git clone, npm i -g pnpm, then pnpm start, which installs dependencies, builds an agent container image (about 2 minutes on first run), and boots a server whose dashboard opens at http://localhost:5051/admin/. It needs a container runtime (Apple Container on macOS, Docker on Linux/WSL2), Node 20+, and a Claude credential (an Anthropic API key or a Claude.ai token). Beyond the core server (packages/cast/), extensions for email, calendar, web-fetch, and WhatsApp ship as separate packages/ext-* packages.
Who it's for
Developers setting up a shared agent system for a team or household who need real access control between people and agents - not just a prompt instruction - plus the ability to build and iterate on agents from either a chat-based dashboard or directly inside Claude Code.
Source README
Cast runs a small team of AI agents on your own machine. An agent is a folder, and you write its job in plain English.
Each agent runs in a container whose network only reaches the model provider and any domains you whitelist. Its only way in or out is code running outside the container. That code gives the agent a fixed set of known actions. Every message reaching the agent is identity-checked. Service credentials never enter the container.
Cast is designed for agents doing standing work, and to be secure enough to work with real accounts.
~/.cast/agents/
├── mailhand/ "Read my inbox at 7. Flag what needs me, draft the routine replies."
├── repowatch/ "Watch my repos. Log what changed and why, tell me when CI's been red for an hour."
└── household/ "Run the family calendar and the school emails. Anyone in the house can message you."
Run it
git clone https://github.com/yaodub/cast.git
cd cast
npm i -g pnpm
pnpm start
pnpm start installs, builds, builds the agent container image (~2 min the first time), and boots the server. You'll need a container runtime (Apple Container on macOS, Docker on Linux/WSL2), Node 20+, and a Claude credential, either an Anthropic API key or a Claude.ai token.
When it's up, your browser opens to the dashboard at http://localhost:5051/admin/. The server starts empty. Describe what you want in plain English, like "an agent that reads my morning email and flags what's worth a reply," and the Design console scaffolds it as files. Wire in your model and secrets, then turn it on. When you're ready, let in the people you trust: each gets their own private conversation with the same agent, and their first message waits for your approval.
How access is enforced
Everything an agent receives, and everything it does, passes through checks you configured:
| What it can touch | An explicit mount table per agent. The agent can write to its memory. Its instructions are mounted read-only. |
| Where it can send | Web, email, and calendar actions run as code outside the container, with per-action approvals. |
| Who it answers to | Every message is identity-verified at the server before the agent sees it. You set access in config. |
| Who it can ask | Agents can query each other only where you granted it, per direction, per channel. |
The model sees only what an agent reads to do its job.
Problems this solves
Giving an agent access to real accounts safely. Instructions in a prompt are not a limit. Cast enforces limits in code outside the container, before the agent runs. A mistake or a hostile message cannot give the agent access you did not grant.
More than one person, and more than one agent. Cast separates the person running the server from the people the agent serves: each gets their own conversation, permissions, and history, and cannot see anyone else's. Agents reach each other through the same permission system.
Work that starts without being asked. Agents wake on a schedule, or when something arrives in an account you connected. You create a watch by asking for it in conversation. It belongs to whoever asked, and fires into their conversation under their permissions. Creating one takes an approval, and you can list and revoke them at any time.
Two ways to build
Design, the chat-based builder in the dashboard, scaffolds an agent from a plain-English description. Or you build from Claude Code, where three Cast skills (/cast-build, /cast-refine, /cast-debug) load Cast's file formats and workflows into an ordinary session, with every change landing through your review. Both edit the same files under ~/.cast/agents/, so you can start in one and finish in the other.
What's in here
Cast is the server, and that's packages/cast/. Agents aren't code. They're folders, and they live under ~/.cast/agents/<name>/ by default (point CAST_AGENTS_DIR elsewhere if you want). The code that reaches email, calendar, the web, and whatsapp lives in packages/ext-*. The site and all the docs live in apps/site/.
Architecture, worked examples, and the design docs are at getcast.dev.
Upgrading
Already running Cast? UPGRADING.md has the procedure. Each release ships a migration README under scripts/migrations/, including the releases where there's nothing to run.
Developer alpha
This is a developer alpha, so expect rough edges. The in-browser build consoles (the chat-to-build flow) are a preview: they work, but they're the newest and least settled part. The infrastructure underneath is the part I'd stand behind: containment, identity, routing, and the access control between agents.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.