Desacoplando o cérebro das mãos: Claude Managed Agents (Parte 1 de 4) — Anthropic

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4) — Anthropic · Canal: AI Engineer · 17:17 · Assistir no YouTube

Tópicos: Agentes de IA, Infraestrutura e hardware de IA, Segurança de IA

Resumo

Priyanka e Gabe, da Anthropic, explicam os fundamentos de agents e harnesses e contam como evoluíram a arquitetura do Claude Managed Agents. A mudança central foi separar o registro da sessão, o harness e os ambientes de execução, tornando os componentes mais substituíveis e facilitando a recuperação de falhas. A arquitetura também mantém credenciais fora do sandbox e permite estratégias flexíveis de gerenciamento de contexto. Na parte prática, Priyanka apresenta as etapas e as APIs para criar um agent simples que conta piadas.

Pontos-chave

• Um agent é um modelo em um loop que usa ferramentas até concluir uma tarefa.
• O harness preenche limitações do modelo, gerencia chamadas a ferramentas e pode incorporar suposições que ficam desatualizadas.
• Executar código gerado por agents exige sandboxes isolados para conter possíveis falhas e reduzir o raio de impacto.
• A arquitetura inicial concentrava sessão, harness e execução no mesmo container, o que dificultava depuração e recuperação.
• A nova arquitetura separa o registro append-only da sessão, o harness e os ambientes de execução, chamados metaforicamente de cérebro e mãos.
• Componentes substituíveis permitem retomar o trabalho após falhas lendo o registro de eventos da sessão.
• Um proxy injeta credenciais nas chamadas externas sem expor tokens ao modelo ou ao sandbox.
• O registro preservado de eventos permite variar a estratégia de compactação e seleção de contexto.
• A arquitetura permite que um harness se conecte a vários recursos, como sandboxes, VPCs de clientes e servidores MCP.
• O fluxo apresentado para criar um agent inclui configurar o ambiente, definir o agent e abrir uma sessão para enviar eventos.

Capítulos

Início	Capítulo	Resumo
00:01	Introdução e fundamentos de agents	Os apresentadores introduzem o workshop e definem agent, harness e sandbox.
05:18	Limitações da arquitetura inicial	A primeira arquitetura concentrava tudo em um container, criando dificuldades de depuração, investigação e conexão com recursos de clientes.
07:53	Separando o cérebro das mãos	A nova arquitetura separa sessão, harness e recursos de execução, além de proteger credenciais e permitir flexibilidade no contexto.
11:31	Preparação para a parte prática	A apresentadora explica os créditos de API e responde a perguntas sobre as interfaces da arquitetura.
13:37	Criando um agent que conta piadas	Priyanka apresenta as APIs para configurar o ambiente, criar um agent e iniciar uma sessão com eventos.

Citações

Um agent é basicamente um modelo em um loop com ferramentas. — 02:07

O agent passou a ter três interfaces separadas. — 07:53

Um cérebro pode alcançar muitas mãos. — 10:29

Os harnesses codificam suposições, e as suposições podem ficar desatualizadas. — 11:00

Conceitos e entidades

• Anthropic (empresa): Empresa cujos profissionais apresentam a arquitetura e as APIs do Claude Managed Agents.
• Claude Managed Agents (ferramenta): Sistema apresentado para criar e executar agents com componentes separados para sessão, harness e execução.
• Priyanka (pessoa): Integrante da equipe técnica da Anthropic que lidera a equipe de engenharia responsável pelo Claude Managed Agents.
• Gabe Semach (pessoa): Integrante da equipe técnica da Anthropic que trabalha no Claude Managed Agents e conduz a parte prática seguinte.
• Harness (conceito): Camada que envolve o modelo, coordena chamadas a ferramentas e compensa limitações ou suposições sobre o modelo.
• sandbox (conceito): Ambiente isolado onde o agent pode executar código, editar arquivos e instalar dependências.
• registro append-only da sessão (conceito): Registro que preserva os eventos de uma sessão e permite retomar o trabalho ou escolher quais informações entram no contexto.
• proxy de credenciais (conceito): Intermediário que injeta credenciais em chamadas externas sem revelar os tokens ao modelo ou ao sandbox.
• VPC (conceito): Rede privada de um cliente à qual o agent pode se conectar como um dos recursos disponíveis.
• MCP (conceito): Protocolo e ecossistema de ferramentas que podem ser conectados ao agent, inclusive por meio de servidores MCP.

Tradução completa (pt-BR)

00:01 [música] Muito obrigado a todos por terem vindo. Acho que vamos começar, já que estamos com a casa cheia. Oi, pessoal. Meu nome é Priyanka. Sou membro da equipe técnica da Anthropic. Lidero a equipe de engenharia que criou o Claude Managed Agents e estou muito animada por estar aqui para conversar com vocês e ajudar vocês a

00:33 colocar seu primeiro agente gerenciado em funcionamento. Estou na Anthropic há pouco mais de dois anos e, nos últimos 12 meses, tenho me dedicado a criar infraestrutura agêntica. Espero compartilhar alguns dos aprendizados com vocês. >> Olá, meu nome é Gabe Semach. Sou membro da equipe técnica que está criando o Claude Managed Agents na equipe da Priyanka. Estou na Anthropic há pouco mais de um ano e passei praticamente todo esse tempo trabalhando nisso. >> Certo. Esta é a nossa agenda. Vamos começar com um breve relato da evolução de como criamos e escalamos agentes gerenciados, alguns dos obstáculos e aprendizados que tivemos ao longo do caminho. Depois, passaremos para uma parte prática do workshop. Na primeira parte, vamos criar um agente bem simples usando o console da plataforma Claude. Vocês não vão escrever nenhum código nessa parte. Vamos simplesmente chegar ao nosso primeiro agente por meio de prompts e testá-lo. Depois, vou passar a palavra ao Gabe para conduzir uma parte prática. Vamos escrever código usando o Claude Code ou seu agente de programação favorito

01:05 e, então, criar um agente financeiro mais complexo. No fim, teremos bastante tempo para perguntas e respostas. Temos um horário de duas horas. Sei que dividiram isso em quatro partes, mas, na prática, é uma apresentação longa. Espero que não leve as duas horas inteiras. Queremos que seja bem interativo, então, se tiverem perguntas, levantem a mão. Temos algumas pessoas por aqui que podem ir até vocês e passar um microfone para fazerem a pergunta, especialmente quando começarmos a parte prática. Certo, vamos começar. Então,

01:36 vou começar pelo básico. Vamos começar com o que é um agente, ou o que faz um agente funcionar. Um agente é basicamente um modelo em um loop com ferramentas. À esquerda, vocês veem o modelo decidindo e executando a próxima ação, chamando ferramentas em um loop até que a tarefa seja concluída. Essa é a definição mais básica do que é um agente. >> Com licença. >> É o arquivo de slides ou um slide? >> Ah, um link para o arquivo de slides. Podemos tentar… >> Podemos compartilhar depois. >> Sim, vamos compartilhar depois. Vai ser difícil disponibilizar agora. Mas teremos prazer em responder perguntas e compartilhar o arquivo de slides no final. Está difícil enxergar os slides lá do fundo? Certo, desculpem. Tudo bem. A próxima coisa sobre a qual eu queria falar é o que é um harness. Um harness costuma ser uma camada que envolve o modelo e ajuda

02:07 vocês a fazer essas chamadas de ferramentas em um loop para alcançar o resultado da tarefa em questão. Ele parte de suposições sobre o que o modelo não consegue fazer e tenta, de certa forma, preencher essas lacunas. Assim, ele executa um loop, faz chamadas de ferramentas, gerencia o contexto e encapsula tudo o que o modelo não consegue fazer. Um bom exemplo é que nosso modelo Sonnet 4.5 tinha algo que chamávamos de ansiedade de contexto. Então, quando o Sonnet 4.5 sentia que estava chegando ao limite do contexto, tentava concluir a tarefa muito rapidamente.

02:42 Então, ao criar um harness em torno do Sonnet 4.5, vocês poderiam adicionar algo como uma reinicialização do contexto para contornar essa limitação causada pela ansiedade. Mas o modelo seguinte, como o Opus 4.5, não tinha essa limitação, então não era necessário fazer essa reinicialização do contexto para o Opus 4.5. Ao criar um harness, vocês querem encapsular todas essas suposições sobre os diferentes modelos e mantê-las atualizadas a cada novo modelo que surgir. Por isso, criar um bom harness é muito, muito importante. E foi isso que tentamos fazer com o Claude Managed Agents. Por fim, vocês querem que o agente tenha acesso a um ambiente isolado, ou, essencialmente, a um computador: um lugar onde ele possa executar o código que está escrevendo para realizar a tarefa. Normalmente, vocês dão ao Claude acesso a um ambiente isolado ou contêiner, onde ele executa o código que está escrevendo. Ele pode editar arquivos, instalar dependências etc. O Claude Code é um ótimo exemplo disso. Ele é um harness que roda localmente no computador, tem acesso aos arquivos e os executa e atualiza à medida que avança. Ele também escreve código

03:12 que não é confiável. Esse código pode ter bugs. Então, ao implantar agentes em produção, vocês precisam garantir que o código escrito pelos agentes fique isolado em um contêiner. E o ambiente isolado deve ser separado, com um raio de impacto limitado. Normalmente, vocês querem executar cada tarefa em um contêiner separado, para não misturar as tarefas nem aumentar o raio de impacto delas. A seguir, vou apresentar a primeira arquitetura que criamos para os agentes gerenciados. Isso foi em dezembro do ano passado, quando lançamos nossa primeira arquitetura para os clientes de acesso antecipado, recebemos bastante feedback e, então, mudamos para uma nova arquitetura. Vou apresentar alguns dos obstáculos e problemas que vimos na primeira versão. Nessa primeira arquitetura, colocamos tudo no contêiner. Tínhamos o registro da sessão, com tudo o que havia acontecido nela. Uma sessão de teste é, essencialmente, a unidade de trabalho. O harness também rodava dentro do contêiner, assim como a execução no ambiente isolado. A vantagem era que, como tudo estava no contêiner, não havia limites entre serviços para projetar. Tudo era local, fácil de editar. As edições de arquivos eram basicamente chamadas de sistema. Mas percebemos que tínhamos adotado um animal de estimação. Se vocês não conhecem a analogia entre animais de estimação e gado, dos primórdios da infraestrutura, um animal de estimação é uma entidade com nome e que recebe cuidados. Quando fica doente, é preciso cuidar dela até que se recupere. Caso contrário, vocês basicamente não podem se dar ao luxo de perdê-la. Já o gado é mais intercambiável, mais descartável. Quando um animal falha, vocês podem substituí-lo por outro e seguir em frente. Um bom exemplo: imaginem que vocês têm um único fragmento de banco de dados. Ele cai, o produto fica fora do ar: vocês têm um animal de estimação. Mas imaginem que vocês têm uma configuração com um conjunto de réplicas e uma instância principal. Se a instância principal cair, vocês podem ativar uma réplica. Isso é gado, certo? Há muitas instâncias. Se uma cair, não tem problema. Vocês podem colocá-la de volta no ar. Então, com a nossa configuração inicial, tínhamos basicamente um animal de estimação. Alguns problemas: depurar era muito difícil, porque tudo rodava no contêiner. Não sabíamos o que estava causando o problema. Um pacote perdido e um contêiner encerrado apareciam de forma muito parecida, e tínhamos que abrir um fluxo via WebSocket para dentro do contêiner para depurar. O outro problema era que investigar também era difícil, porque os dados dos clientes ficavam nesses contêineres. Então, não tínhamos um

03:43 jeito de entrar, basicamente, para investigar e depurar. Esse foi outro problema que vimos no nosso acesso antecipado. O último problema era que, se um cliente quisesse que nos conectássemos, por exemplo, a um MCP na VPC dele, isso significava estabelecer peering entre redes ou enviar nosso harness para que ele o executasse. Então, essa arquitetura trouxe vários desafios para os quais não conseguimos encontrar uma boa solução. Por isso, decidimos separar o cérebro das mãos, e vou explicar o que isso significa.

04:14 com agentes gerenciados na nuvem. E, por último, você quer que seu agent tenha acesso a um sandbox ou a um computador, essencialmente, um lugar onde ele vai executar o código que está escrevendo para realizar a tarefa. Então, normalmente, você dá ao agent acesso na nuvem a algo como um sandbox ou container, onde ele executa o código que está escrevendo. Ele consegue editar arquivos, instalar dependências etc. Claude Code é um ótimo exemplo disso. Ele está sendo executado — é um harness, essencialmente — localmente no seu computador, tem acesso aos seus arquivos e os executa e atualiza à medida que avança. Ele também está escrevendo código

04:47 que não é confiável. Pode ter bugs. Então, ao fazer o deploy de agents de produção, você precisa garantir que o código escrito pelos seus agents esteja em um sandbox e contido em um container. E você quer que seu sandbox seja isolado e que o raio de impacto seja limitado. Então, normalmente, você quer executar cada tarefa em um container separado, para não misturá-las nem aumentar o raio de impacto das suas tarefas. A seguir, vou apresentar a primeira arquitetura com a qual de fato

05:18 construímos os managed agents. Isso foi em dezembro do ano passado, quando lançamos nossa primeira arquitetura para nossos clientes de acesso antecipado, recebemos bastante feedback e, depois, mudamos para uma nova arquitetura. Então, vou explicar algumas das armadilhas e dos problemas que vimos na primeira versão. Na primeira arquitetura, colocamos tudo no container. Tínhamos o registro da sessão com tudo o que havia acontecido nela. Então, uma sessão de teste é essencialmente sua unidade de trabalho. O harness também estava sendo executado

05:49 dentro do container, e a execução do sandbox também acontecia dentro do container. A vantagem disso era que, como tudo estava no container, não havia limites entre serviços com os quais precisássemos nos preocupar ao projetar. Tudo era local, fácil de editar. As edições de arquivos eram essencialmente apenas chamadas de sistema. Mas o que aconteceu foi que percebemos que tínhamos adotado um animal de estimação. Então, se você nunca ouviu falar da analogia entre animais de estimação e gado, dos primórdios da infraestrutura, um animal de estimação é uma entidade que tem nome e recebe cuidados. Quando fica doente, você precisa cuidar dela para que se recupere. Caso contrário, você basicamente não pode se dar ao luxo de perdê-la. Já o gado é mais intercambiável, mais descartável. Então, quando um falha, você pode substituí-lo por outro e seguir em frente. Um bom exemplo: imagine que você tivesse um único shard de banco de dados. Ele cai, seu produto fica fora do ar: você tem um animal de estimação. Mas imagine que você tenha uma configuração com master e réplica. Seu master cai, você pode colocar uma réplica em funcionamento. Isso é gado, certo? Então, você tem muitas instâncias. Uma cai, e isso não é um problema. Você pode colocá-la de volta em funcionamento. Então, o que tínhamos na nossa configuração inicial

06:20 era essencialmente um animal de estimação. Alguns problemas: era muito difícil depurar porque tudo estava sendo executado no container. Não sabíamos o que estava causando o problema. Então, um pacote descartado e um container parado se manifestavam de forma muito parecida, e precisávamos basicamente entrar no container por meio de um fluxo websocket para depurar. O outro problema era que investigar era difícil porque os dados dos clientes ficavam nesses containers. Então, não tínhamos uma

06:52 forma de entrar, essencialmente, para investigar e depurar. Esse foi o outro problema que vimos no nosso acesso antecipado. E o último foi que, se um cliente quisesse que nos conectássemos, digamos, a um MCP na VPC dele, isso significava estabelecer peering entre redes ou enviar nosso harness para que ele o executasse. Então, essa arquitetura tinha vários desafios para os quais não conseguíamos encontrar uma boa solução. Por isso, decidimos que queríamos essencialmente separar o cérebro das mãos, e vou explicar o que isso significa.

07:22 entrar e depurar. Então esse foi o outro problema que vimos no nosso acesso antecipado. E o último era que, se um cliente quisesse que nos conectássemos, digamos, a um MCP na VPC dele, isso significava fazer peering entre redes ou enviar nosso harness para que ele o executasse. Então, havia vários desafios nessa arquitetura que não conseguíamos realmente superar com uma boa solução. Por isso, decidimos separar o cérebro das mãos, e vou explicar o que isso significa.

07:53 Então, o agente essencialmente se tornou três interfaces separadas. À esquerda, você tem a sessão, que é essencialmente um registro apenas de acréscimo de tudo o que aconteceu na sessão até então. No meio, você tem o cérebro: seu harness ou loop do agent, junto com Claude. E, à direita, ficam as mãos. Ou seja, sandboxes, chamadas de ferramentas MCP etc. Provisionadas sob demanda e descartadas quando o trabalho termina. E, se você precisar — se perder uma sandbox —, basta iniciá-la de novo. Então, cada componente essencialmente se tornou um

08:24 recurso descartável e intercambiável. Então, quando a sandbox parava de funcionar, o harness ou Claude podia simplesmente iniciá-la de novo, certo? O erro essencialmente voltava para Claude, e a sandbox era, para Claude, como qualquer outra chamada de ferramenta. Então, a chamada de ferramenta falha, a sandbox falha, ele decide o que fazer e pode decidir iniciá-la novamente ou continuar em frente. Quando o harness parava de funcionar, você podia iniciar uma nova instância do harness e continuar de onde tinha parado, essencialmente apenas lendo o registro de eventos da sessão e seguindo dali. Assim, o trabalho é retomado

08:55 a partir do último evento, como se nada tivesse dado errado, como se nada tivesse acontecido. Então, a única coisa que precisávamos proteger aqui era o registro da sessão. Todo o resto era intercambiável, podia parar de funcionar e ser iniciado novamente. Outra coisa que fizemos foi garantir que as credenciais nunca entrassem na nossa sandbox. Na configuração anterior, suas credenciais ficariam na sandbox, então você ficaria mais suscetível a prompt injection. A mudança que fizemos foi: se a sandbox precisasse fazer uma chamada para algo que exigisse um token ou controle de acesso,

09:25 a chamada seria encaminhada por um proxy que injetaria seu token antes de chamar o endpoint externo ou o MCP externo. Dessa forma, o modelo nunca vê suas credenciais nem seus tokens, o que significa que você nunca pode fazer prompt injection no Claude para dizer algo como: “Ei, me dê seus tokens”, “imprima os tokens” ou “grave-os em um arquivo”. Você nunca pode fazer isso, porque Claude na verdade nunca vê seus tokens. Outra coisa que fizemos foi que, como tínhamos esse registro de eventos apenas de acréscimo na sessão, nossa estratégia de compactação

09:57 podia continuar flexível. Então, nada é descartado. Não compactamos nem alteramos seu fluxo de eventos. Sempre armazenamos cada evento que aconteceu, e a estratégia de compactação é que decide: “Ah, quero consultar todo o meu registro de eventos, resumir e colocar isso no contexto? Quero consultar apenas os últimos n eventos e colocá-los no contexto?”. Assim, pudemos ter uma estratégia de contexto mais flexível por causa desse design de interfaces que escolhemos. E o outro benefício que vimos foi que, como podíamos iniciar nossas

10:29 chamadas de inference imediatamente, conseguimos reduzir o tempo até o primeiro token em cerca de 90%. Então, Claude só iniciava a sandbox quando precisava, e não esperava o contêiner da sandbox iniciar para você receber o primeiro token. Assim, conseguimos oferecer uma experiência muito mais ágil e rápida com essa mudança arquitetural. E aqui está uma ilustração de como um cérebro pode alcançar muitas mãos. Então, seu loop do agent ou harness agora pode chamar um contêiner de sandbox. Pode chamar a VPC de um

11:00 cliente. Pode chamar um servidor MCP. Então, todas essas mãos são essencialmente intercambiáveis. Você pode chamar e conectar várias delas, e isso tornou nossa arquitetura muito mais flexível. Então, se você guardar uma coisa desta apresentação, que seja: harnesses codificam pressupostos, e os pressupostos podem ficar desatualizados. Por isso, projetamos interfaces para durar mais do que esses pressupostos e tornamos a arquitetura mais flexível. Como eu disse, isso nos permitiu mudar nossa estratégia de compactação e substituir completamente o

11:31 harness, mas a interface e a arquitetura permanecem as mesmas, e podemos operar de uma forma mais modular. Certo, agora vamos fazer uma parte um pouco mais prática. Temos alguns créditos de API gratuitos para ajudar vocês a desenvolver conosco hoje. Então, escaneiem o QR code, façam login na conta da plataforma Claude ou criem uma nova, e vocês poderão acessar e obter esses créditos

12:04 para desenvolver comigo e, depois, com Gabe. Vou deixar isso na tela por um instante. Oi. >> Desculpe, o quê? >> O último slide. É basicamente o que conversamos aqui, certo? Estas são, mais ou menos, as três interfaces para as quais projetamos, certo? A primeira é a pergunta

12:35 era: quais foram as interfaces que projetamos para que as coisas durassem mesmo com mudanças? Temos o registro de sessão apenas de acréscimo. Temos o harness, que também é intercambiável, e temos as mãos, às quais você pode conectar uma sandbox, chamadas de ferramentas ou qualquer coisa a que o modelo precise ter acesso. E é isso que o torna mais genérico e extensível. Certo, voltando aos créditos. Mais alguém precisa escanear isso antes de começarmos? Certo,

13:05 ainda estou vendo alguns celulares. Certo, vou dar uns 30 segundos para todo mundo. Obrigado pela paciência. Ah, estamos com problemas de internet. Ah, não. >> Gabe, temos um microfone? Porque não consigo ouvir algumas das perguntas.

13:37 Sim, os créditos devem chegar um ou dois minutos depois que vocês se cadastrarem. Estamos pegando um microfone para podermos, esperamos, circular pelo local e ouvir algumas dessas perguntas. Mas vou mostrar a vocês como criar um agent bem simples que conta piadas. Primeiro, vou abordar algumas das nossas principais APIs e conceitos, e depois vamos acessar platform.anthropic.com para criar seu primeiro agent. Então, nosso primeiro passo será criar nosso

14:08 API de ambientes, que é v1 environments e ajuda a criar o ambiente ou modelo para sua sandbox. Isso vai incluir a configuração de rede. Você quer acesso irrestrito à rede ou quer restringi-lo a domínios ou MCPs específicos? Você pode definir quais pacotes quer instalar no seu contêiner ou sandbox. Esse será o primeiro passo para configurar nosso ambiente. Em seguida, você vai criar o agent. Então, o agent é essencialmente… você

14:40 pode dar um nome ao seu agent. Neste caso, vamos chamá-lo de joke teller. Vamos escolher qual modelo você quer usar para esse agent. Você pode usar Opus 4.8, Haiku ou Sonnet, à sua escolha. E então vamos fornecer ao agent um system prompt. Neste caso, vamos dizer: “Você é um comediante. Encontre uma piada nova sobre o tema. Conte-a bem.” E você pode fornecer ferramentas a esse agent. Neste caso, vamos fornecer a ele o conjunto de ferramentas do agent, que é mais ou menos nosso conjunto básico de ferramentas. É como seu conjunto de ferramentas bash: read, write,

15:12 grep etc. E quase todos os agents vão precisar disso. Então, esse será o segundo passo. O terceiro passo será finalmente criar a sessão. A sessão recebe um ID de agent e um ID de ambiente e cria uma sessão. Essa é sua unidade de trabalho ou tarefa. Quando a sessão é provisionada, ela fica ociosa. Nenhum trabalho foi feito até você enviar um evento. E é mais ou menos assim que ficaria um fluxo de eventos na sua sessão.

15:43 Você terá eventos que envia e, depois, eventos que o agent retornará para você. À esquerda, você verá uma mensagem do usuário. Você pode dizer: “Ah, conte uma piada sobre sistemas distribuídos.” E então o agent vai responder com uma piada engraçada. Você pode usar algo chamado ferramenta personalizada. Uma ferramenta personalizada permite definir uma ferramenta cujo tratamento da resposta fica a seu critério, e Claude essencialmente colocará um evento de uso de ferramenta personalizada no seu fluxo de eventos, que você poderá escutar. Depois, poderá processar esse evento e retornar o resultado para o Claude.

16:14 resultado da ferramenta. E há alguns outros exemplos ali do tipo de eventos que você veria. Então, você verá um erro de sessão se sua sessão acabar apresentando um erro ou encontrar um erro. O status ocioso é quando sua sessão está ociosa, sem trabalhar. E isso geralmente acontece quando você não está realmente usando um ambiente isolado. E, à esquerda, “interromper” é quando você quer parar ou encerrar a sessão e não quer mais que ela execute o trabalho. Esta é uma espécie de lista completa de recursos. Talvez, se tivermos tempo no final, Gabe possa voltar a isso e se aprofundar. Mas Gabe vai trabalhar com vocês na parte dele do

16:45 workshop, aprofundando alguns desses conceitos, como multi-agent e memória, que também oferecemos. Certo, antes de irmos para aquela parte, vamos agora para platform.claw.com. E espero que vocês consigam usar seus créditos de API e ver isso. Se não conseguirem, Travis está andando por aí com o microfone, caso tenham perguntas ou precisem chamá-lo para qualquer coisa. Mas, se acessarem o console, verão que, nesta seção de gerenciamento de agent, há algo chamado

17:17 início rápido. É uma espécie de tour guiado para ajudar você a criar seu primeiro agent. [música]

Transcrição original

[00:01] [music] 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

[00:33] 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

[01:05] 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

[01:36] 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

[02:07] 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

[02:42] 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

[03:12] 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

[03:43] 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

[04:14] 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

[04:47] 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

[05:18] 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

[05:49] 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

[06:20] 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

[06:52] 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

[07:22] 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.

[07:53] 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

[08:24] 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

[08:55] 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

[09:25] 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

[09:57] 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

[10:29] 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

[11:00] 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

[11:31] 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

[12:04] 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

[12:35] 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,

[13:05] 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.

[13:37] 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

[14:08] 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

[14:40] 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,

[15:12] 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.

[15:43] 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

[16:14] 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

[16:45] 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

[17:17] quick start. This is sort of like our um guided tour of how to build your first agent. [music]