undefined | Better HN

0 pointszwigglers22d ago0 comments

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.

0 comments

3 comments · 1 top-level

embedding-shape22d ago· 2 in thread

> small team's internal tool where sales and engineering collaborate but shouldn't see each other's data

Right, but wouldn't that happen by default? Lets say I slap a PHP API in front of a local Codex instance running somewhere, then let people login and chat with those, then by default nothing is shared? Sharing stuff between, is extra stuff on top, not things that happen by default, so I'm still not sure what the "duct-taping row-level access into the prompt" actually means in practice? You mean people would ask to access other's data and you want to prevent them from that?

zwigglersOP22d ago

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.

embedding-shape22d ago

> My household runs a shared agent on Telegram, my partner and I can do everything, calendar, purchases.

Alright, so already here you have permissions, per user, it sounds like, as you both have different chat sessions, I'm assuming?

Associated with those chat sessions, is the user, and what tools (via MCP or passed manually to the model, or whatever) it has access to at that moment.

Already here you have what's needed 100%? Why would you give/remove access via the prompt, I don't think anyone use LLMs like that in the first place?

Adding tool calls/responses is already doing something more, but instead of doing less, you suggest piling something on top of that?

Sorry if I seem slow, I'm just trying to understand what problem you're actually trying to solve here, as it sounds to me you're trying to solve something you could have just not done to begin with, then you don't have that problem anymore at all?

1 more reply

j / k navigate · click thread line to collapse