zwigglers

25 ms·

1.
by zwigglers 4mo ago
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.
2.
by zwigglers 4mo ago
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 mec
3.
by zwigglers 4mo ago
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
4.
by zwigglers 4mo 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
5.
by zwigglers 4mo ago
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&#x2
6.
by zwigglers 4mo ago
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.
7.
by zwigglers 4mo ago
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 pe
8.
by zwigglers 4mo ago
Thanks, means a lot. the "tried to build it myself" crowd is exactly who this is for
9.
Show HN: Tired of duct-taping access control into agent prompts. Here's the fix(github.com)
22 points by zwigglers 4mo ago|23 comments
10.
by zwigglers 4mo ago
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 tha
11.
by zwigglers 4mo ago
The version that probably works better is triaging in advance what's definitely not Opus territory: summaries, documentation, test generation.
12.
by zwigglers 4mo ago
Same pattern. Scanners flag everything. The problem is there's no layer between findings and everyone's inbox. Prioritization is harder than detection.
13.
Sudden removals from the app store are a danger for every Android developer(medium.com)
2 points by zwigglers 8y ago|0 comments
14.
by zwigglers 8y ago
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
15.
Google's automated system wrongly removed our app. A human would have stopped it(medium.com)
3 points by zwigglers 8y ago|2 comments