It's interesting to see the market movements from the big players.
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 :)
If your mixing work with personal calendars that’s a bigger problem.
Work should be entirely separate calendars with things from personal added to it in generic blocks the owner can understand but protects from this leakage. Work calendars are owned by companies (generally) and should be treated like the are looked at by coworkers.
You can turn on a feature that will not auto-add invites to your calendar if sent from "unknown senders". The downside (significant IMO) is that "unknown senders" is based on Google Address Book + Other Contacts (aka people you email with). So if you're texting with someone, using a Calendly-style link, or pretty much any other non-email method of communication to schedule the meeting, it can easily be lost. It will still end up in your inbox, but you will have to accept the invite there for it to appear anywhere in Google Calendar.
Firstly, I want to offer my sincere apologies for how we mishandled this. You are absolutely right: we should have done a better job communicating how this change was rolling out.
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 patrick@reclaim.ai if you'd like to discuss this further.
Congratulations on your success. Reclaim.ai has been an incredibly valuable tool for me and my work.
I'll admit to feeling like this will be the beginning of the end for me. I love Reclaim right now, it serves its purpose very well and stays completely out of the way whilst doing it, but I don't have any love for Dropbox or the vision for the future with Dropbox.
Maybe I'm completely wrong though and you'll pull off something great. Best of luck and congrats again.
I appreciate the candor, and the support for Reclaim.
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 :)
Yeah, its kind of a bummer. Dropbox doesn't really have a cohesive vision for their productivity suite? Dropbox Paper doesn't seem to have progressed and there haven't been any other notable new products released.
Not the question I asked though. I’m far more interested in knowing how well everyone did exit wise, as that is a data point that would be most useful to the general public.
Out of Dropbox's long history of acquisitions, very few of the products from said acquisitions have survived. Did this factor into your decision to join Dropbox and if so how did you weigh that risk?
My concern is simply: privacy (not from Reclaim.ai, but Google and other Big tech).
I would hope there's a way to not use Gmail, and changing from my Fastmail.com at this point would be a burden on work colleagues, but I'd do it if the details of my family's life can somehow remain private.
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 :)