Lightbody
Joined 17 years ago
Joined 17 years ago
My point is: context and privacy is HARD in multi-player modes.
This announcement is all about Claude extending its reach beyond single-player workflows and into multi-player workflows.
On the flip side, Slack just announced MCP support for the Slackbot AI chat capability embedded within Slack. It is, for now, exclusively single-player.
Single-player is the "safe place" (relatively speaking). The context, permissions, and standards (MCP/MCP UI apps) all work reasonably well for it, but get super complex or break down entirely when thrown into a multi-player shared context. I suspect Slack is doing what they are doing with an eye towards multi-player, but it's hard to say how that will manifest.
For a real life example of this challenge: I work in scheduling (for Reclaim.ai) and you can ask our chat to find time to meet with a coworker and we go find time and help explain why certain times won't work. For example, it might say: "I couldn't do 11am tomorrow because you've got a job interview scheduled on your personal calendar". This is safe and fine to do in a private context.
But... imagine if one were to ask our service (or Claude) to find time with someone and it replied to the thread for everyone to see: "The soonest I could find is 12pm tomorrow. Reggie is available at 11am, but Lightbody has a job interview so it won't work". WHOOPS.
I think the other comments in this thread have the right idea of it: for this to really work safely, the permissions model needs to be nailed down, and it may mean that you end up with multiple identities of "Claude Tag" (or whatever agent you engage with in a public forum), and the context it gets is only the context that particular identity is entitled to, just like any other employee. But then that gets tedious because now I've got even MORE "people" to keep track of and know who to engage with, which is half the problem getting work done in large enterprises.
Will be interesting to see how this evolves. I'll have my popcorn out :)
Context: I'm the cofounder of Reclaim.ai.
https://www.votebeat.org/michigan/2024/10/24/michigan-regist...
For background (and for anyone else reading): what is being referenced here is that Reclaim is, by definition, a product that can straddle two or more Google or Microsoft accounts. It can do things like block out your work calendar when your personal calendar gets busy.
The issue is: some companies have come to us and told us they will no longer approve of Reclaim's access to their calendars unless we enforce certain restrictions, such as only allowing authentication to an account that contains their calendar data (ex: Reclaim!) via their SSO provider, and no other authentication is allowed.
It isn't quite accurate that they have "taken over" your account. In fact: if you disconnect their corporate Google/Microsoft account from your Reclaim account, you are free to use it how you want. For example, their regular calendar sharing allows you to connect to your work account via your personal Google calendar, you could do that and not avoid any disruption in service. But most companies don't permit more than "free/busy" level of sharing, which isn't quite enough for this workaround.
If you need help disconnecting your company's account from your Reclaim account, we can walk you through how to do that.
We are exploring more sophisticated (but much more expensive) solutions, such as allowing you to authenticate with your non-company credential but not show you any information that is associated with your company calendar (ex: data masked). But it's unclear if your employer (and similar) would accept this. It's also still a degraded experience for the end-user, so it's tough to say if this is ultimately better or worse than the current situation.
That all said: I am sorry we didn't roll out this change to you. I hope you will give us the benefit of the doubt and consider working with us on ways to meet your employer's requirements as well as yours. You are welcome to email me directly at [email protected] if you'd like to discuss this further.
Part of why we went with Dropbox was strong alignment for what the future of work can look like. Also because unlike many tech acquisitions, we were able to keep the entire team and product intact while continuing to invest in and pursue the long term vision we've had for Reclaim.
I hope you'll give us a chance to change your perspective in the coming years :)
Former: New Relic, BrowserMob, Selenium, Java open source.