Name: Claude Tag on-call: A new teammate in your incident channel
Uploaded: 2026-10-15T18:19:48.126Z
Duration: 45 min 8 s
Description: Claude Tag on-call: A new teammate in your incident channel

Transcript for "Claude Tag on-call: A new teammate in your incident channel": Hello. Thank you for joining us today for our Claude Tag on call, webinar. We're gonna be diving into how we can operate Claude Tag as a teammate in your Slack incident channel. And so, really, what Claude Tag is is our way of bringing Claude Code remote into Slack so that it's a multiplayer experience that everyone in the channel can kind of steer and engage with together. One of the breakout... Breakaway use cases for this product today is incident on call and incident response. And so we're gonna dive right into it, and I'm really excited to share share it with you all today. My name is Kevin Martin. I work on go to market incubations here at Anthropic. And, without further ado, let's go ahead and dive into all things Claude tag and on call. Before we get straight into tag, I think it's important to kind of walk the line of, you know, how our products have evolved at Anthropic. Obviously, in 2023, the way that people were engaging with large language models was primarily via chat. Right? And so, you know, you'd ask questions, you'd get answers, and that's really what the state of the art was there, for a long time. In 2025, we brought Claude Code to market, and that's really the first enterprise grade agent that is still the industry leading coding agent today. If you were walking the halls of Anthropic in 2025, we'd noticed something really funny. And what we noticed was that people outside of engineering organizations, in go to market, marketing, you know, so on and so forth, finance, we noticed that they were using Claude code to do their job. And we had this epiphany of, like, wow. This agentic loop is really powerful and is, you know, capable of driving great results beyond just software engineering work. And that actually led us to to bring the same Claude code harness to our desktop app, under a product that we call Cowork. And so Cowork is the same, you know, same agentic harness under the hood as code, but it's, you know, wrapped in a friendly user interface that allows knowledge workers to get the same type of powerful experience out of, out of out of Cowork that they would get out of Claude code. And now taking the next step, going on to Claude Tag, ultimately, Claude Tag is backed by Claude Code remote. So it is the same exact harness that you would have, you know, in Claude code, in in Cowork, but it's a little bit different as well. And I'll I'll kind of talk about the key differences here. I think it's important to differentiate between the previous product generation. If you think about Claude Code and you think about Cowork, these were really places where you would go ahead and collaborate with Claude. You'd be sitting over Claude's shoulder or Claude would be sitting over your shoulder, and you'd kind of be steering and driving the change that you were looking for together. Claude tag is a slight departure away from collaboration, and it's a step toward delegation. And so this is a a a a surface where you're basically not only giving Claude a single task to solve for, but you're giving it a category of work to solve for. Here we can see that we're basically saying, you know, whenever an alert fires here, start investigating before anyone asks. This is an example of what we would call a standing responsibility, and this is ultimately the pattern that we're gonna be exploring today for for incident on call. The the essential prompting pattern is something like whenever x, do y. And as long as x is an event that shows up in Slack, you can basically define the job that Claude Tag will be doing and how it will be responding to those events. And so it's a it's a really powerful paradigm to not only hand Claude a task, but to give it a a category of work that it'll own, for a time span that you ultimately define. Now, obviously, in the early days of our products and our models, you would have to collaborate with Claude. It was important for you to really insert yourself and steer and make sure that the agent was building what you wanted to build. Tag as a delegate first product has really only become viable thanks to the massive increases in model intelligence today. So I definitely wanna highlight the fact that, you know, this is a this is a product that requires a high degree of intelligence. I would default Claude Tag to Opus 5.5 today and then allow users to kind of click up and down to, you know, Fable or to Sonnet as necessary. But this this method of working has really only become possible thanks to the recent in the, advancements in model intelligence. I think it's also important to understand how Claude works in its own, how how it works, like, under the hood and, you know, really the things that make it a teammate. The first is that it's operating under its own identity. And so by default, it's gonna be acting under its own accounts. You know, it'll have the Claude app for Slack. It'll have its own, you know, GitHub identity via the GitHub app. But for all the other tools that you're gonna set up for, you know, metrics and alerting and pages and feature flags and, you know, so on and so forth, you're gonna need to give it its own service account that's... It... That will allow it to operate under its own identity. When a task, you ask for does not have the agent identity configured, you will be able to delegate your own personal connections, and that actually allows Claude to assume your identity and your connections for a given task. This is done in a very safe way. Once you delegate access, a colleague of yours cannot jump in and and steer Claude with your access, but it does allow you to kind of bridge that last mile. And so when the agent identity does fall short, you can always rely on your own. The next thing that's important to kind of understand here is that you're ultimately getting a Claude code remote session per thread. So every single thread will get a working session. They'll, you know, create a task list or a checklist that you can watch, and anyone in the thread can kind of steer it and answer so long as it's operating under its own agent identity. And then finally, the thing for it to be operating as a teammate is gonna be the access that it has. This teammate mentality is really important. If you're gonna bring, you know, Claude in to the team to do a job, you're gonna have to equip it in the same way you would equip a person on the team. And so incident on call might be something like an SRE team, for example. And if you want Claude to be operating as the incident commander and you want it to be able to do good investigations and actually operate as an extension of the SRE team, you need to equip it with the same tools and context that you would equip another member of the SRE team with. And, ultimately, an admin will be able to decide exactly what tools and information Claude will be able to reach on a per channel basis. For this example, in the incident channel that we're about to go through, Claude will be able to see the metrics, see who's being paged, see the current status of the feature flags in one repository, and nothing else. Another really important thing to understand is that there's a really sophisticated memory system behind the hood for Claude Tag, and it's gonna be remembering basically everything that's happening. And it's built off of all of our prior art with things like auto memory and auto dream. So Claude will be able to kind of, you know, over time understand are there patterns emerging from the different incidences that it's responsible for. So let's let's talk about the power of bringing this into into Slack. Really, what we were trying to solve for is, like, this this loop that you see on the left. Like, how can we cut out some of these round trips? So, you know, prior to Anthropic, you'd get paged middle of the night. You'd open up your laptop. You'd find the alert. You open up all the tools that you have at your disposal, the dashboards, the deploys, the feature flags. You have to do all this context aggregation. You have to report the context that you found in Slack, then you kind of go back and dig and so on and so forth. Right? It was a really kind of tedious, difficult process to go do this investigation, especially if you're, you know, unfortunate enough to be paged in the middle of the night. With Anthropic, all of this becomes a single thread in Slack. And so here you can see we have our metering service, which is, you know, triggering an alert on an a... Payments API error rate. Claudetag, based on a standing responsibility that it was previously given, figures out exactly when the error stepped up. It pulls the graphs from our metering stack. It diffs the last three deploys. It checks for feature flag changes and identifies that one actually changed two minutes before this incident started popping up, and it's able to go ahead and figure out exactly what the root cause was and then come back to me with, you know, what decisions should we make to to solve for the incident. And so this really simplifies the experience of of handling these incidences when you only are operating from a single pane of glass versus doing a bunch of investigation, across tools and services yourself. Ultimately, the way that you frame these standing responsibilities is really important. And there's a few different ways to do it, but they all kind of have the same common elements across them. So the first thing that you're gonna do is basically let Claude know, like, how long is it on the hook for a given job? How long will it actually be responsible for this unit of work? And it's absolutely okay for it to be an indefinite amount of time. You just wanna ensure that Claude is conscious of that. And so here you can see in my prompt for this incident alerts channel, I'm gonna tell Claude, hey. Remember for this channel, from this point forward until I tell you otherwise, so now this is an indefinite responsibility, We're next gonna move on to what the what the trigger is. We're gonna say, you know, when a meter lane alert fires, start investigating before anyone asks. So that's the trigger. That's the event that it's looking for. We're gonna then tell it what to do. So, again, like, whenever x, do right. Whenever x, whenever a meter lane alert fires, do y. We're gonna ask it to post what changed and what to look at first in the alerts thread. We're gonna propose a fix, but don't merge anything without a human being approving it. And if it's customer facing, we're gonna page the on call through pager line. When it's resolved, we're gonna draft the postmortem for review. And so we've now defined how long it applies, what triggers it, what it posts first, where it stops, who it pages, and when it's done. And, really, these are the the common elements of a good of a good standing responsibility. It's really important to explain what the trigger is and, you know, you know, where where its boundaries are and where it should be... When it should be considered done. This is kind of the same thing that you would have to be thinking through if you were building loops out in in Claude code. Let's go ahead and talk about the different ways that you can configure this standing responsibility. You could do this as a message in Slack. This is the way that I primarily do this at work today. I just message message Claude tag in my Slack channel, and I give it give it the standing responsibility. You can also go ahead and set this up in the channel level instructions if you want, and that will be, like, effectively a system prompt for a given channel. And so for channels that are very specific around handling incidences, you could do this there. You could also go ahead and build this into a skill that you load into the channel's access bundle. And then you would just basically say, you know, to Claude, hey. Whenever this incident happens, run the on call skill. So there's no, like, wrong way to do this. The important thing is that you include kind of the six elements below, and you give it a really clear description of the task at hand. Alright. Let's get into the demo. That's gonna be the fun part of this anyway. We're gonna follow a single alert from 11:04PM to the post mort. This is all gonna be happening in a demo workspace. The company is... The fictitious company is gonna be called Marchfell. The tools, the people, and every number are invented. This is meant to be illustrative, but it is a real pattern, one that we employ at Anthropic and one that a lot of our customers employ as well. Alright. Set the stage. It's 11:04PM. The payments errors cross 2%. I am unfortunately on call or maybe fortunately, thanks to Claude Martin, and my phone lights up. I'm waking up. I'm rubbing, you know, the the soot out of my eyes and, getting ready to go ahead and and start taking care of of this incident. Just gonna go back here. Sorry. There we go. Okay. So here you can see on Tuesday, October 6, previously, I gave Claude Tag the standing responsibility just in the shape that we talked about. Remember for this channel until this point. Otherwise, you know, whenever a meter lane alert fires, go do the root cause analysis, propose a fix, so on and so forth. It has the standing responsibility, in play here. Now today at 11:04PM, meter lane actually triggers that payments API error rate. And we can see that the threshold was 2%, and we're currently at 3.1%. The pager line is fired. It paged me. That's why I'm up. That's why I'm awake. But before I even have a chance to acknowledge the page, before I've even, like, opened up Slack, Claude here is already getting to work. And so we can see that Claude Martin says it's on it. It figured out exactly when the error rate started stepping up, and it's looking at what changed around then. It pulled the error and, the p 99 from meter lane from ten forty to current time. It diffed the last three deploys against GitHub. It checked the feature flags in our flag warden service, and it, ran the resend worker test against the sample batch. And so behind the scenes, even though this looks like just a simple Slack message, there's really a lot going on. It's looking in its channel memory for previous incidents that, match this type of pattern. It's engaging with our meter lane service via its service accounts. It's using the GitHub app to pull the payments API. It's checking our flag warden service with its service accounts again to see what the current status of the feature flags are, and it's actually rerunning the unit tests in the Claude Code remote sandbox. So while it appears like a simple Slack message, there's a whole lot that's actually happening here in the background. So Claude's gonna keep working on this, and it now has, the root cause provided. I still haven't even opened up Slack yet. I'm still rubbing the set out of my eyes. And here we can see that, you know, Claude has determined that the errors have started climbing at ten fifty eight. This is two minutes after this batch resend flag was turned on in our flag service. So the resend worker now has no cap on concurrent sends. So when a batch retries, it's flooding the queue, and the downstream calls time out, figuring out exactly what is causing this issue. Furthermore, because of the way we prompted it with the standing responsibilities, it's showing up with options to solve for it immediately. And it's saying there's a couple things we can do here. We could turn the flag off. This is safe. There's no data loss. This would turn the feature off until someone looks, or we can cap, the max in flight in the resend worker and keep the feature on. Claude also recommends what it would start with for the initial cap, and it says what it would actually go with too. So So Claude is recommending that we go with option two. It's a four line change. The tests are already covering it. Do you want me to open the PR? And then it tags me. So it's done the initial investigation. It's figured out what's going what's going on, and now it's proposing the go forward path, but ultimately looking to me to decide on what the what the corrective action is. I'm gonna go ahead and align with Claude and its recommendation, and I'm gonna say, yes. Let's go with two. We're gonna cap it. I I don't want that feature to go away. Let's keep that feature on. And so Claude gets to work. It pulls the payments API from GitHub. It creates a branch. It goes ahead and writes that four line config change, which we can go ahead and see right here. It marks in its pull request that it writes under its own identity that I was the one who requested it, and it will even link back to the thread in the PR body. And I can go ahead and see exactly what changed. Right? We took away max in flight none, and we're going ahead and we're adding max in flight 16. And so we're updating that that config per per its recommendation. Now I go in and I approve the pull request. I let Claude know. Pull request gets approved, and CI starts taking over. And so as soon as the pull request is approved, the deployment is going underway. Obviously, we have a CI pipeline that's doing the tests and so on and so forth. But now that it's actually deployed and the CI has completed, Claude is proactively deciding that it's gonna watch meter lane and the error rate for a few minutes before it calls it solved. So it's actually taking care of the post incident, like remediation, the timekeeping, and watching for this getting solved to completion. And so here we can see that, ten minutes have passed. We... And we now have the error rate under 0.3% since 11:28. Our p 99 is back to normal. It's gonna go ahead and resolve the incident. It's gonna note for next time that, you know, when when the payments API errors step up, to check the flag warden changes first, and it actually went ahead and drafted the post mort as a Claude AI artifact, which it's shared here and in the on call handoff channel for Monday. So it's also now helping with with on call handoff. And if we crack open the artifact, we see a really beautiful, rich description of exactly what happened in this incident. We have the timeline of events. We have the severity. We have the duration. We have what the fix was, and we have more critically follow ups for us to go and chase back when we're in working hours in the morning. And so this is a really, you know, prime example of how Claude is owning a standing responsibility of being the incident captain, helping me who's on call decide what changes need to be made, and then documenting everything along the way so that, we have kind of a consistent way of showing our incident post marts and making sure that we have kind of a a great visualization for all of the things that that happened. I think one of the most critical takeaways for this demo is to understand how much of the heavy lifting Claude really did here. Claude did the investigation. It was up to me to have the discernment to decide on what the fix was. Once I gave Claude direction, it implemented the fix. I reviewed the fix and made sure that, you know, everything was was clean and that it was solved in the way that we intended it to be solved. And then once I approved the pull request, Claude watched the deploy land, it watched the error rate drop, and it wrote the post mort. So, ultimately, like, Claude did the majority of the legwork here, but I was still involved where it was most critically important. I decided on which fix we wanted to go with, and I ultimately stamped and approved the change that was gonna roll to production. We have customers who are already running this flow. We have a great case study with Carvana where they're seeing 56% fewer alerts in their retail science channel by solving the root causes behind them and that they're getting 65% faster answers for their wholesale platform teams issue and alert triage. There's a great quote from Alex who's the SVP of engineering and analytics over there who says, our teams are using Claudetag to move from a production alert in Slack to investigation, pull request, human review, and ultimately resolution. They are not the only ones, and we do this internally all of the time. It's so powerful to have Claude Tag be on its way on a root cause analysis before human beings even had time to set eyes on it. This really allows you to reduce your your mean time to resolution dramatically, which is obviously really important as you operate, software and production at scale. I think it's also important to highlight that, really, what's happening here too is ultimately, like, yours to define. You get to decide what Claude can reach, what it's... Where it stops, what components of incident response it's responsible for, and all of this is ultimately tunable by you. So you'll be able to set up access to tools, services, and repositories on a per channel level. Your team will set the line on what it's supposed to do and where it needs to hand off to a human being. You know, critically in the, standing responsibility we gave it previously, we said it's on a human being to to merge and and make sure that, you know, like, we ultimately have the discernment in picking which solution we're gonna go ahead and implement. And your repo's review rules and your channel settings are gonna be what kind of enforce those things. And then finally, all of these actions are happening on the record. Because Claude Tag is operating under its own service accounts, under its own identity, you can log in to those those services like Meter Lane or PagerLine and actually see exactly what Claude is doing in those individual services logs. So there's always, you know, a clear answer of of who's done what. Let's talk about the setup that was necessary to kind of achieve the example that we just showcased. So before we get the on call page, we have to set up Claude tag. And and, really, I wanna be clear about exactly, you know, what this looks like. Let's set it up from zero. I'm gonna assume nothing. And that way, when you all go to set this up after this webinar, you'll have kind of a clear picture of what it takes. So, you know, before the on call page, we're gonna go into the Claude tag admin settings. You're gonna need a team or an enterprise plan for this. The owner of that plan, and routines will need to be turned on under capabilities. You also need your Slack admin for at least one step here. The first thing we're gonna do is we're gonna pair Slack. And, essentially, what that does is you add the Claude app to Slack, and then you write this message that you see here, the one that says at Claude connect. When you write at Claude connect inside of Slack, it will spit out a pairing code that you'll then paste here in the admin UI. And once you've gone ahead and done that, you've effectively married your Slack workspace to your Claude enterprise or your Claude team account. The next thing you're gonna go ahead and do is is launch this. You're gonna set up a monthly spend limit. 2,500 is preselected. You'll pick the channels that it joins, and you'll leave the toggle... Leave on the toggle that lets members know that they can tag it. This will basically notify people that claw tag is now available for them. The final step is for you to go ahead and pair GitHub. And so, the setup will offer this right after pairing if you haven't yet installed the Claude GitHub app. And so, you know, you want to make sure that whoever owns your GitHub organization and, you know, whoever is a Claude owner basically gets this connected, so that you can go ahead and pull the repositories and Claude can actually go and do the work that it needs to do to solve for these incidences. Repositories are ultimately bindable per channel, so you don't have to give every single channel every single repository. It's up to your discretion which channels are gonna be allowed to kind of go ahead and, execute against which repositories. And then finally, again, you will have to create service accounts for your tools. For Claude to operate under its own agent identity, you're gonna go... You're gonna have to go ahead and, you know, create API keys, tokens, actual service accounts with, you know, like, a a fake email for Claude, for example. But this really allows, you know, Claude to kind of operate under its own identity. And this is very similar to the type of setup you would do for a new hire. Right? You wanna make sure that you're giving it the narrowest role that covers the work. Read only, in this case, you know, allows it to sign in as Claude, create the API key, pass that API key to the access bundle for its agent identity. And this is why the actions will be showing up, as Claude in the audit log versus a a person. It's Claude who's actually taking the actions here. So once you've gone ahead and you've configured, you know, Claude tag, how do you actually set up incident on call? I wanna get into that as well. So, basically, this is what the on call setup page looks like. You can find this at claw.ai/ on call or, you know, code in claw.ai and then click on call on the sidebar. On team, any member can open this. On enterprise, it needs to be an owner or a Claude tag admin. It's, one on call for the whole organization, and, ultimately, this page is the the setup here. And so the first thing that you're gonna do is you're gonna define where it works, and you're gonna specify, like, what incident channels do you want it to engage in. So here you can see we picked ink alerts. We picked end on call. We've picked deploys. And, critically, if you look down at the bottom, we've also specified channel rules such that it'll pattern match to any incident channel that we stand up. So this allows us to basically make sure that if we're standing up a channel per incident and they're all prefixed with I n c hyphen, that Claude tag is automatically gonna get added. Claude on call is automatically gonna get added so that it can go ahead and and and be the incident commander that we're we're looking we're looking for it to be. You'll also specify exactly what connectors you want Claude, on call to have. And, again, like, the mentality for deciding which tools and context it has access to should always come back to to teammate mentality. If this is gonna be a member of your eng team or your SRE team, you have to think about what tools, what information, what services does it... Does... Do those team members have access to in order to solve for incidences. So you're gonna want it to have your your metering stack, your paging stack, your your your feature flag stack, the code repos. If you have runbooks codified somewhere, you're gonna wanna make sure it has access to those as well. And so really just think about, like, if I was bringing someone brand new on to the team to handle this, what would I need to equip them with? If you have that guiding principle in mind as you set this up, you'll you'll be setting yourself up for success. You'll grant the repositories that you wanted to have access to. And, obviously, this is gonna be up to your discretion for, like, what you want it to be able to operate on. It's important that it has the code bases that are in question for the given channels so that it can actually go ahead and and do the investigation and see what code has changed recently. And, ultimately, because this is Claude code remote running in our infrastructure, you know, you want it to show up with a a pull request that remediates the issue. And so connecting the repos is really important here as well. And then, once you've gone ahead and configured on that, you should be set up. Once all the cards are set, it'll save as you go. You can click done, and that will leave set up, and you can come back and edit at any point in time. If you find that click offs ing your way through this is a little bit, cumbersome and difficult, We actually have Claude in there to help you set up on call. So you can actually go ahead and config... Open up this chat window and have a discussion with Claude about how you solve for incidences at your organization. You know? Like, you can see it's asking, like, when something breaks today, where where does your team hear about it? How does it... How do they get alerts? How do they go ahead and, you know, get the information they need to see how the systems are running? And you can just have this conversation with Claude as you set this up, and it will be able to make recommendations for you as to, like, what you should be wiring up and what you should be connecting. And so we really, like, really love this Claude enables Claude approach, and it'll help you kind of think through what the setup needs to be in order to make sure that Claude can run on call successfully. You know, another really critical part again is making sure that Claude has access to your different apps. And so in this case, we're gonna go ahead and connect meter lane. And you can really get this super fine tuned. So we talked about making a service account. We talked about, you know, creating an API key for Claude, under its own identity, and here's where you're gonna go ahead and and paste that in and connect it. And you can see that there's a lot of different configuration options here. You can specify what hosts it may go to. You can even go ahead and narrow the... Narrow it to read routes, for example, so you can specify, like, what are the path prefixes that you allow for, what are the methods that you want it to be able to do. And so you really have a lot of fine grain controls into exactly how you want Claude to operate under its own identity against the tools and services that your organization employs. Also, if you happen to not be the person who can create a credential for these different tools and services, you can actually go ahead and submit a link to the admins of those services that will allow them to kind of go ahead and provision, get the token minted, and then paste it into, a window that's provided by this link that'll ultimately come and land back in your, in your Claude on call settings. So don't don't feel fearful of having to do all of this on your own. You can delegate to the appropriate service administrators when appropriate. Again, we talked about this, but I think it's important to highlight. It's really common practice for people to create dedicated incident channels per incident. Usually, there's a naming convention for you to kind of go ahead and lean into. And, again, you can go ahead and specify that channel name prefix just to make sure that Claude shows up with with the preconfigured access bundle with all of the tools and context that needs to handle incident on call, and it can go ahead and just jump in, immediately. So, you know, this will happen for any public channels that match. For private channels, you'll have to invite Claude explicitly, and, you know, each joined channel will in... Will inherit that bundle inclusive of the on call connections, repos, skills, and what have you. You can also really, like, tune this to your heart's content. So we talked about the fact that, ultimately, what's happening is, you know, we have a session that's running inside of Claude code remote, and you can actually specify the exact environment or the exact kind of sandbox that you want it to be running in, behind the scenes. So here you can actually see, in the advanced settings, we can specify a a Claude environment for it to run-in. Ultimately, it's an owner who can go ahead and do this, but I just want you to understand that there is this, you know, additional layer of control and tunability available to you all. You can also specify the auto mode allow rules. And so, you know, auto mode is our classifier for allowing Claude code to run automatically. It's the default in the Claude code CLI today. It's also the default for, Claude tag because, ultimately, it's Claude code remote. But you can actually go ahead and kind of specify, rules for the classifier to honor as Claude is going and doing different work. And so all of this is malleable and and configurable by you and your admin so that you guys can basically owning this category of work, when it's driving these incidents through completion, that it's doing so in a way that's aligned with your business requirements and and your best practices. So just know that all of this is here for you as well. You can always be, you know, just asking. And, again, this teammate mentality for both admins and for people that are working with Claude is so critical. Just really, you know, message it like it's a teammate. And so, you know, in this case here, we're basically saying to Claude, like, what can you access? You can also ask it, like, what what do you remember? And you can always just ask Claude what it has access to, what it's able to reach, what it can do. And here's an example of Claude coming back with, here are my connectors, here are the repositories I have, here are the skills that I have configured, and how how each of those are running. And so anytime you have questions against the implementation, against how it's how it's running, it's meant to be transparent. It's meant to be friendly. It's meant to feel like a teammate. So just go ahead and engage with it as such. I think the teammate mentality is super critical when it comes to kind of polishing and tuning and shaping the work that Claude, Claude Tag is doing. If you find that Claude Tag is overly proactive on certain things or you find that it's not exactly, you know, doing work to your standards or that it's, you know, it needs to, do something slightly differently. Just as you would coach and guide a teammate, you'll do the same thing here with claw tag, and you'll tell it, hey. Next time you write an incident post more, we really like to have these KPIs at the top. Or, you know, every time that people are discussing x, y, and z, don't insert yourself automatically. Like, let the human beings have the discussion and tag you in once they're done. And so you can basically, in natural language, just coach and tune the way that Claude Tag is, behaving. And so keep that in mind. It's really flexible. It's really smart. It's going to remember... Going back to its memory system, it's gonna remember the guidance that you give it, and it'll honor, honor things that are critically important. So keep that in mind. So, you know, after we've gotten all the configuration set up for on call, we have to go back and set that standing responsibility. Right? And we talked about this in the beginning, the the common core elements that are necessary for a good standing responsibility. We're gonna time box it. Even if it's indefinite, we wanna make that explicit that it's indefinite. We wanna give it a trigger to respond to. We wanna tell it what to do once it is triggered. We want to tell it what its boundaries are and make sure that it doesn't overstep, And we wanna make sure that it knows what to do once the, once the job is complete, how should it put a bow on it. And so, this is something that you can, you know, write here in a Slack message again. You can put this in channel settings. You can put this in a skill, and you can always go and edit it. It's not set in stone. And because Claude Tag is ultimately this multiplayer experience, everyone in the channel can actually go ahead and shape this work over time, which is really, really nice. It it really gives Claude the feeling of this teammate that kind of improves over time as it ramps and it learns what different people care about and how how the team wants it to be performing its its assigned task. You know, these one off asks will grow into on call jobs that Claude owns and remembers, and I'll showcase some of these. I really like spending a a moment on this slide when I present this to customers because I think it's really important, you know, not just for incident on call, but for Claude tag as a whole. There's so many different ways to engage with this product, and, they... You know, there's there's varying levels of kind of, usage here. And so I wanna start here at the top. You can use this like chat. You can use this like code and Cowork, and you can ask it to do a single task. That's completely viable. You can still do that. The value starts compounding when you start moving down here into these more advanced usages. And so let's talk about routines. So routines are not net new to Claude Tag. They've been available in Cowork for a while. They've been available in, you know, Claude Code. But the power of doing them in tag is that the channel owns them instead of an individual. Prior to Claude Tag, I would run, you know, eight or so routines on behalf of my team. And anytime those routines needed to get augmented, I was a single point of failure. I was a bottleneck. I had to be... You know, I was on the hook for basically making the changes that the team wanted to see. Once Claude tag came around here at Anthropic, I was able to kill all of my personal routines, restart them in our team channel, and now everyone on the team has the freedom and flexibility to kinda tune these routines. And that that in in and of itself is really powerful. Standing responsibilities is obviously the one that we've really leaned into here today. You know, owning on call is a standing responsibility. There are plenty of other standing responsibilities that can be configured. Again, that whenever x do y pattern is universal and applicable across different business units and segments. So just keep it in mind that, like, you are all empowered now to recruit Claude into a given channel and to not just give it a single task to do, but to give it a a category of tasks. And so it's really, really powerful. And I think this concept of standing responsibilities is is one of the most differentiating pieces of value, compared to all of the other products that we've released at Anthropic thus far. And then finally, you know, it has this really sophisticated memory system, which we've touched on a few times. It's really good at remembering. You know, oftentimes, Slack is the most real time representation of, your business. And so, for Claude to be kind of acting on all the information there, it's it's really great. There's a whole lot of on call jobs that Claude Tack can own. We showed first response to alerts. We showed drafting the postmortem. It can also chase the follow ups. It can triage new incidences. It can run the weekly handoffs between the on call, staff. It can quiet noisy alerts. It can figure out, like, which alerts have been, you know, noisy over time and call them. It can catch up whoever is joining an incident mid flight. It can go ahead and, you know, routine... On a routine, check the dashboards and see how the health of the business and how the health of the systems are running. And even more critically, as it's handling these incidences, it can actually keep the runbooks that you have all written current, and it can keep them up to date over time. And so it's really, really powerful across all of these different things. To start off this week, we would recommend configuring claud tag and on call, throwing it in one incident channel with one repo or a couple depending on how your architecture is set up. Give it the monitoring tool it needs. Give it a standing instruction and see how it behaves. Don't feel the need to boil the ocean and get this configured for all incidences across your business on day one. Start small, cut your teeth, build your muscle memory, and then from there on, you know, go ahead and, expand from there. Thank you so much. I know that there's some questions in the chat, so I'm gonna pop back over, to Q&A and answer some of the questions that we have here. So let me go open up that panel. Let's see here. How does usage billing work? Is it separate than how per user usage billing works? That's a phenomenal question, Nathan. So the way that billing works today is that any action that, Claude is taking under its own agent identity is built to the or... Billed to the organization. So it's not by user in that case. If you're DMing Claude Tag, if you're talking to Claude in the DMs, that will actually be, you know, Claude, billing against your own user account. But, ultimately, admins can set spend caps at the organizational level as well as a per channel level. And so it's up to them to kind of set the limits that that Claude Tag will be operating under. That was a phenomenal question. How is Claude on call different from Claude Tag working with skill files as Git? It's it's not different from Claude Tag. Ultimately, on call is just a permutation of what Claudetag is. It is a pattern that we have seen a lot of customers adopt and one that we use internally, but it's it's not a completely separate different product. It's just a way of setting up Claudetag for a very high value task. How does Claude Tag maintain long term memory and preserve task continuity? Wow. I love this question. So, the memory system here is super sophisticated as I've mentioned. And, ultimately, what's happening is Claude Tag in every public channel is commingling memories together. So all the public channels share a, like, commingled memory sphere. As such as channels are contributing memories, Claude is able to basically mark where the memories come from so it doesn't lose the thread or the plot on, like, where did it remember these things from. And then, you know, the next question becomes, like, how does this behave in a private channel? Claude tag in a private channel will be able to read from that public channel memory sphere, that commingled memory sphere, but it will exclusively write to a private channel memory node that's one to one with that channel, which it can read from as well. And this makes sure that if someone brings Claude Tag into an HR channel where people are discussing payroll information, for instance, that that payroll information never leaks into the public channel memory sphere. All of this is kind of built off of our prior art of things like auto memory and auto dream, and so it's really smart about knowing, like, when one memory actually, you know, one new piece of information implicates changing the memory of another of another place. I have found this this product to be so incredible with respect to memory management. And in fact, it's actually why we do not offer ZDR for Claude Tag today. It it candidly requires this type of memory system in order for it to be effective. You can imagine if you, you know, brought someone onto your team that couldn't remember anything, it'd be difficult to work with. So it's the it's the same same thing... Same situation here. Talked about that. Is memory functional? Ryan, you got it. Yeah. Memory's out of the box. There's nothing for you to configure. It's designed in a way where you should never have to think about it. You can, of course, crack it open and see what's in the memory files and so on and so forth, but it is really truly designed for it to be handled automatically. For the API threshold example you provided, can you give us a sense of how many tokens it used from initial trigger to post mortem actions? I mean, this is super dependent on model. This is dependent on the repository. This is dependent on the event. So, it's never gonna be like, oh, it's ballpark this many tokens. You can do things to reduce the, the amount of variance, let's say. Obviously, you know, models are probabilistic. They're going to infer, you know, how they get from point a to point b, but you can do things like give models skills that'll at least narrow the possibilities of ways that it can get from point a to point b. That's a really great way of helping it control cost and making sure that things are happening in a consistent pattern. So really great question. Does it work with Grafana and Azure Log? Yep. Anything with an MCP? Anything that you can create a service account for? Yep. Claude works across channels. Any... Oh, Ryan. Ryan, you're you're crushing it, man. You're answering these faster than I can read them. But, yeah, ultimately, Claude Tag is... You know, you can configure it with really any tool you can create a service account or an MCP connector for. I know we're a little bit over, but I wanna thank you all for joining me today for all things Claudetag and OnCall. I hope you have a great experience leveraging it. Thank you.