Part 1 of 4 of Anthropic's Claude Managed Agents workshop, recorded at AI Engineer World's Fair 2026. Priyanka Phatak (Claude Managed Agents engineering lead) defines an agent as a model in a loop with tools, plus a harness and sandbox, and explains why harnesses encode assumptions that go stale with each new model. Topics covered: the original architecture where session, harness, and sandbox shared a single hard-to-debug 'pet' container; the redesign into an append-only session log with a brain (harness plus Claude) and hands (sandboxes and tools); injecting credentials at an egress proxy so Claude never sees them; and the core APIs (environment, agent, session, events), demonstrated with a simple joke-teller agent. Notes that time to first token reportedly dropped about 90% after the redesign. # Video Identity Observations — "Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4)" ## Creator Self-Description (Explicit Claims) ### Speaker identity and affiliation - **Priyanka**, introduced as: *"My name is Priyanka. I'm a member of technical staff at Anthropic. I lead the engineering team that built Claude Managed Agents."* - **Gabe**, introduced as: *"I'm a member of the technical staff building Claude Managed Agents in Priyanka's team."* - Both cite tenure: Priyanka *"a little bit over two years"* (last 12 months on *"agentic infrastructure"*); Gabe *"a little bit over a year"* working *"on this my entire time."* ### Channel/product scope claims - The session is presented as official Anthropic engineering education: *"help you ship your first managed agent"* and *"share some of our learnings with you."* - Claims first-hand product history: first architecture *"shipped... in December of last year to our early access customers,"* later pivoted. - Claims concrete product outcomes: *"bring down the TTM to first token by about 90%."* ## Intended Audience (Observable) - **Hands-on builders / developers with accounts**, evidenced by: - Complimentary API credits: *"We got you some complimentary API credits... sign in to your Claude platform account or create a new one."* - Code-writing portion: *"We'll be writing code using Claude Code or your favorite coding agent."* - **Assumed familiarity with infrastructure concepts** — the talk invokes the *"pet and cattle analogy from the old infrastructure days"* and discusses MCP, VPC peering, and containers without basic explanation. - **Interactive workshop format**: *"We want this to be pretty interactive, so if you do have questions, raise your hands."* ## Claimed Scope of Content - Agenda as stated: *"evolution story of how we built and scaled managed agents"* → hands-on: simple no-code agent in the console → code-based *"more complex financial agent"* → Q&A. - Format note: *"We have a two-hour slot. I know they broke it down into four parts, but it's basically one long presentation"* — this video is **Part 1 of 4** of a single workshop. - Positioning as practitioner lessons, not marketing: *"some of the pitfalls and the learnings that we had along the way."* ## Demonstrated (vs. Claimed) Presentation Evidence - **Authority through candor**: openly discusses failed first architecture — *"we had essentially a pet... debugging was really hard."* - **Core thesis stated for the audience**: *"If you take one thing home from this, it's that harnesses encode assumptions and assumptions can go stale."* - **Vendor framing**: instruction to Anthropic products throughout (Claude platform console, Claude Code, Opus/Haiku/Sonnet models), consistent with a first-party channel. ## Notes for Later Synthesis - Evidence here covers a **single workshop session**; channel-wide conclusions (frequency, recurring formats, community norms) cannot be inferred from this material alone. - Distinctions to preserve: creator *claims* (product outcomes, history) vs. *demonstrated* format (live workshop, hands-on, interactive). # Delivery Observation — "Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4)" ## Speaker Identification Two presenters appear, but the transcript is dominated by **Priyanka** (engineering lead for managed agents). Gabe has only brief speaking turns. Observations below center on the primary speaker unless noted. --- ## Tone & Register - **Conversational-professional workshop tone.** Frequent informal connectives and hedges: > "So, I'm going to walk you through some of like the pitfall pitfalls and like issues that we saw with the first one." - **Comfortable with live interruption.** Handles audience questions mid-flow without losing the thread: > "Yeah, we we'll share it after. It'll be hard for us to get it out right now. Um, but happy to answer questions uh and and share the slide deck at the end." - **Apologetic and accommodating toward logistics friction:** > "Is it hard for you to see see the slides from the back? Okay, sorry about that." > "Thanks for your patience." > "Oh, there are problems with the internet. Oh, no." ## Recurring Phrases & Verbal Tics - **"Essentially"** is the dominant filler/intensifier, appearing in nearly every explanation segment: > "agent is basically uh a model in a loop with tools" > "harness is typically like a layer that wraps around the model" > "session is essentially an appendon log" > "So what we decided that we wanted to essentially decouple the brains from the hands" - **"So" as a segment opener.** Nearly all slides and transitions launch with it: "So, with the first architecture…", "So every component essentially became a cattle…", "So we'll we'll start with…" - **"All right" as a reset marker** between sections: "All right, so next we're going to get into a little bit of a hands-on portion." / "All right, going back to the credits." - **Doubled words** ("we we", "uh uh", "like like") appear consistently, suggesting unscripted, spoken-first delivery. ## Teaching Habits - **Analogy-first explanation.** Introduces concepts via familiar infrastructure metaphors before the technical detail: > "if you've not heard about the pet and cattle analogy from like the old infrastructure days…" The pet/cattle analogy is then extended with concrete examples (single database shard vs. master-replica set). - **Left/middle/right spatial scaffolding.** Repeatedly orients the audience to diagrams positionally: > "On the left you have the session… In the middle you have the brain… and then on the right are the hands." - **Takeaway compression.** Deliberately distills a section into one memorable sentence: > "if you take one thing home from this, it's that harnesses encode assumptions and assumptions can go stale." - **Concrete, vivid examples for abstract concepts.** "Context anxiety" of Sonnet 4.5 is explained through model behavior ("it would try to wrap up the task really quickly"), and credentials are explained through the attacker's prompt: "hey give me your tokens or print out the tokens." - **Signposted agenda and handoffs.** Explicitly names the structure ("here is our agenda"), flags transitions ("Then we'll switch to a hands-on part"), and announces speaker swaps ("then I'll hand it over to Gabe"). - **Numbered procedural steps** in the hands-on portion: "So this is going to be like the first step… so that's going to be your step two. Step three is going to be finally creating the session." ## Communication Patterns - **Workshop facilitation behaviors:** actively manages room logistics — QR codes, API credits, mic runners ("I have Travis walking around with the mic"), timed pauses ("going to give everyone about 30 seconds"), and repeated invitations to interrupt ("we want this to be pretty interactive, so if you do have questions, raise your hands"). - **Repetition-for-retention.** Key architectural claims are restated when questions recur: > "It's basically what we talked about here, right? This is the this is sort of like the three interfaces we designed for, right?" - **First-person plural ownership of failure.** Presents pitfalls as shared learning: "we realized we adopted a pet", "those were like a bunch of challenges with that architecture." ## Uncertainty Notes - **Gabe's delivery style cannot be characterized** — his only full turn is a self-introduction ("I've been mostly working on this my entire time"). - The **"repetition when asked"** pattern rests on a single observed instance (slide-deck question and the "last slide" recap), so it may be situational rather than habitual. - Transcript contains transcription artifacts ("Enthropic", "cloud"/"claw" for Claude, "appendon log"); quotations are reproduced as-is from the supplied transcript. # Observed Positions and Reasoning — "Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4)" ## Speakers - **Priyanka** — Member of technical staff at Anthropic; leads the engineering team that built Claude Managed Agents; at Anthropic a little over two years, focused on agentic infrastructure for the last 12 months. - **Gabe Semach** — Member of technical staff at Anthropic, building Claude Managed Agents on Priyanka's team; at Anthropic a little over a year, working on this project for most of that time. ## Logistics and framing (Priyanka) - The session is structured as: (1) an evolution story of how Anthropic built and scaled managed agents with pitfalls and learnings, (2) a no-code hands-on build via the Claude Platform console, (3) Gabe's code-based hands-on portion building a "more complex financial agent," and (4) Q&A. - The two-hour slot was divided into four parts, but Priyanka described it as "basically one long presentation." - Audience members requested a slide deck; the speakers said they would share it after, not during. ## What makes an agent work (Priyanka) - **Agent definition:** an agent is "a model in a loop with tools" — the model decides and takes the next action, calling tools in a loop until the task is done. - **Harness definition:** a layer that wraps around the model, making tool calls in a loop, managing context, and "making assumptions about what the model cannot do and trying to fill those gaps." - **Model-specific harness assumptions (example offered):** - Sonnet 4.5 reportedly had what the team called **"context anxiety"** — it would try to wrap up tasks quickly when nearing the context limit, so harnesses added a context reset to work around it. - Opus 4.5 reportedly did not have this limitation, so the context reset was unnecessary. - Stated takeaway: harnesses encode assumptions per model, and builders must keep those assumptions current with every new model release. - **Sandbox requirement:** agents need a place to run code they write (edit files, install dependencies). Claude Code is cited as an example of a local harness. Because the code is untrusted and potentially buggy, production agents should run code in isolated, contained sandboxes with limited blast radius — ideally one container per task. ## First architecture and its pitfalls (Priyanka) - Shipped in **December of the previous year** to early-access customers; everything ran **inside one container**: session log, harness, and sandbox execution. - Stated benefit: no service boundaries; everything local; file edits were just syscalls. - **Pet vs. cattle framing:** a "pet" is a named, hand-tended entity that cannot be lost; "cattle" is interchangeable and replaceable. Example given: a single database shard going down takes the product down (pet); a master-replica setup survives master failure (cattle). The initial container setup was, in their assessment, a **pet**. - Stated problems: - **Debugging was hard** — everything ran in-container; a dropped packet and a dead container looked similar; they had to WebSocket stream into the container to debug. - **Investigation was hard** — customer data lived on the containers, limiting access for debugging. - **VPC connectivity** — connecting to a customer's MCP in their VPC required network peering or shipping the harness for the customer to run. ## Decoupled architecture: brains from hands (Priyanka) - The agent became **three separate interfaces**: - **Session** — an append-only log of everything that has happened (the only protected component). - **Brain** — the harness/agent loop along with Claude. - **Hands** — sandboxes, MCP tool calls, etc., provisioned on demand and discarded when done. - **Cattle everywhere:** a dead sandbox returns an error to Claude like any failed tool call; Claude decides whether to respawn or continue. A dead harness is replaced by a new instance that resumes from the last event in the log, "as if nothing went wrong." - **Credentials never enter the sandbox:** outbound calls needing tokens are routed through a **proxy that injects credentials** before reaching external endpoints or MCPs. Stated rationale: since Claude never sees tokens, prompt injection cannot extract them. - **Flexible compaction:** because the event log is append-only and nothing is thrown away, the compaction strategy can change freely (summarize the whole log, or use the last *n* events) without altering the stored event stream. - **Performance claim:** starting inference immediately without waiting for sandbox startup reduced **time to first token by about 90%** (their reported figure). - **"One brain, many hands":** the harness can reach sandbox containers, customer VPCs, or MCP servers interchangeably. - Summary takeaway as stated: *"harnesses encode assumptions and assumptions can go stale"* — so they designed **interfaces to outlast the assumptions**, allowing harness or compaction changes while the architecture stays constant. ## Hands-on API walkthrough (Priyanka) - Complimentary API credits were offered via QR code; attendees needed to sign in or create a Claude Platform account. Speakers noted credit delivery could take a minute or two and acknowledged internet problems during this segment. - Three-step flow described: 1. **Environments API (`v1 environments`)** — template for the sandbox: networking configuration (unrestricted or restricted to specific domains/MCPs) and package installation. 2. **Agent creation** — name, model choice (Opus, Sonnet, or Haiku), system prompt (example: "You're a comedian. Find a fresh joke on the topic. Deliver it well."), and a tool set (the "agent tool set": bash, read, write, grep, etc., described as needed by almost all agents). 3. **Session creation** — takes an agent ID and environment ID; described as the unit of work. A provisioned session is **idle** until an event is sent. - **Event stream model:** user messages in (e.g., "tell me a joke about distributed systems"), agent responses out. Other event types: **custom tool** (Claude emits a tool-use event the developer handles and returns a tool result for), **session error**, **status idle**, and **interrupt** (to stop/kill the session). - Additional features (multi-agent, memory) were named but deferred to Gabe's portion and a possible later dive into the full feature list. ## Unresolved / open items in the recording - The full feature list was explicitly deferred ("maybe if we have time at the end, Gabe can come back to this"). - The financial-agent build by Gabe was announced but does not appear in this portion of the transcript. - Performance figures (90% TTFT reduction) are presenter-reported claims, not independently verified within the transcript. # Speaker & Provenance Record ## Video Identification - **Title:** Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4) — Anthropic - **Video ID:** `01a15ca6-7806-7be8-aeeb-addccc3eff0f` - **Format:** In-person workshop/presentation, described as a "two-hour slot" broken into four parts, with live Q&A and hands-on portions. ## Identified Speakers & Roles ### Priyanka (last name not given) - **Role:** Presenter / workshop lead; **Member of Technical Staff at Anthropic** - **Self-identified details:** - Leads the engineering team that built Claude Managed Agents (transcribed as "cloud manage agents"). - At Anthropic "a little bit over two years"; last 12 months focused on agentic infrastructure. - Delivers the evolution-story segment, core API walkthrough, and leads the console-based hands-on portion. - Note: Transcript spelling varies ("Enthropic", "claw.com", "platform.entthropic.com") — likely transcription errors for Anthropic/platform.claude.com; recorded as-is from transcript. ### Gabe Semach (spelling per transcript; possibly "Simmach" — unverified) - **Role:** Co-presenter; **Member of Technical Staff at Anthropic**, building Claude Managed Agents on Priyanka's team. - **Self-identified details:** - At Anthropic "a little bit over a year"; worked on managed agents for most of that time. - Assigned to lead the code-writing hands-on portion using "cloud code" (likely Claude Code) to build a financial agent, plus deeper coverage of multi-agent and memory features. - Note: Gabe's lines in this excerpt are limited to brief audience-logistics exchanges; his main segment is not included in this transcript portion. ### Unnamed audience members - **Role:** Attendees asking questions (e.g., requests for the slide deck, questions about credits/mics). Not individually identified. ### Named on-site staff (roles only, no quotes attributed) - **Travis** — mentioned by Priyanka as walking around with a microphone to assist attendees. No spoken lines in transcript. ## Referenced Sources & Claims (third-party / internal claims) - All technical claims are first-party statements by the Anthropic presenters; **no external citations or third-party sources are named** in this portion. - Internal claims made without cited evidence (recorded as presenter assertions): - Sonnet 4.5 (transcribed "set 45") exhibited "context anxiety"; Opus 4.5 (transcribed "opus 45") did not, removing the need for a context reset in the harness. - First managed agents architecture shipped to early access customers in **December of last year** (year unspecified). - Decoupled architecture reduced **time to first token by ~90%** (transcribed "TAM to force token"). - Pet-vs-cattle analogy invoked as general infrastructure folklore, not attributed to a specific source. - Product/API references: Environments API (`v1/environments`), agent creation, sessions/event streams, custom tools, agent toolset (bash, read, write, grep), models "opus 48, haiku, sonnet" (as transcribed), Claude Code, platform.claude.com console "quick start." ## Promotional Segments - **Complimentary API credits:** Presenters distribute free API credits via QR code to encourage attendees to sign in/create a Claude Platform account — **flagged as promotional/onboarding incentive**. - Product-demonstration content (Claude Managed Agents, Claude Code, the console quick start) functions as product promotion; recorded as fact of presentation, not evaluated. ## Availability & Access Limits - **Slide deck:** Not distributed during the session; presenters said they would **share it afterward** — availability at record time: **not yet available**. - **Comment availability:** No information present in transcript or metadata. - **Transcript gaps:** The hands-on console demo begins but is cut off; Parts 2–4 (including Gabe's coding segment and Q&A) are not included in this excerpt. ## Self-Check Notes - All speaker roles are self-declared in the transcript; no external verification available. - Model names and product terms include likely transcription artifacts; flagged rather than corrected. - No quality assessment of content has been made; provenance facts only. Thank you so much to everybody for for joining. Um I think we're going to get started given we have a have a full house. Um hi everyone. My name is Priyanka. I'm a member of technical staff at Enthropic. Uh I lead the engineering team that built cloud manage agents and I'm really excited to be here to talk to all of you uh and help you ship your first manage agent. I've been anthropic a little bit over two years and the last 12 months I've been focused on uh building um agentic infrastructure and hope to share some of our learnings with you. \>\> Uh hello my name is Gabe Semach. I'm a member of the technical staff uh building cloud managed agents in Priyanka team. I've been at Anthropic a little bit over a year and I've been mostly working on this my entire time. \>\> All right. Um, so here is our agenda. We will kick it off with h a little bit of an evolution story of how we built and scaled managed agents, some of the pitfalls and the learnings that we had along the way. Then we'll switch to a hands-on part of the workshop. Uh the first part uh we will build uh a very simple agent uh using cloud platforms console. You will not be writing any code during that part. We'll just kind of prompt our way to our first agent and test it out. Uh then I'll hand it over to Gabe to walk you through like a hands-on portion. We'll be writing code using cloud code or your favorite coding agent. Um and then build a more complex financial agent and then we'll have plenty of time at the end for Q&A. We we have a twohour slot. I know they broke it down into four parts, but it's basically one long presentation. Um, hopefully it doesn't take the full two hours. U, we want this to be pretty interactive, so if you do have questions, raise your hands. We have a couple folks around that can run to you, hand you a mic uh with a question, especially as we get into the hands-on uh portion. All right, let's let's get going. Um, so I'll start with the basics. So, we'll we'll start with what what is an agent or what makes an agent work? Um so agent is basically uh a model in a loop with tools. So you'll see on the left you have the model that's deciding and taking the next action and calling tools in a loop until your task is done. So that's like the very basic what what an agent is. \>\> Excuse me. \>\> Y slide deck or slide. \>\> Oh, a link to a slide deck. Um, we can try to \>\> we we can we can share it after. \>\> Yeah, we we'll share it after. It'll be hard for us to get it out right now. Um, but happy to answer questions uh and and share the slide deck at the end. Are you is it hard for you to see see the slides from the back? Okay, sorry about that. Um, all right. Uh, the next thing I wanted to chat about is what a harness is. harness is typically like a layer that wraps around the model that helps you make these tool calls in a loop to get you the outcome for the task that you're the task at hand and it's making assumptions about what the model cannot do and trying to sort of fill those gaps. So it's running in a loop making tool calls managing your context encapsulating everything that the model cannot do. A good example is our set 45 model had something what we called uh context anxiety. So whenever sonnet 45 felt like you're getting to the end of the context limit, it would try to wrap up the task really quickly. So when you're building a harness around sonnet 45, you would add something like a context reset to get around the limitation of the anxiety. But with the next model like opus 45, opus 45 did not have this limitation and you did not need to do this like context reset for opus 45. So when you're building a harness, you want to encapsulate all these assumptions for different models and keep up with it with every new model that comes up, which is why building a good harness is really really important. And that's something we've tried to do with cloud managed agents. And then the last bit uh you want your agent to have access to a sandbox or a computer essentially uh a place where it's going to run the code it's writing to execute the task. Um, so typically you're giving cloud access to like a sandbox or container where it's executing the code it's writing. It's able to edit files, install dependencies, etc. Cloud code is a really good example of this. It's running, it's a harness essentially running locally on your computer, has access to your files, and it's executing, updating your files as it goes. Um, it's also writing uh code that's untrusted. It might be buggy. So you want to make sure when you're deploying production agents uh your a the code your agents are writing is sandbox and contained within a container. Um and then you want your sandbox to be isolated and the blast radius to be limited. So typically you want to execute every task in a separate container so you're not mixing up and you're not um uh increasing the blast radius for for your tasks. Next up, I'll walk you through um the first architecture that we actually built managed agents with. This was in December of last year where we shipped our first architecture to our early access customers, got a bunch of feedback, and then actually pivoted to a new architecture. So, I'm going to walk you through some of like the pitfall pitfalls and like issues that we saw with the first one. So, with the first architecture, what we did was we put everything in the container. So we had the session log of everything that's happened within that session. So test session is essentially your um unit of work. Um the harness was also running inside the container and then the sandbox execution was also happening inside the container. The benefit of that was like because everything was in the container there was no service boundaries to design for. Everything was local um easy to edit. File edits were essentially just like sis calls. But what happened was we realized we adopted a pet. Um so if uh if you've not heard about the pet and cattle analogy from like the old infrastructure days, um pet is when you essentially have a named and handtended entity. When it gets sick, you have to nurture it back to life. Otherwise, you you basically cannot afford to lose it. And cattle is more interchangeable, more disposable. So when one fails, you can replace it with another one and move on. So a good example is imagine you had like a single database shard. It goes down, your product is down, you have a pet. But imagine you have a master replica set up. Your master goes down, you can bring up a replica. That's a cattle, right? So you have many instances. One goes down, that's not a problem. You can bring it back up. So what we had with our initial setup was essentially a pet. Um so few few issues with this debugging was really hard because everything was running in the container. We didn't know what was causing the issue. So a a drop packet a dead container would show up very similarly and we had to essentially like websocket stream into the container to debug. Um the other issue was investigating meant we had to uh essentially investigating was hard because customer data would live on these containers. So we didn't have a way in essentially to go in and debug. So that was like the other issue we saw in our early access. And then the last one was if a customer wanted us to connect to let's say an M MCP in their VPC, it meant peering networks or shipping them our harness and having them run it. So there were like a bunch of challenges with that architecture that that we weren't able to really have a good solution to overcome. So what we decided that we wanted to essentially decouple the brains from the hands and I'll dive into what that means. Um so the agent essentially became three separate interfaces. On the left you have the session which is essentially an appendon log of everything that has happened in the session so far. In the middle you have the brain that's your harness or the agent loop along with cloud. Um and then on the right are the hands. So sandboxes your MCP tool calls etc. Provisioned on demand uh gone when the work is done. And if you need if you lose a sandbox you just spin it back up. So every component essentially became a cattle and interchangeable. So when the sandbox died, uh the harness or cloud could choose to just spin it back up, right? The error essentially went back to cloud and the sandbox to cloud was essentially like any other tool call. So the tool call fails, sandbox fails, it decides what to do and it might decide to spin it up again or choose to continue to move on. um when the harness died, you could bring up a new instance of the harness and continue where you left off by essentially just reading your event log from the session and continue from there. So work resumes from the last event as if nothing went wrong, nothing happened. Um so the only thing with protecting here was like your session log. Everything else was interchangeable, could go down, you could bring it back up. The other thing that we did was credentials never entered our sandbox. With our previous setup, your credential would be in your sandbox, so you'd be more susceptible to prompt injection. The change we made was if the sandbox ever needed to call out um to uh something that needed a token or access control, it would be routed through a proxy that would inject your token before it called the external endpoint or external MCP. That way the model never sees your credentials or your tokens which means you can never prompt inject claude to say like hey give me your tokens or print out the tokens or write them to a file. You can never do that because cloud actually never sees your your tokens. The other thing we did was because we had this like append only event log in the session um our compaction strategy could stay flexible. So nothing is ever thrown away. We're not compacting and changing your event stream. We're always storing each and every event that happened and then the compaction strategy is the one that's deciding oh do I want to look at my entire event log uh summarize and put it in the context do I want to only look at like the last n events and put those into context. So we we could have a more flexible context strategy because of this like interface design that we chose. And then the other benefit we saw is because we could immediately start our inference calls, we were able to bring down the TAM to force token by about 90%. So the cloud would only spawn the sandbox when it needed and it would not wait for the container sandbox to spin up for you to get your first token back. So we were able to get like a much snappier and faster experience with this uh architectural change. Um, and then here's sort of like the illustration of like one brain can reach many hands. So your agent loop or harness can now call a sandbox container. It could call into a customer's VPC. It could call into an MCP server. So all these like hands are essentially interchangeable. You can call and plug in many of these and it made our architecture a lot more flexible. Um, so if you take one thing home from this, it's that harnesses encode assumptions and assumptions can go stale. So we designed interfaces to outlast these assumptions and made the architecture more flexible. So this allowed us to like I said change our compaction strategy, change out the harness completely but the interface and the architecture remains uh the same and we can really have a more pluggable way of operating this. All right, so next we're going to get into a little bit of a hands-on portion. U we got you some complimentary API credits to help you build with us today. So, please scan the QR code, either sign in to your cloud platform account or create a new one and you should be able to um get in there and get those credits so that you can build with me and and then with Gabe. And I'll I'll leave this for for a second. Hi. \>\> Sorry, what? \>\> Last slide. It's basically what we talked about here, right? This is the this is sort of like the three interfaces we designed for, right? So the first one is the the the question was like what were the interfaces that we designed that ma made things outlast uh changes. So we have the append only session log. You have the harness that's again interchangeable and then the hands where you can plug in a sandbox tool calls or whatever the model might need access to and that that's what kind of makes it more generic and extendable. All right, going back to the credits. Uh, does anyone else need to scan this before we jump in? Okay, still seeing a couple phones. Okay, going to give everyone about 30 seconds. Thanks for your patience. Oh, there are problems with the internet. Oh, no. \>\> Uh, Gabe, do we have a mic? Because I I can't hear some of the questions. Yeah, the the credit should arrive once you once you sign up in hopefully a minute or two. Um, yeah, we're getting a mic so that we can hopefully walk around and uh get get some of these questions. But yeah, I'm going to walk you through building a really simple agent that tells you jokes. Uh, and I'm going to cover some of our core APIs, our concepts first, and then we'll hop over to platform.entthropic.com to build your first agent. Um, so our first step is going to be creating our our environments API, which is v1 environments that helps you create the environment or template for your sandbox. So this is going to have uh your networking setup. So do you want uh unrestricted networking or you want to restrict it to specific domains or MCPS? you can define what packages you want installed on your uh container or sandbox. Um so this is going to be like the first step we're going to take to set up our environment. Next you're going to create the agent. So agent is essentially uh you're you can give your agent a name. So in this case we have we're going to call it joke teller. Um we're going to choose which model you want to use for this agent. So you can use opus 48, you can use haiku uh or sonnet uh your choice. Uh and then we're going to provide the agent with a system prompt. In this case, we're going to say you're a comedian. Find a fresh joke on the topic. Deliver it well. Uh and then you can provide this agent with tools. In this case, we're going to provide it with agent tool set, which is sort of like our basic tool set. This is like your bash tool set, read, write, grap, etc. And you almost all agents will need need this. Um so that's going to be your step two. Step three is going to be finally creating the session. Um so session takes an agent ID and an environment ID and creates a session. This is your task uh unit of work or your task. Um and when the session is provisioned it's idle. No work has been done right until you send an event. And then this is sort of what an event stream on your session would look like. Um you're going to have events that you send and then events that the agent will come back to you with. On the left side you'll see you have user message. You can say, "Oh, tell me a joke about distributed systems." And then the agent will come back to you with a funny joke. Um, you can use something called a custom tool. Custom tool essentially lets you define a custom tool that you want to handle how you uh how you respond to it and claude will essentially put a custom tool use event on your event stream that you can listen to and then you can process that event and then return the result um to claim tool result. And then there are some other examples in there for what type of events you would see. So you'll see session error if your session ever ends up in an error or sees an error. Status idle is when your session is idle, not working. And this is typically when you're not really have a sandbox that you're using. Um and then interrupt on the left is when you want to stop or kill the session and don't want to do the work anymore. Uh this is sort of like our full feature list. Maybe if we have time at the end, Gabe can kind of come back to this and dive in. But Gabe will be kind of working with you on his part of the workshop going deeper into some of like these concepts like multi-agent and memory that we also provide. All right, before we go to that one, we're going to hop over now to platform.claw.com. Um, and hopefully you can use your API credits and see those. Now, if you don't, I have Travis walking around with the mic in case you have questions or you need to just like flag him down for for anything. Um but if you go to your console you'll see in this manage agent section there is something called as a quick start. This is sort of like our um guided tour of how to build your first agent.