From Primitives to Production: How Anthropic Builds Agents

Summary

This video from Anthropic's applied AI team explains how LLMs have evolved from simple single-model inference to autonomous agent loops where the model decides its own trajectory, and introduces the core primitives—code execution, web search, and file access—that underpin all agent capabilities.
The Claude Agent SDK enables modular agent design through Skills that prevent context pollution by loading task-specific instructions only when relevant, sub-agents for parallel workstreams and scope isolation, and MCP for external service connections.
Security is enforced through deterministic hooks for human-in-loop approvals and sandboxed isolated execution environments, while evals function as essential unit tests providing objective quality measurements; a live demo shows an SRE agent resolving a PagerDuty alert and publishing a postmortem to Confluence end to end.

From Primitives to Production: How Anthropic Builds Agents

Recorded at: Agentic + AI Observability Meetup | SF | April 9, 2026
Speaker: Isabella He (Member of Technical Staff, Anthropic)
Session: Skills and Security
Large Language Models (LLMs) are evolving from simple "tokens in/out" processors into autonomous agents. this video breaks down the engineering principles and frameworks used at Anthropic to build agents capable of navigating complex environments without human-encoded logic.
The talk highlights the transition from orchestrated workflows to modern agentic systems, featuring tools like Claude Code and the Claude Agent SDK.
Key Takeaways:
-Anthropic defines an agent as an LLM placed in a loop with a specific goal and a set of tools.
-Effective agents are built using core primitives like code execution and web search that apply across any domain.
-Developers use modular "Skills" to prevent context pollution by loading instructions only when relevant.
-Systems utilize the Model Context Protocol (MCP) for external connections and sub-agents for parallel workstreams.
-Security is managed through hooks for human approvals and restricted sandboxing environments.
-Evals function as essential unit tests to provide objective measurements of agent quality.
-Managed infrastructure abstracts the complexities of deployment so developers can focus on core logic.
0:00 — Evolution of LLMs
2:45 — Defining an Agent
3:15 — How Claude Code Works
5:50 — The Claude Agent SDK
6:58 — Utilizing Agent Skills
8:50 — Benefits of Sub-Agents
11:10 — Governance and Safety Hooks
13:56 — Evaluation with Evals
16:48 — Site Reliability Engineer (SRE) Agent Demo
24:01 — Introduction to Managed Agents
Check out future Agentic + AI Observability events: https://luma.com/AgenticAIObservability

Chapters

FAQs

How does Anthropic define an agent?

Anthropic defines an agent as a large language model placed in a loop with a specific goal and a set of tools, where the model decides its own next steps rather than following a deterministically encoded workflow. This is a meaningful distinction from earlier LLM orchestration patterns where human-written code directed the model's path through a workflow. The combination of goal, loop, and tools enables agents to navigate complex environments and complete multi-step tasks autonomously.

What are Agent Skills and why do they help prevent context pollution?

Agent Skills are reusable, modular instruction packages that load into the agent's context only when relevant to the current task, avoiding the context bloat that occurs when all possible instructions are loaded upfront. Large context windows filled with irrelevant instructions dilute the model's attention and can degrade performance on the task at hand. This video explains how Anthropic uses Skills to keep agents focused and efficient as the range of tasks they handle grows.

What security mechanisms does Anthropic use to govern agent behavior?

Anthropic uses deterministic hooks—code-level checkpoints that fire before certain agent actions—to require human approval for sensitive operations such as file writes or external API calls. Sandboxed execution environments ensure that agent code runs in isolated containers that cannot access unauthorized resources or affect production systems. This video argues that these deterministic controls are essential because relying on the model itself to refuse dangerous actions is insufficient for production security.

What does the SRE agent demo in this video show?

The demo shows an agent built on Anthropic's agent SDK that automates a site reliability engineering workflow: it detects a PagerDuty alert, diagnoses the issue, implements a fix, and publishes a postmortem document to Confluence—all without human intervention at each step. This end-to-end example illustrates how primitives, Skills, and sub-agent architecture compose into a real operational agent. The demo is designed to show the full pipeline from trigger to resolution as a practical reference for agent builders.

Full transcript

[00:01] Agents in anthropic are actually very simply defined where essentially you want to give the model and lean in on model intelligence
[00:13] today we think about as having essentially a task that you give it then you give it the same core primitives things
[00:31] excited to be here and talk about essentially Anthropics position and point of view on how to build agents. All right, so for today's agenda, the main thing that I want to leave everyone with is hopefully just speedrun exactly how anthropics thinks about agents, how we build agents internally, how we
[00:44] govern and build effective agents, leverage evals, and also show you a quick demo at the end of an actual agent built on our anthropic perspective on our agent SDK. A little bit of quick introduction. My name is Isabella. I'm on our applied AI team at Enthropic.
[00:56] Essentially what this means is that I spend about half my time working internally. So I've contributed to claude code designer news/init experience if you've seen that out in beta testing. I work on context engineering. So things like compaction
[01:08] and tool result clearing. But I spend the other half of my time working with our customers. So I work personally with a mixture of our big tech and startup customers and essentially work to see how we can help them stay on the frontier and leverage claude in their
[01:20] models and build agents effectively within different domains as well. So let me go ahead and jump in into exactly how Enthropic looks at agents around as we're evolving from different models. As we've seen, LLMs have progressed very
[01:32] significantly and rapidly in the past couple of years. I'm sure a lot of you might know this chart already, but if we think back to first when the initial LLM started coming out, a lot of them were single LM features. So essentially
[01:44] tokens in and then tokens out. And then we move to more of a workflow state where LLMs are essentially orchestrated by code. This was a little bit more complex where you essentially take the input of one LLM, you run some logic of
[01:56] it, bring it to another LLM and you chain together different LLM calls orchestrated by code. But this was still very deterministic relying on human encoded logic to guide LLMs around where they were going. But as we have seen
[02:08] models get more and more capable, that brings us to what we think about as agents at Enthropic, which is really where LLMs are actually deciding their own trajectories. So instead of a workflow style approach where you're encoding exactly where the LLM is going
[02:21] to go, agents actually essentially are able to look at complex environments, look at the tools it has at its disposal and essentially work in a loop in order to uh strive towards a particular goal
[02:34] without deterministic elements encoded in. So essentially just to break this down, I think there are a lot of different definitions of agents as you all might have experienced as well, but at anthropic we kind of think about agents very very simply. Essentially
[02:46] what an agent is is it is a large language model. It is then put into a loop. It uses tools at its disposal and it has a particular goal that it's optimizing towards. So if you look here, agents in anthropic are actually very
[02:59] simply defined where essentially you want to give the model and lean in on model intelligence as much as possible and give the model the ability to change its own trajectory based on the information that it acquires. And then at anthropic we've written a lot of
[03:11] agent loops. So specifically, one of our most popular agents is Cloud Code. For those of you who love cloud code, you might have experienced the power of cloud code already with how cloud code essentially leans on our cloud models to
[03:23] essentially enable developers to achieve tasks that they might never have achieved before. Cloud code, working and running cloud code for hours on end. Can I get a quick raise of hands? How many people here have used cloud code personally? Okay, lots of hands raised.
[03:37] Um, if we actually talk really quickly about what cloud code looks like under the hood, I want to just quickly touch base on exactly actually how cloud code works. Essentially, cloud code has access to about 14 or 15 tools, things
[03:49] like bash, edit, grap, glob. And these are actually tools that you all have at your disposal in your terminal as developer as well. What a lot of agents did before cloud code was essentially semantic search over a particular file,
[04:01] which is looking for things like keyword phrasing, and you had to feed it a specific file to edit. But cloud code instead essentially has the same set of tools that you have access to as a developer. So if it wants to search for a particular file to edit, you don't
[04:13] have to tell it exactly which file to edit. You can run cloud code on a codebase that is millions or hundreds of millions lines of code. And essentially cloud code will use list, gp, glob bash commands to navigate the codebase just as you as a developer would. And then as
[04:25] we see models get more and more intelligent, what we see is an evolution in how we think about agents in general. I think a couple of months maybe around a year ago we thought about agents as needing very specialized domains across
[04:37] different expertise areas. So you had like a specialized coding agent that might be a cloud code. We used to think you might need almost an entire new harness for something like a research agent or a customer service agent or a site reliability agent. But as we all
[04:50] might have seen just across different model launches, they're also coming out quicker and quicker. You see this progress accelerating. Where we are now is that with every new model that we see, we can unlock a whole new set of capabilities. So instead of breaking
[05:02] down agents by domain, we actually see that it's more effective if we just think about agents as this really almost general purpose but with essentially access to different tools that you can then tailor to specific domains. So
[05:14] agents today we think about as having essentially a task that you give it. Then you give it the same core primitives, things like code execution, file system, web search, to-do lists. You put it into a loop and you can almost think about the power of cloud
[05:27] code powering agents in any domain. So claude code could power a customer support agent. It could power an instant response agent. It could power domains essentially beyond code but running the same core primitives of cloud code
[05:39] giving claude an access to a computer. So now let's go ahead and get tactical. I want to everyone to hopefully leave with just a little bit of a playbook of if you were to leave this room, how would you actually go and build agents? Um specifically the way that for instance claude code is built today. The
[05:52] Claude agent SDK is a product that we offer at Enthropic. It is essentially the same building blocks as cloud code, but allows you to put in your custom tools and custom system prompts and custom skills and essentially leverage
[06:04] the power of cloud code for any agent that you might be building for your own domain. So, this involves things like system prompt, skill, tool descriptions, hooks and guardrails that you can customize. And I want to just break down a couple of these specifically to talk about how you can leverage the cloud
[06:17] agent SDK and cloud code, but specifically for agents that y'all may be building yourself. So if you think about essentially if we take the harness that is cloud code, if we take the ability to essentially execute tools, use a computer, what is actually missing
[06:29] between just running cloud code versus a very purpose-built agent that you might build, let's say a finance or an audit agent. The key thing that is actually missing is domain expertise and context engineering is something that I've spent
[06:41] a lot of time on atropic and it's a huge part of just making agents effective beyond just running a general purpose cloud code and really making it tailored to specific use cases. Now, there are variety of different ways in order to leverage context and leverage domain
[06:54] expertise. One of them, something that we're very excited about, Enthropic is something called agent skills. Skills are essentially almost like just packaged instructions that you can give to Claude. And the key thing here is
[07:06] that they're progressively loaded. So, essentially, if you think about a system prompt, if you're designing, let's say, a customer support agent, you might tell the agent, hey, you know, you're in charge of doing XYZ things. Customer members might say this, you're
[07:18] responsible in answering these types of questions. But maybe you have a specific type of question that a customer support bot has to answer, which is for instance starting a new ticket for a customer. You don't actually want the instructions
[07:30] about how to open a new ticket for that customer injected into your system prompt because that would pollute the context and that would let you read those useless instructions for a customer asking any other question into that system prompt instruction on every single prompt to cla. Instead, what
[07:44] skills let you do is essentially have those instructions only loaded in when it's relevant to the prompt. So only when the customer says, "Hey, I want to open this new ticket." That's when that skill is invoked in. And Claude can read those instructions into context. Skills
[07:57] can also include scripts and executable files on top of instructions. So, one good example of this that I like to give is our open source PowerPoint skill, which essentially other than instructing Claude how to create PowerPoints, it
[08:09] actually also has scripts to edit the actual PowerPoint files itself. And it's just an effective way when you essentially want instructions and scripts and templates given to Claude on progressive enclosion disclosure as
[08:21] well. The other elements here in terms of all different ways you can give Claude context other than skills, we also have MCPs. So MCPs are essentially our default way to talk to external systems. Of course, you can also leverage skills essentially to run
[08:34] scripts or bash commands or CLI commands to also talk to external systems. But MCP is our open standard for how you can leverage essentially existing and approved external integrations to things like Google Drive and Slack and
[08:47] essentially connect your agent to different external systems as well. Sub agents is another way of essentially giving your agent very specific domain context and also is a very powerful lever for context engineering. Sub
[08:59] agents are something that I like to talk about as just essentially a way to kick off a parallel workstream for claude but also have their own context window. You might imagine that this is useful let's say if you're designing an agent that
[09:11] essentially maybe it's a finance agent and you're looking through essentially a really really large context of a really large document. You might launch a bunch of different sub aents to read different aspects of the document. They can each write, you know, their kind of own
[09:23] vendetta of writing summaries of that portion of the document, then report back to a main agent. What this does, it essentially prevents the main agent from having to read in that entire document into context. It makes sense so that the sub agents are responsible for their own
[09:36] portion of their world and can essentially report back to the main agent. We also see a very effective pattern where you can kind of couple different sub aents with different models. Um so the cloud code default sub agent for the explore mode is a haik
[09:48] coup sub aent. So the haiku will kind of come in and explore different aspects of the codebase and then report back to maybe a more intelligent model like a opus or sonnet. Now this is something that our team is actively working on. We merged custom/comands and skills
[10:00] recently if any of you have seen it but um I know there's some confusion around hey when do I use a skill versus MCP versus sub agent. I would think about it essentially as thinking about skills whenever you want procedural knowledge
[10:12] that you always want to persist and you want to call on. Another example I like to give is our front-end design skill at Claude Code, which essentially whenever Claude does front-end design work, it can invoke a front-end design skill to make Claude better at frontend design.
[10:24] That's like a repeatable workflow that you essentially want to inject additional instructions into Claude. MCP servers are kind of the maybe the first place you think when you think about integrating with an external system. There's some cases where it might be
[10:36] more effective to do this as a script or a skill, but MCPs are really actionable when you want to essentially take action in an external system. Now, sub agents here, I think you can use them as sort of specialized worker agents, but the main thing is just for parallel
[10:49] exploration and also fresh context windows. Now I want to talk a little bit about governance, security and observability which I know is a hot topic for just today overall because we don't want to design and deploy AI agents that are not secure and that is a
[11:01] huge point that we also emphasize in anthropic. Um safety is really really important to us and that's something that we encode into the model itself but also design primitives around. So the first one here is hooks. Hooks are
[11:13] essentially a way so that you can secure the tool calls that an agent is going to make. You could imagine let's say if an agent is trying to run a like remove RF command that can be something that you can guard against with sandboxing and
[11:25] with hooks. Hooks can also essentially allow you to enforce human in the loop. So for instance, if you want an agent to call out for human approval before running a command like writing to a certain system. Let's say you're writing to a Salesforce system or writing to a
[11:38] Jira ticket. before that command is actually able to execute or before that tool can execute, you can put a pre-tool use hook on it to make sure that the agent is asking for permission deterministically every single time. So
[11:50] hooks are essentially a way for you to inject a little bit of determinism into your agent, otherwise letting the kind of the model decide its own trajectory and be flexible and be dynamic. But hooks are a way to add some of those guardrails back into the system. The
[12:02] other element here is permissions. Permissions we think about a lot as well with our agent SDK and this is something that you might have also seen in cloud code. We recently announced an auto mode as well in cloud code. That is my pro tip for the day if you haven't seen it
[12:14] already. I haven't seen a permission prompt in a long time just using the auto mode in cloud code. Um but permissions are something that you want to think a lot about as well because we of course want to govern agents to make sure they're not taking actions that a human wouldn't want. The first place
[12:27] that agents um go for permissions in the cloud agent SDK is to hooks. So that's that layer I talked about where we can enforce human in loop. You can also make sure that you're just adding like rules of what the agent is not allowed to do
[12:39] when to ask for permission. You can essentially think about it almost as the same way for cloud code agents where you want to essentially do like allow edits or if you want to make sure that cloud code is asking for permission every single time. The other element here is
[12:51] sandboxing. And I think this is something that I also really recommend looking into for anyone looking into how to design a secure agent. And essentially what a sandbox is is we want to give an agent sort of the free realm to reduce permission prompts and also
[13:03] execute commands within an existing environment. But anytime the agent tries to exit that sandbox environment, run a command that it's not allowed to or access a network that it's not supposed to access, that's when a permission prompt is triggered. So there's native
[13:16] sandboxing built into cloud code that's also extensible to the cloud agent SDK. So, we've talked a little bit about how the cloud agent SDK is kind of built on cloud code, but one point that I think I really want to make is just the way we think about agents and anthropic both
[13:28] with the agent SDK and with our new manage agents that we just released is that a lot of these core primitives actually do translate really well across domains. So, you think about like a contract review agent, they may also access the file system. They're reading
[13:40] in a contract just instead of a codebase. And then they execute a lot of the same model logic but with custom skills, custom prompts, and custom tooling to make it tailored to that domain. Next thing that I want to talk about a little bit here is just to make
[13:52] sure now that we've discussed a little bit about how to build an agent is how to make sure that the agent is actually executing the capabilities that you want it and how you can actually evaluate the effectiveness and capabilities of your agent. And that is where evals come in.
[14:05] And eval is something that I talk a lot about with the different teams I work with just because I feel like a lot of times people are just behind on building evals with how quickly agents are evolving and models are evolving. But eval are actually a really really
[14:17] important way of helping you stay on that path of model progression. And that is because without evals, let's say a new model comes out, you have your existing agent, you have your existing prompts and your existing tooling. You don't know objectively in a quick way to
[14:29] test if a new model put into your system is actually going to help you achieve new capabilities. But with evals, essentially what you can do is define a test a set of use cases. They're almost like unit tests, but for built for agents and built for dynamic paths. And
[14:42] say you're building like a customer support agent, you can essentially run evals to check if that response given to the customer is actually something that is high quality both on the response content itself and on the style. And eval
[14:55] signal over the things that you're building. So here is the anthropic agents playbook. And I know I went through everything a little bit quickly just cuz I want to leave time for a demo if we can get to it. I think the various elements here are essentially giving an
[15:07] agent agentic frameworks that are actually leveraging the power of the model. I think a lot of other frameworks that exist, I think usually I think the danger here is when the frameworks themselves become too workflow based or don't give the model the capability to
[15:19] actually execute the tools that it needs. This is just because if you think about agents as a proxy for how we at humans think about solving tasks, you wouldn't want a human to be essentially be restricted in how much it can do. If I didn't have access to all the
[15:31] different tools at my disposal, like all the different commands inside of a terminal, then I wouldn't be able to be as effective of a developer and actually be able to solve a problem by leveraging all the different tools and skills and materials that I have at my disposal. So
[15:44] that is a really really huge part of just making sure your agentic framework is well levered to capture that model intelligence. The other aspects here are essentially it's really really powerful when you give your agent access to a computer. That's kind of what makes
[15:56] claude code magical just because claude code can actually come in and access different elements of your computer and why we saw so many people nontechnical users using cloud code as their primary entry point to claude before we release co-work just because claude can kind of
[16:08] do so much more when you just give it access to everything that you have going on on your computer and the same kind of works for different agents in different domains as well. The next part here, domain expertise is where I think a lot of builders focus on today. That's
[16:21] where, you know, at anthropic, we can only build so many agents, but there's infinite amount of domains to tackle in the world. And that's where custom agent skills, tools, and system prompts come in. And the last part here is eval, which is just a quick reminder that as
[16:33] you're building agents, evals are a huge part to make sure that you're actually checking the capabilities of the agent and figuring out where the agent is falling and where it's succeeding in your prompts and systems today. All right, so now I'm going to jump ahead to
[16:45] a demo. And the demo that I'll be showing today is essentially a site reliability engineer, an agent that can actually come in here and debug things when your production cases fall, when you're seeing error spike. Um, bit of a risky demo, so everyone can cross their
[16:58] fingers and hope that the agent is actually able to debug the incident. Um, but just to set the stage here, I'm sure with the technical audience we have today, a lot of you are familiar with this. But the pain point that the agent is trying to solve is that for
[17:11] engineers, half their life is spent on building new features. They, you know, have exciting new features come out, are advancing the product capabilities, but the other half of their time is actually spent on debugging production instance.
[17:24] Whenever a new feature is launched, this means that you might be on call again. You might be, you know, woken up at 2 a.m. and you have to come in and look at an incident that has been raised. You need to wake up from your bed, come in and triage and investigate. And another
[17:37] huge pain point is that maybe once you're done with all this investigation, you actually also have to go and write a post-mortem about it. So again, just very painful steps and is a huge pain point that we're going to try to automate away with our agent. And if we
[17:49] think about everything that we talked about previously in this talk so far, we talked about skills, we talked about cloud code, we talked about tools and MCP servers, the site reliability engineer actually maps really well to all those components that we talked
[18:02] about. So if we think about what exactly is going to happen for this agent under the hood, the agent is going to come in and receive an event. Then it's going to run inside of this core loop in the cloud agent SDK. It has access to cloud code. So it can actually access your
[18:14] codebase and debug things live within your codebase. Then it has skills for things like runbook adherence. So runbooks being like, hey, previously when you saw this similar incident, what are the steps you took to debug it? The agent is going to be able to read those
[18:26] skills in as well as like say how to write a postmortem. It also has all these MCPs to access all these external systems and do things like ingest logs just as how you as a human developer would be able to look up things like Kubernetes and look up things like your
[18:39] observability to debug what's going wrong with the agent. Okay, so we have here is a sample codebase here. You can see we have different elements and we have an API server environment. What we're going to do here is actually break this agent. Don't worry, there's only kind of one important element which is
[18:52] this database pool size. So here what we're going to do is we're going to break this um codebase. We're going to actually drop that database pool size down to one. Essentially, what we're doing here is we're making it so that there aren't enough resources to allocate to this codebase. And then
[19:06] we're going to come in um actually before I do that, let me just go ahead and flip. You can see here that we're logging all the 500 errors that we're calling. And let me come in and just redeploy this on Docker. In fact,
[19:19] this might take a second here. Okay, there we go. Hopefully in a second here we're going to see the errors start to spike. We're waiting for the metrics to pick up a little bit here. Um the
[19:31] graph that you're looking at is essentially just a log of all the 500 errors that you're seeing. So here we just saw that big spike that just happened because we're no longer allocating enough database pool resources. So therefore we're seeing a lot of spikes that the user is then
[19:43] going to experience because the service is going to be down. So now if we actually then flip over, usually again what the engineer is going to have to do at this point is they might get woken up by a page duty call. they have to wake up at 3:00 a.m. and come manually debug.
[19:55] But instead, what we're going to do is we're going to hand this off to the SR bot. So, let me just go ahead and type this in. Okay, so as you can see here, we've told the SR bot that the 500 errors are spiking and for them to create an incident. Of course, we could do a little bit more here. We could actually have this just automatically
[20:08] polling for incidents. So, we don't even have to come in and tag the bot. But for purpose of this demo, it's just also a little bit more illustrative here that we're going to come in and create an instant and keep the human in the loop. For those of you who might be able to see here, page duty is actually calling
[20:20] me right now. Let's see. It's kind of an annoying sound. >> You have one triggered incident on S agent demo. The failure is 500. >> Okay. So, as you can imagine, that's not a super pleasant noise to wake up to
[20:33] when you're woken up in the middle of the night. But thankfully, we have the SR bot. So, let's go ahead and just say yes. It's going to come in and start to kick off an investigation to find the root cause of my 500 spikes. You can see
[20:46] here that the bot is kind of reacting to my messages as well, which is also something that I think I would recommend just I know like you know latency is a huge concern for a lot of agents that people are building. But there are ways to leverage just response streaming as
[20:58] well as acknowledgement of an agent working on it that we can leverage also to pull on for threads like latency. And you can actually see here that the agent has pretty quickly determined that the user service is the culprit here that's actually causing the spikes. And it has
[21:11] come in and investigated everything here. It's found that hey, we deployed this here and it identified that the database pool size is the reason why this error is occurring. So, let's go ahead and say yes to this fix. But what
[21:23] I'm going to do is I'm going to open up the codebase side by side here. Okay. And this is kind of the risky part of the demo so everyone can hold their breath. But before I kick this off, I
[21:36] want everyone to keep their eyes on this line here. The database pool size equals to one. And what we're hoping for here is that the agent is actually going to come in and edit the codebase for us. And I think the key thing here is that I
[21:48] think right access or agents taking actions can feel pretty dangerous sometimes. But the important thing is just to add the appropriate guard rails around the agent. And you can see here that when this just went up to 20, that is kind of the power that we can unlock
[22:00] when we give agents access to the tools at its disposal. And it's actually not going to just stop there. the agent is going to come in and redeploy the server and make sure and verify its own work so that it actually can make sure it solved
[22:12] the issue effectively. So if we keep our eye on this graph here, we can see that now that we have resolved this issue, the 500 errors are going back down. The service is back up. Yay. So the agent has helped us avoid
[22:26] this incident response needed from a human and handed this off to an agent. You can also see here now that the agent has offered to resolve the pager of duty for me and also create an postmortem. And again, this is another part of the
[22:39] element here. Usually for an on call engineer, it doesn't end when you resolve the incident. Now, you have to come in and write a postmortem so your team can actually know what you did and encode this for future practices. We're actually going to see here some of the power of those MCP server connections
[22:52] come in as well because our postmortm postmortem is going to be created inside of Jira or Confluence, which is where our team keeps all of our postmortems today. Okay, looks like the postmortem is getting published and the agent is
[23:04] also resolving the pager duty incident. And we can see here if we just open this up here, let's come in and open up the postmortem. There we go. We see the postmortem here. It talks about
[23:16] the pedag duty incident that happens, the timelines, the root cause it documented, the remediation steps, and the action items as well. And again, this postmortem here is actually a skill, which means that the Claude agent is not going to read instructions about
[23:29] the postmortem into a system prompt until I actually say as a user that I want it to execute and kick off a postmortem for me. That means that we can make this postmortem skill instruction more detailed and encode things about like how you want your action items detailed. You can even
[23:42] include a template for the postmortem or if you want things really deterministic, you can have a script where you're, you know, deterministically injecting things into Jira or wherever your postmortems live for your team. So that's kind of the power of skills as well, which is that we're able to save on context by
[23:55] not having these repeatable knowledges added to the system prompt every single time we call cloud. All right, so just to end us off here, um, manage agents is something that we really recently released, I think today or maybe yesterday. Um, just want to show a quick
[24:08] video of it just because everything that we talked about today is on the cloud agent SDK and just generally how we think about agents at Enthropic. But manage agents is our very new product which essentially allows you to kind of abstract away all the work that we
[24:20] didn't talk about today which is deployment and hosting of an agent. Usually that's a huge bottleneck especially when you think about giving claude access to a computer or file system just because that is where you actually really start to think about how
[24:32] do you make sure everything is containerized and make sure that the access to computer is safe and deployed in a virtual machine and that is kind of the work that manage agents abstracts away for teams building agents today. All right, so that's all I have for you
[24:44] today, but cloud manage agents, you can see, has some more like observability and built-in capabilities just to make sure your agent is running. It kind of breaks things down more by session and environments rather than how you might think about agents as being very very
[24:56] decomposed via like our messages API for instance. So you can think about managing agents as just the environment you give to the agent and the sessions that you run on the agent. So encourage everyone to think about if you're building an agent from scratch, you're just prototyping something new, test out
[25:08] the manage agent and see where you can get with it as well.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.