Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Tag

anthropic.com

Post reply on HN
Print view View original

141–150 of 200 posts

Re: Claude Tag

#141

Post by Lightbody »

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 :)

Re: Claude Tag

#142

Post by on_meds »

Lightbody wrote: post #141

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, permissi…

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.

Re: Claude Tag

#143

Post by NewsaHackO »

MeetingsBrowser wrote: post #109
NewsaHackO wrote: post #104

Earlier quoted context omitted.

How are Anthropic's production applications poor quality? Other than memory use (which unfortunately is the industry standard nowadays) Claude Code is pretty solid.

Claude code is by far the buggiest piece of software I interact with, If the underlying model weren’t so good, I would never opt to use it. It takes multiple seconds to launch, random lines disappear in the scroll back, it’s internal state gets messed up causing the TUI to show duplicate and/or offset lines, and it frequently causes some kind of GPU buffer corruption causing the entire terminal env to show garbage.

>It takes multiple seconds to launch,

Yes, this is the ubiquitous memory issue that I mentioned. Unfortunately, it is now the baseline in all modern apps.

>random lines disappear in the scroll back, it’s internal state gets messed up causing the TUI to show duplicate and/or offset lines,

I haven't seen this issue, other than when I am using a shell that is bugged and does it with all TUI/console programs (usually a virtualized shell which I resized). Do you have a reproducible example of this?

Re: Claude Tag

#144

Post by yalogin »

This is quite brilliant. This will seamlessly integrate with every collaboration systems as long as they are able to “enroll” Claude as a user. Claude gains knowledge across systems and makes the ai enhancements for each app/system unnecessary. For example if slack creates something similar it’s less useful because Claude’s model works across any system/app. More so, anthropic can either charge for it separately or not , companies will pay in extra used tokens anyway.

Re: Claude Tag

#145

Post by verdverm »

NewsaHackO wrote: post #104
nozzlegear wrote: post #71

> Today, 65% of our product team’s code is created by our internal version of Claude Tag. Given the reliability and general product quality of the Anthropic product team's code, this doesn't sound like a selling point.

How are Anthropic's production applications poor quality? Other than memory use (which unfortunately is the industry standard nowadays) Claude Code is pretty solid.

Their product features are a venn diagram, so depending on the tool you use, you may or may not have access to a "Claude" feature

i.e.

- design is only available in web

- cowork is only available in desktop, sharing projects only works in chat, not cowork, which is arguably the more valuable place to have that feature (re: multiplayer like tag). SSO only works if you type your email, the "login with google" button be damned, and only after you finish typing your email does the login button text change.

- cli has a number of features only available there, with the cowork equivalent having a different name iirc

If you admin/support other people using the breadth of tools, you will see more of the slop they sling

Re: Claude Tag

#146

Post by holografix »

Wowza this will be a token guzzler. Assuming Claude is parsing every message posted on multiple slack channels, compacting knowledge etc.

Looks like Anthropic is progressing further into platform territory and conquering Agentic use cases left right and centre. If you’re building an agent platform for workforce productivity today, your best best is model agnosticism and focus on token cost control.

Re: Claude Tag

#147

Post by brandensilva »

holografix wrote: post #146

Wowza this will be a token guzzler. Assuming Claude is parsing every message posted on multiple slack channels, compacting knowledge etc. Looks like Anthropic is progressing further into platform territory and conquering Agentic use cases left right and centre. If you’re building an agent platform for workforce productivity today, your best best is model agnosticism and focus on token cost control.

That's exactly what I'm doing. Push for model flexibility, cost control, and reliability.

The moat is to be anti lock in. The open source model needs to be amped up on steroids to avoid this permiating every facet of your org you cannot escape.

Re: Claude Tag

#148

Post by KptMarchewa »

SAK_ATAK wrote: post #98

I don't understand how this is gonna fly for enterprise security and compliance. Claude needs to inherit permissions from somewhere, and those permissions will never align with the members of a slack channel. And finding the lowest common denominator of access probably results in a dumbed-down, useless experience. The only way it works is if customers truly start treating agents as humans with the same liability as a…

What permissions? I believe this does not actually _modify_ anything, just creates PRs. _Humans_ merge them.

Re: Claude Tag

#149

Post by bitlad »

What if you could do this:

@claude collect all the internal knowledge and context. And fire folks who are not required.

Re: Claude Tag

#150

Post by allan_s »

bitlad wrote: post #149

What if you could do this: @claude collect all the internal knowledge and context. And fire folks who are not required.

Fortunately hr system in most companies are from software vendors that are 2 gen behind so a mcp with a "fire $EMPLOYEE " tool will not come up

Would also be funny if it fires the one who done the request.

Post reply on HN