zwigglers

If you're trying to solve this problem right now you should take a look at cast and see if it addresses your problem. Would love to stress test my framework against different use cases.

Not imagining it, using it in prod. Not sure how you define "multiple instances" here but basically, one agent with multiple concurrent conversations. Access level is based on the point of ingress to the agent, limitations are mechanical (tool access) and semantic (affecting posture, not a true security boundary but you can inflence behavior per entrypoint).

It sounds like you're describing two chat sessions = two agents, one chat session per agent. The agents get different tools, no shared context, no duct tape. Is this an accurate read?

The duct taping comes in when two different people share an agent, when having a shared context is useful.

The shared context use case is less common. You have to have hit that wall yourself to feel the problem. Does that track?

Exactly that. Separate sessions give you data isolation. The hard part is capability isolation, like selective collaboration (between multiple users and multiple agents).

My household runs a shared agent on Telegram, my partner and I can do everything, calendar, purchases. My kid should be on a different trust tier, can ask questions but not send emails on our behalf for example. With a prompt rule the kid can just say 'dad said its okay', but with cast the kid's ingress is wired to a permission set that never reaches certain tools.

That's the simple version. The more interesting case is building agents that collaborate across trust boundaries in real time, but that's a longer conversation.

Fine for single-user setups. I'm solving a different layer: multi-agent/multi-user identity and routing. When multiple people with different permission levels are all talking to the same agent, env vars don't tell you who's asking or what they're allowed to do.

You caught me. no time travel. I updated the README about an hour in (added the before/after code block). Codebase was there from the start, just some docs polish.

For a dev team using agents as coding tools + coordinating via git, that workflow makes sense.

I built cast for other (non-coding) scenarios. A shared agent that multiple people interact with conversationally in real time, with different permission levels.

Think a household assistant on Telegram, or a small team's internal tool where sales and engineering collaborate but shouldn't see each other's data. There's no PR workflow there, just people chatting with a shared service.

On Mac Mini: Runs on anything with Node and a container runtime. Just trying to tap into the zeigeist.

Thanks, means a lot. the "tried to build it myself" crowd is exactly who this is for

Hi HN, Yao here. Most frameworks are built for one developer, one agent. The moment a team shares infrastructure, people end up duct-taping row-level access into the prompt and hoping the model doesn't argue past it. I got tired of that.

Cast is a harness for multi-user, multi-agent systems: one server, a handful of people with their own identities, a fleet of agents handling different things and talking to each other when they need to. Agents are skills and CLAUDE.md, not Python classes, so you can focus on launching quick and refining the agent based on real usage. MIT, self-hosted, runs on a Mac Mini.

Cast puts access control in the routing layer, not the prompt. Each agent runs in its own container with actual filesystem boundaries. Identity verified before the agent sees the conversation (Slack, telegram, etc). Credentials never mounted in.

Developer alpha. Looking for teams that have hit the multi-user Claude Code wall and want to try this out. github.com/yaodub/cast. MIT. BYO Claude key.

The version that probably works better is triaging in advance what's definitely not Opus territory: summaries, documentation, test generation.

Same pattern. Scanners flag everything. The problem is there's no layer between findings and everyone's inbox. Prioritization is harder than detection.

The issue being highlighted is that Google is not deploying humans to review these decisions and instead leaving them to automated systems.

There is a difference between being an responsible enforcer of IP rights and automatically removing apps when they receive a complaint.

If you read the article in more detail, the complaint's only request was that the offending app's name be changed. The offending app complied with the request, but upon appeal Google did not take this into account and offered a boilerplate rejection without considering the facts of the particular case.