Speaker A
Hello everyone. How are you? Good. Okay. Amazing. Welcome to the last workshop session of the day. I hope you have all enjoyed the very first day of Code with Claude. My name is Maya.
Learn how to build proactive agent workflows using Claude Code's new routines feature for automation and improved productivity.
Key Takeaways
- Routines transform Claude Code from a reactive tool into a proactive coding teammate.
- Managed infrastructure eliminates the need for users to handle hosting and session persistence.
- Customizable triggers allow flexible automation based on schedules or events.
- Interactive sessions provide transparency and control over agent workflows.
- Automating repetitive tasks like documentation can significantly improve team productivity.
Summary
- Introduction to building proactive agent workflows with Claude Code by Maya from Anthropic.
- Challenges of running proactive agents locally, including infrastructure, hosting, and session management.
- Explanation of the new 'routines' feature in Claude Code that automates remote agent sessions with triggers and connectors.
- Routines run on managed infrastructure, removing the need for users to maintain hosting or session state.
- Agents can be triggered by time-based schedules, GitHub events, or custom webhook events.
- Routines sessions are interactive and steerable, allowing users to monitor, steer, and resume sessions via web, CLI, or desktop.
- Internal use case: automating documentation creation at Anthropic to handle increased PR volume.
- Demonstration of setting up a routine in the terminal with scheduling and notification options.
- Key decisions when creating routines include trigger timing, required context, and actions to perform.
- Encouragement to identify daily tasks that could benefit from automation using Claude Code routines.
Full Transcript — Download SRT & Markdown
Speaker A
I'm a member of our applied AI team here at Anthropic. What that means is I spend about half my time developing our own first-party products and features and the other half of my time helping customers develop their very own
Speaker A
products, features, agents on top of our models. Today I'm here to talk to you about how to build a proactive agent workflow with Cloud Code. Can I get a show of hands? Who has used our routines feature
Speaker A
inside of Cloud Code? All right, some folks over here. Awesome. Awesome. That's what I'm going to be talking about today. Okay, so first off, a question for the group here. Who has tried to run Cloud Code on a cron? Can
Speaker A
I get a show of hands? Folks, put your hands up high. Awesome. Awesome. Now keep your hands up if you've enjoyed building all of that infra and maintaining that job. All right, we have one guy back there. We have one guy.
Speaker A
Thank you. Thank you for your effort. Thank you for your work. We felt similar pain internally at Anthropic as we tried to develop proactive agents that run on Cloud Code. And we decided to do something about it.
Speaker A
So, we believe that coding agents shouldn't wait for you to press enter to get started. Right now, Claude Code is a really powerful coding tool, but we want to take Claude Code and turn it into a really powerful coding teammate.
Speaker A
A teammate notices when something breaks and does something about it. Right now, a tool waits for you to enter your prompt and actually press enter.
Speaker A
So the goal of today's presentation is to talk about how we have created this feature called routines to take Cloud Code from a tool today into the teammate of tomorrow.
Speaker A
So today we'll be talking about four things. I'll go through some of the challenges that you folks have felt building proactive agents today. I'll go through this new feature inside of Cloud Code called routines.
Speaker A
We'll go through a real example about how we use routines internally at Anthropic to automate documentation creation and then finally we'll talk about applying routines to your own workflows.
Speaker A
So I want to talk first through the challenges with building proactive agents today. We all know it's doable.
Speaker A
But I want to talk about what's a little bit cumbersome with this.
Speaker A
The first thing that's a little bit difficult with building proactive agents today is deciding where these agents should run. You probably don't want them running on your local machine because if you close your laptop or your laptop dies, your agent session is done. What
Speaker A
that means is you'll need to manage things like hosting, data persistence, and authentication. Basically, you'll need to build a whole infrastructure outside of your prompts, which is doable, but it's a lot of work and there's a lot of boilerplate code
Speaker A
there. The next thing you'll need to do is figure out when to actually kick off these sessions and trigger these agents.
Speaker A
Again, you can build things and build on top of cron or you can do things like post to endpoints that you have to spin up. But again, there's a lot of infra that you need to build yourself
Speaker A
here. Finally, the challenge with building proactive agents today is sometimes you want to be a human in the loop, but other times you want to be a human out of the loop with these agents. Right now when you kick off a headless Cloud
Speaker A
Code session, it's often hard to figure out what your agent is actually doing in real time. There's no way to watch, steer, bound, or even resume your agent session. It's difficult to do that.
Speaker A
So we wanted to address each of these three issues and build routines. Routines is a brand new feature inside of Cloud Code. It's an automation where you can kick off a remote Claude Code session by only
Speaker A
defining the prompt, what repos you want to connect it to, what connectors it has available to work with, and a trigger.
Speaker A
Claude Code handles the rest. So there were three kind of main things we were thinking about as we went ahead and developed this routines feature inside of Cloud Code.
Speaker A
The first thing is that we wanted these agents to be always available. These agents, these routines run on Claude Code's managed infrastructure. And what's nice with that is that we deal with the hosting, the session state, and the connector off for you. Nothing
Speaker A
depends on your laptop being opened and we deal with all of the cloud stuff for you, which I think is quite nice. The next thing is we want these agents to be able to work proactively with customizable triggers. You might want to
Speaker A
kick them off on a time-based schedule or you might want to work event-based.
Speaker A
We have the ability to work natively with GitHub events as well as your own custom events that you can post to webhooks and endpoints with the event payload as context.
Speaker A
Finally, and the last point that I think is really nice is that these Cloud Code sessions that get launched with these routines are interactive and steerable as if you were launching Claude Code in the terminal. Every routine is really just a Claude Code
Speaker A
session under the hood that you can open, you can watch, follow up on, steer, and resume from web, CLI, and desktop.
Speaker A
And so I want to walk you guys through a real use case that we use here at Anthropic internally. So the question for us and for a member of our engineering team is how can we automate docs creation with routines?
Speaker A
So, just to add a little bit of data behind this, weekly PRs for Claude Code have gone up 200% since the beginning of the new year. This has been super awesome for our Claude Code engineering team. Their productivity is insane.
Speaker A
This has been really awesome for you folks because you get new features inside of Claude Code very, very quickly.
Speaker A
The one person that this has not been so awesome for is the one engineer responsible for maintaining our documentation across Cloud Code and the agent SDK. And so when routines launched, she was a super big fan and early adopter. And I want to walk you
Speaker A
through how she set up a couple routines to help automate documentation creation for Cloud Code and our Cloud Agent SDK.
Speaker A
So on my side here, I have the terminal open. And I encourage you all to open your terminal and launch Cloud Code.
Speaker A
And inside of the terminal here, I'm able to type what we see on the screen here, slash schedule, and actually type in something that Sarah, our documentation queen, has done to actually set up this routine. So she
Speaker A
went and typed in once a week, please review all the new changes merged to main against our documentation repo and create a PR to update docs if you see any changes.
Speaker A
I encourage you folks to think right now what are some tasks that you do every day that would help if they could run on a schedule or if Claude could actually initiate these sessions for you. I encourage you to think about that.
Speaker A
After kicking this off inside of Claude Code, Claude comes back and prompts me with a couple questions. It might ask, "Hey Maya, at what time every week do you want me to actually kick this off?" Or once I create a PR, do you want me to
Speaker A
notify you in any way? Maybe ping you on Slack. And once I answer these questions, Claude actually goes ahead and creates a routine that we'll view in a little bit inside of Claude Code on the web.
Speaker A
But first, I want to walk through the three main decisions you'll need to make as you create any routine. The first decision is you'll need to figure out when your routine should trigger.
Speaker A
What's actually the event or is there a certain cadence that you want this to run?
Speaker A
The second decision is what context or what information does Claude need to have to actually be successful here? Do you need access to certain docs or does Claude need access to certain tools to ping you?
Speaker A
Finally, the last thing to think about is how do you actua
Speaker A
these and I'll talk through how Sarah, a member uh of our team, actually does this to automate documentation creation.
Speaker A
So the first one is the trigger. When uh should this event actually run? So inside of routines, there's basically two ways to do this. You can have things kick off on a schedule on a timebased trigger.
Speaker A
For that earlier example I showed you, uh this is how we do a weekly review of differences between our source code for cloud code as well as our documentation repo.
Speaker A
You can also have routines kick off uh on an event-based cadence. So maybe every time a release is cut, uh you can diff the release branch against the docs and see if there's any new features that you'll need to spin up PRs for in our
Speaker A
documentation repo. Or maybe your engineer is actually deploying uh changes and creating PRs might tag their changes. Maybe this is like a new feature. They could tag it with a label that says need docs. And you could actually kick off clawed code
Speaker A
sessions anytime one of these uh labeled PRs get merged. The next thing you'll need to think about is context.
Speaker A
What does your agent actually need to know to be successful? Likely you'll need to give it access to either one or more codebase repos. So for this docs example, uh we need to give Claude access to not only our
Speaker A
claude code source code to figure out what new changes exist there, but also our docs repo, right? For claude to actually create uh new PRs there.
Speaker A
Next, you might want to provide additional context to these sessions. Uh maybe for this one example, I want Claude to have access to all of our existing marketing briefs. Maybe I want Claude to use similar language and verbiage that we use uh in other
Speaker A
marketing materials externally at Enthropic. So maybe all of this lives inside of Google Drive and I'll want to give Claude access to these files during the session. So I'll hook up the drive connector.
Speaker A
Or maybe anytime Claude creates a PR, um I'll actually want it to ping me on Slack. Uh so I'll give it access to the Slack connector. It's important to think about this as you're setting up the routine because whatever context Claude
Speaker A
has, that's uh the ceiling of how successful Claude will be. Finally, the last thing to think about here is steerability.
Speaker A
How do we actually ensure the quality um of Claude's outputs? There are a couple ways to do this. Um, one thing that I think is quite interesting is to actually invest in agent onagent review. If folks have actually designed multi- aent systems
Speaker A
here and have heard of the generator uh critique pattern, uh this is something that we've borrowed here. You can actually set up one routine to go ahead and create uh docs PRs and you can set up another routine that maybe triggers
Speaker A
on that PR's creation um to actually go ahead and leave comments on the PR before a human actually gets to it.
Speaker A
Another option we had emphasized it's nice to have a human out of the loop, but sometimes you actually do need to monitor these cloud code sessions and maybe nudge Claude in a different direction. What's really nice and what
Speaker A
I'll show you in a second is that you can actually open Claude Code on the web and you can view what's happening inside of a live session as if you would working with Claude in the terminal. You can ask it questions midsession. You can
Speaker A
push it in another another direction. You you can also resume a past routine or a past session and continue the conversation.
Speaker A
Finally, the last thing we do and what I think is quite obvious is that we verify Claude's outputs. For this documentation example, we actually render the page that or the documentation page that Claude has changed and created and we
Speaker A
confirm those outputs are what we expect. And so now I'll jump back into that initial routine that we've kicked off here in this demo. Um, and we'll jump to the demo slides. Awesome. And so we can see right now I'm in cloud.ai AI and I
Speaker A
can go over to this left side panel and actually kick click on this uh code button and I can jump into routines on this left hand side and I can actually click on this routine that I had created
Speaker A
earlier. On the left hand side here you can see that it's connected to two repositories.
Speaker A
our uh mocked up Cloud Code source code as well as our Cloud Code documentation.
Speaker A
You can see that this runs every Monday at 10 a.m. and it's connected to GitHub as well as Slack.
Speaker A
These instructions here on the right hand side Claude generated for me based on the initial prompt that I pasted in and the questions that I answered. We can see here that uh this is a a weekly documentation sync uh for our claude
Speaker A
code fork. And I can actually go ahead and click on a session here. And I can see that these initial instructions are what uh gets pasted in for the very beginning of this Claude code session.
Speaker A
We can see that Claude has read these instructions and started by looking at the source code repository to see uh any changes, any recent PRs that have been merged. Looked at our change log and compared that to what's inside of the
Speaker A
documentation repo. We can see Claude's actually found some changes here and gone ahead and opened a PR for me.
Speaker A
This is one example where you can kick off a routine on a schedule. Now I want to show you another example where we can actually kick off a routine uh based on a GitHub event. So here I've actually created a new routine and I've
Speaker A
already filled some of this in. Um I want to make uh another documentation automation uh routine and but this time I want this to actually trigger every time I create a new GitHub issue.
Speaker A
So I pasted in some instructions here basically to investigate the issue that this session triggers on. Figure out if it's related to a documentation gap and then if it is and if you believe that this is a gap um go ahead open a PR and
Speaker A
actually ping me in this channel. So I've gone ahead and connected our cloud code documentation repo as well as our source code again. And I want to show you how I actually set up this trigger.
Speaker A
Like I had mentioned before, there's two different types of triggers. Um, schedulebased and event based. And within event-based triggers, we have native git github events supported here as well as the ability to trigger from your own code by sending a post request.
Speaker A
So here I'll create a uh GitHub event trigger and trigger on issue opens anytime I open an issue inside of this cloud code documentation repo. And I want this connected to Slack so I can send me a ping anytime I make a PR um as
Speaker A
well as our GitHub MCP. So I will go ahead and create this here. And now let's make sure that this is working. So I have a new issue open here that I'm about to create inside of our Cloud Code Docs repo. Um so I happen to
Speaker A
know that there are a few few tools missing from docs in this new version.
Speaker A
So I'm going to go ahead and actually create this So I can see here that I've gone ahead and created that. And now let's refresh this page.
Speaker A
And we can see actually that a new run has gotten picked up here. We can see that these initial instructions are the very first prompt. Um and we can see that this additional context from this issuer passed in as well.
Speaker A
I happen to know that I actually already have another PR open for this. So, let me just guide Claude to stop this session.
Speaker A
I've already made these changes and we can see here the ability to actually steer Claude in real time after routine gets kicked off.
Speaker A
Awesome. Um, now let's come back and talk about the different ways uh that we can use routines to actually automate your challenges. As uh developers, I want to talk through um a couple ways that we could turn common software
Speaker A
engineering or developer challenges into routines with quad code. The first one I want to talk through is this deploy verifier. Um maybe you have recently uh just deployed changes to an to a service and you want to make sure
Speaker A
that this service is healthy and you shouldn't roll back these changes. I want to think about this uh in three ways. First, what should my trigger be here? Second, what context is important to provide to Claude in this routine?
Speaker A
And lastly, how do I plan to actually interact or steer this routine to keep Claude honest?
Speaker A
I happen to know that my CD pipeline can post after every deploy. So, this seems like a pretty good trigger to actually kick off this routine on. I can actually post to this uh web hook that we support
Speaker A
inside of routines. And this can actually kick off my Claude code session. In terms of what context I think is important to provide Claude here, I can think of a couple things. one, it's probably nice to give Claude access to
Speaker A
the source code for the service that we reach recently deployed on. Next, it's probably important to give Claude access to monitoring tools. Maybe that's data dog, maybe that's Graphana, I don't know what you folks use, but um likely helpful to give Claude access to
Speaker A
these uh monitoring tools. And maybe if something goes down, I want Claude to alert me. I want Claude to ping me on Slack or send me an email um or maybe maybe even send me a text using Twilio
Speaker A
or something like that. These are some of the connectors or the tools that I would give Claude access to inside of this session.
Speaker A
In terms of keeping Claude honest or actually steering my session, maybe I'd start by having Claude run an investigation for me and giving me an eventual no go or no-go decision to actually roll back this change. I could
Speaker A
jump into Claude code on the web and actually view and read Claude's analysis for this session. Then maybe I can continue to work with Claude if I actually think that this should be rolled back and actually use Claude to
Speaker A
help me roll back a change. Maybe eventually as I watch Claude work more and more and trust its decisions, I can let Claude roll back the change itself if based on the monitoring monitoring uh data it has access to. Uh
Speaker A
if I deem that that's the right decision. There are other challenges like maybe you want to build an on call investigator or maybe you're actually a PM and your job is to go through uh a lot a lot of issues inside of your
Speaker A
backlog. Maybe that's GitHub issues. Maybe that's posts inside of a Slack channel and maybe you want to kick off a weekly job that actually reads through all of these issues. Um maybe it's kicked off on a timebased trigger. You
Speaker A
give it access to GitHub and Slack and wherever your issues live. Um, and you use Claude to actually help you prioritize and maybe open PRs for the most important issues. Okay, my final takeaways here, uh, proactive agents, uh, beat reactive agents. We want Claw
Speaker A
to go from a tool to a teammate. Um, you can move from an agent that is waiting for you to actually press enter and create a PR to an agent that reacts to problems um, and opens a PR itself.
Speaker A
We built routines so you don't have to focus on maintaining all of this infra, but instead you can actually concentrate on your domain and process expertise.
Speaker A
This is what routines handle for you. And finally, I encourage you to get started with routines today. Uh you're a single slashcchedule command uh inside of Claude Code uh away from creating your very first routine.
Speaker A
Awesome. Thanks so much,
Topics:Claude Codeproactive agentsautomationroutines featureAnthropicagent workflowcloud infrastructureinteractive sessionsdocumentation automationdeveloper tools
