Pare de dar ferramentas ao seu agent. Dê a ele um sandbox — Mikyo King, Arize AI

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: Stop Giving Your Agent Tools. Give It a Sandbox - Mikyo King, Arize AI · Canal: AI Engineer · 14:02 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA

Resumo

Mikyo King apresenta Code Mode como uma alternativa ao tool calling tradicional: em vez de fornecer ao agent um catálogo grande de ferramentas, dá-se a ele um ambiente de programação isolado para descobrir e combinar ferramentas. Essa abordagem pode reduzir o uso de tokens, custos e turnos, além de permitir tarefas mais complexas e comportamento emergente. A palestra também aborda riscos operacionais e de segurança, como controle de recursos, acesso à rede, secrets e permissões. Por fim, King mostra como Arize avalia Code Mode com o Harbor e relata reduções de 43% nos tokens e 31% no custo, com latência praticamente constante.

Pontos-chave

Code Mode substitui um catálogo extenso de ferramentas por um ambiente em que o agent pode buscar as ferramentas necessárias e executá-las em código.
O agent pode combinar chamadas sequencialmente, em paralelo ou com condicionais, e retornar ao context window apenas os resultados relevantes.
A abordagem pode reduzir tokens, custos e quantidade de turnos, além de habilitar tarefas de horizonte mais longo e comportamento emergente.
Arize implementou Code Mode com Bash, um sandbox de Python, endpoints REST para operações CRUD e consultas SQL.
Um paradigma de programação integrado à interface permite que o agent leia dados e altere elementos da UI por meio de um web worker.
Sandboxes exigem cuidado com recursos, acesso à rede, secrets, permissões, falhas de execução e depuração de código.
A descoberta de ferramentas, a precisão do código gerado e a compatibilidade com modelos menores continuam sendo desafios.
Arize avalia os agents no Harbor com instruções claras, acesso à rede desativado, múltiplas execuções e verificadores que indicam sucesso ou falha.
Nos resultados apresentados, Code Mode reduziu o uso de tokens em 43% e o custo em 31%, enquanto a latência permaneceu praticamente constante.

Capítulos

Início	Capítulo	Resumo
00:01	Por que os agents podem criar software sob demanda	King explica como agents de programação podem dissolver a divisão entre ferramentas feitas para programadores e softwares destinados a outras pessoas.
02:05	Code Mode em comparação com tool calling tradicional	A palestra compara catálogos grandes de ferramentas com um ambiente programável que permite compor chamadas e reduzir o conteúdo enviado ao context window.
04:41	Composição de ferramentas e comportamento emergente	King descreve a descoberta progressiva de ferramentas, a eficiência de tokens e a possibilidade de o agent criar soluções para tarefas específicas.
08:17	Riscos e desafios dos sandboxes	O palestrante discute segurança, permissões, recursos, depuração, descoberta de ferramentas e limitações de durabilidade e compatibilidade com modelos menores.
11:25	Avaliação do Code Mode e resultados	King apresenta a avaliação com Harbor e os resultados medidos, incluindo redução de tokens e custo, e conclui defendendo sandboxes para agents.

Citações

Você dá a ele um ambiente de programação para executar essas ferramentas em diferentes tipos de fluxos. — 03:08

A capacidade de criar as próprias ferramentas traz um enorme benefício. — 05:42

Reduzimos a quantidade de tokens em 43%. O custo caiu 31%, e a latência permaneceu praticamente constante. — 12:58

Espero que esta palestra convença você a dar um sandbox ao seu agent. — 14:02

Conceitos e entidades

Code Mode (conceito): Abordagem em que o agent usa um ambiente de programação para descobrir, combinar e executar ferramentas, em vez de depender de um catálogo inteiro de chamadas diretas.
sandbox (conceito): Ambiente isolado de execução que permite ao agent rodar código e ferramentas, com controles de recursos e acesso.
tool calling (conceito): Mecanismo em que o modelo solicita a execução de ferramentas, cujas chamadas e resultados podem ser acrescentados ao context window.
Arize AI (empresa): Empresa para a qual Mikyo King diz liderar o grupo open source.
Mikyo King (pessoa): Palestrante que apresenta a adoção de Code Mode pela Arize.
Arize Phoenix (ferramenta): Plataforma open source de observabilidade e avaliação usada pela Arize para desenvolver e avaliar seu agent.
Harbor (ferramenta): Framework citado para executar agents em ambientes sandbox e avaliar tarefas com verificadores.
MCP (conceito): Padrão mencionado na palestra como um dos lugares em que Code Mode pode ser incorporado.
Bash (ferramenta): Shell usado pela Arize para combinar utilitários Linux, CLI e arquivos dentro do ambiente de execução do agent.
SQL (conceito): Linguagem usada para permitir consultas agregadas aos dados, sem precisar percorrer registros página por página.

Tradução completa (pt-BR)

00:01 [música] >> Obrigado a todos por terem vindo. Meu nome é Mikail. Eu lidero o grupo de open source na Arize AI, onde trabalhamos em uma estrutura totalmente open source de observabilidade e evals, e também desenvolvemos nosso próprio agent. Hoje, quero apresentar a vocês o que é o Code Mode

00:32 e contar nossa trajetória adotando o Code Mode. Se olharmos para os últimos 30 anos de desenvolvimento de software, podemos dividir os softwares em duas categorias diferentes: os feitos para engenheiros de software e os feitos para quem não é engenheiro. Por exemplo, imagine que peçam para você baixar todas as faturas da sua caixa de entrada de e-mail. Se você for programador, pode escrever um script, entrar lá, verificar dinamicamente se há um anexo, baixá-lo e colocá-lo

01:02 em uma pasta. Talvez sejam umas 50 linhas de código, e você terá uma ferramenta que pode usar. Já se não tiver conhecimentos técnicos, terá que entrar nessas caixas de entrada e baixar os arquivos manualmente. Você fica limitado pela interface do software e precisa comprar esse software. O mais interessante em ferramentas como o Claude Code é que essa fronteira está desaparecendo completamente, certo? Basicamente, qualquer coisa de que você precise, o agente de programação pode criar dinamicamente para você. E os laboratórios e fornecedores de modelos fundacionais

01:33 sabem disso, certo? Se olharmos para todos os benchmarks, como o SWE-bench, veremos que é para isso que esses modelos estão sendo treinados. Então, não faz sentido alinhar os agents que estamos desenvolvendo para que consigam criar dinamicamente o software de que precisamos e dissolver essa fronteira? Antes de começar a falar sobre o Code Mode, vamos ver como é um agent. Espero que vocês já tenham criado esse tipo de agent. Você dá a um agent

02:05 um catálogo enorme de ferramentas e, iterativamente, chega uma pergunta do usuário; o agent chama as ferramentas, cujas respostas são inseridas na context window, raciocina sobre elas e então chama outra ferramenta, cuja resposta também é inserida na context window. Espero que a maioria de vocês já tenha criado um agent assim. Certamente, com um conjunto específico de ferramentas, isso pode funcionar muito bem. Mas agora estamos numa época em que queremos muito mais. Queremos um comportamento muito mais emergente. Queremos colocar muito mais contexto no agent. Queremos horizontes mais longos. E é aí que

02:37 começa esse inchaço do contexto. Vocês vão ver muitas ferramentas sendo adicionadas à context window, talvez sem relação com a tarefa. Talvez a chamada da ferramenta retorne um monte de lixo ou seja necessário paginar os dados. E, assim, vocês acabam lidando com essa deterioração do contexto. Também lidam com várias interações, muitos turnos e, por consequência, precisam lidar com a compactação. Felizmente, o Code Mode resolve muitos desses problemas. É uma arquitetura alternativa.

03:08 Em vez de, por exemplo, simplesmente dar ao agent um índice enorme ou um menu de ferramentas, você dá a ele a capacidade de buscar a ferramenta específica e também de executá-la. Mas não dá apenas a capacidade de executar a ferramenta: você fornece um ambiente de programação para executá-las em diferentes tipos de fluxo. Assim, ele pode executá-las em sequência, em paralelo ou adicionar condicionais. E o bom disso é que

03:38 você pode chamar várias ferramentas em um único turno e retornar apenas o que é necessário para inserir de volta na context window do modelo. Resumindo, vamos colocar essas duas situações hipotéticas lado a lado: com o tool calling tradicional, o acúmulo de contexto na context window cresce a cada chamada de ferramenta. Isso obviamente aumenta a latência e o custo. Também aumenta o número de turnos. Portanto, aumenta o tempo que o usuário leva para obter valor, certo?

04:10 Isso gera bastante sobrecarga. Por outro lado, o Code Mode, quando bem implementado, pode desbloquear muitos recursos, porque pode chamar quantas ferramentas quiser em um único turno e só precisa inserir na context window exatamente o que é necessário para resolver o problema. Também é possível reduzir o número de turnos. Esse é, basicamente, o objetivo do Code Mode. Vamos ver alguns dos motivos pelos quais o Code Mode funciona.

04:41 O Code Mode funciona porque, primeiro, você não precisa fornecer de antemão um catálogo gigantesco de ferramentas. Ele pode simplesmente escolher as ferramentas de que precisa, entendê-las e então executar apenas essas. Ou seja, há uma disponibilização progressiva das ferramentas. Certamente, recursos como a busca de ferramentas também já estão integrados aos fornecedores de modelos fundacionais. Há também a capacidade de composição. É muito vantajoso poder chamar ferramentas em diferentes sequências: em sequência, em paralelo, distribuindo as chamadas ou encadeando-as. É possível criar coisas muito mais

05:11 complexas e eficientes. Se vocês já ouviram falar, os fluxos de trabalho dinâmicos do Claude são baseados nessa capacidade de composição — mas na composição de subagents. Já mencionei a eficiência no uso de tokens. Você não precisa despejar todas as saídas das ferramentas nem se preocupar com elas sendo inseridas na context window. O modelo pode selecionar e buscar dinamicamente determinadas partes e inserir de volta na context window apenas o que precisa. E o quarto motivo, que é um dos principais motivos pelos quais adotamos o Code Mode, é essa ideia de

05:42 comportamento emergente: a capacidade de criar as próprias ferramentas, certo? Por exemplo, com o tool calling tradicional, se eu dissesse: “Pegue todos esses registros e remova as informações de identificação pessoal”, ele não conseguiria fazer isso porque não tem uma ferramenta para isso. Ou talvez tentasse fazer dentro da própria context window, mas aí estaria expondo números de cartão de crédito na context window, o que não é bom. Portanto, a capacidade emergente de criar as próprias ferramentas traz muitos benefícios. Aqui estão algumas maneiras como adotamos

06:14 o Code Mode. Criamos nosso próprio agent e harness dentro do Phoenix, nossa plataforma open source de observabilidade, e começamos com Bash. Bash é uma ótima ferramenta para combinar coisas como sed e grep, combinar primitivas integradas do Linux com nossa própria CLI e transferir os resultados para arquivos para uso posterior. Também adicionamos um sandbox de Python e

06:44 expusemos todos os nossos endpoints REST de CRUD. Eles servem, por exemplo, para obter traces ou manipular conjuntos de dados. Colocamos isso no ambiente de programação para que o agent possa combinar essas operações de criação, leitura, atualização e exclusão, o que desbloqueia toda uma categoria de possibilidades. Também adicionamos mais um recurso: a capacidade de escrever SQL. Vocês provavelmente já ouviram falar muitas vezes de text-to-SQL, mas isso também desbloqueia muitos

07:15 recursos. O motivo é que nem tudo se encaixa na categoria de ferramentas voltadas apenas à criação, atualização e exclusão. Talvez seja necessário fazer consultas de agregação, como: “Mostre todos os spans de LLM com latência P95 de X, Y e Z”. Você não quer ter que paginar todos os seus traces para fazer isso. Você quer que o LLM consiga localizar exatamente o que está procurando. Essa é uma maneira interessante e criativa como também usamos o Code Mode. Também criamos uma espécie de

07:45 paradigma de programação na nossa interface, vinculado a ela. Assim, conseguimos dar ao agent a capacidade de alterar o intervalo de tempo ou ler dados do armazenamento de dados dentro do frontend. O mais legal é que quase temos esse comportamento emergente de uso livre do computador, porque conseguimos colocar esse paradigma de programação em um web worker com vinculação de dados bidirecional diretamente ao nosso navegador. Ele pode realizar interações complexas com a interface para você, e é muito divertido vê-lo fazer isso

08:17 cozinhar. Então, o modo de código obviamente não é de graça. Você está lidando com código gerado por LLM. Se assistiu às palestras da Anthropic, provavelmente já viu alguns desses casos. Você está lidando com recursos. Então, se estiver trabalhando com sandboxes hospedados, precisa se preocupar com CPU, memória e por quanto tempo essas sandboxes ficam disponíveis. A rede é um ponto muito importante. Talvez você queira que ele consiga acessar a web, mas nunca sabe o que há na web. Por isso, precisa pensar cuidadosamente no tráfego de saída da rede. Segredos são um

08:50 tema muito discutido. Acho que cada provedor de sandbox está tentando criar uma estratégia diferente de armazenamento de segredos. Mas digamos que você queira usar Jev dentro da sua sandbox, como o Pi, que a Durable acabou de lançar. É uma ideia incrivelmente legal poder tomar decisões rápidas dentro de uma sandbox, mas você precisa garantir que esses segredos não voltem para a context window. E o outro ponto são as permissões. Há pesquisas bem interessantes sobre isso também, mas, em geral, as permissões são amplas demais. E

09:20 então, talvez as permissões estejam corretas nos cinco primeiros conjuntos, mas não na sexta operação. Ou talvez não estejam corretas na composição. Por isso, você precisa pensar em adicionar algumas barreiras de proteção a essas coisas, se for necessário. Também há a complexidade operacional. Certamente, as sandboxes nem sempre iniciam perfeitamente. Então, você precisa conseguir lidar com falhas. É mais difícil depurá-las, porque agora você está depurando código, em vez de depurar ferramentas individuais. E

09:52 a precisão dos parâmetros das ferramentas se torna uma questão muito mais importante, porque o parâmetro da ferramenta agora é código. Então, e se algo falhar no meio? A descoberta de ferramentas também continua sendo um problema. Antes, se você tivesse uma ferramenta, o LLM saberia de antemão que ela existia; agora, talvez precise passar por uma negociação para entender quais ferramentas estão no catálogo de coisas que pode fazer. E este é um ponto importante: você vê o modo de código sendo incorporado ao MCP, mas também vê cada vez mais o modo de código sendo integrado aos

10:23 harnesses. E agora você tem um problema de sandboxing duplo. O sandboxing vai retornar dados em JSON serializado, que precisam ser analisados e depois inseridos em outro modo de código. Então, acaba acontecendo esse trabalho duplicado, o que também pode aumentar a complexidade operacional. Esses são problemas ainda em aberto. Não são impeditivos, mas a durabilidade é um problema. Digamos que você crie um trecho enorme de código que precisa ser executado e ele falhe no

10:53 meio. Você não consegue retomar a execução a partir daquela etapa. Se o determinismo e a matemática forem importantes para você, por exemplo, talvez isso obrigue você a pensar na linguagem de programação que está usando. JavaScript é uma linguagem com a qual os LLMs se saem muito bem, mas talvez não seja a melhor para matemática. Por exemplo, o modo de código pode ser uma ótima maneira de trabalhar com multimodalidade e manipular imagens ou criar bytes, mas tirar isso da sandbox é bem complicado, certo? Porque você não quer serializar todo o binário, a imagem inteira. Isso

11:25 acabaria na context window. Então, talvez você precise fazer algum tipo de transferência segura da imagem. E o outro ponto é que os modelos de fronteira são incríveis no modo de código, mas, se você estiver tentando reduzir custos e quiser trocar por um modelo menor, talvez ele simplesmente não tenha capacidade suficiente. Então, como avaliamos o modo de código na Arize? Usamos a nossa própria plataforma, chamada Arize Phoenix, e executamos nossos agents em várias permutações

11:56 por meio de algo chamado framework Harbor, que basicamente coloca os agents em ambientes de sandbox e os executa com instruções claras e o acesso à rede desativado. Fazemos vários testes para reduzir bastante a instabilidade. E criamos evals na forma de verificadores do Harbor para garantir que o agent está fazendo a coisa certa. O Harbor também tem suas raízes nesse framework de RL. Atribuímos um ou zero para indicar se ele executa ou não a

12:27 tarefa, e o testamos em muitas permutações diferentes. É por isso que você quer testar dessa forma: como mencionei, pode haver muita instabilidade. Às vezes, pode funcionar em um sistema não determinístico. Ele pode seguir trajetórias diferentes, dependendo de como você o utiliza, e acompanhamos a taxa de sucesso em K de cada tarefa que esperamos que ele consiga executar. Então, como isso funciona? Estes são os resultados da nossa execução do

12:58 Harbor. Você pode ver que, antes e depois do modo de código, reduzimos a quantidade de tokens em 43%. O custo caiu 31% e, embora a sandbox tenha gerado alguma sobrecarga, a latência permaneceu praticamente constante. Então, sabíamos que, em várias dessas superfícies — fosse no Claude Code, no MCP ou na CLI —, tínhamos conseguido algo definitivamente melhor do que antes. Como usamos esses dados? É realmente um grande avanço se você registrar tanto a trajetória quanto as evals. Como

13:30 vocês viram em muitas das outras palestras, isso cria um ambiente excelente para reforçar e observar o comportamento desses agents e poder orientá-los sobre como melhorar gradualmente. Então, talvez, na primeira vez que introduzimos uma ferramenta nova, a eficiência até diminua. Assim, podemos explicar a um agent de programação por que, nesses cenários específicos, partes das instruções estão orientando-o na direção errada. E podemos melhorar gradualmente essas evals para tornar nossos agents melhores. Então, se você não levar nada além de

14:02 isto, espero que esta conclusão resuma tudo. Gostamos muito do modo de código na Arize por causa do menor número de turnos que ele proporciona. Queremos que você possa usar qualquer modelo. Queremos que seja mais barato e estamos muito empolgados com os comportamentos emergentes e as tarefas de longo prazo que nossos agents conseguem realizar. Espero que esta palestra convença você a dar uma sandbox ao seu agent e depois usar uma das nossas ferramentas para avaliá-lo. É isso. Obrigado.

Transcrição original

[00:01] [music] >> Thanks for everyone for coming. So, my name is Mikail. I head up the open source group at Arise AI and we work on a fully open source observability and evaluation framework and we also work on our own agent. So, today we want I want to kind of walk you through what Code Mode is

[00:32] and our journey embracing Code Mode. So, if you look back in the last 30 years of software development, you could kind of segment software into two different categories. You could think of there’s software built for software engineers and software for non-engineers. Take for example, you have you know, you’re asked to get all the invoices out of your email inbox. If you’re a programmer, you could write a script, [snorts] you can go in there, you can dynamically like see if there’s an attachment, download it, put it into

[01:02] a folder. It might be a you know, 50 lines of code and you get this tool that you can use versus if you were a non-technical, you’d have to go into these inboxes, you have to manually download it. You’re restricted by the interface of the software and you had to kind of buy that software. And the thing that’s really interesting about things like Cloud Code is that that boundary is completely dissolving, right? Basically, anything you need, the coding agent can actually build that software for you dynamically. And the labs and the

[01:33] foundation model providers know this, right? If you look at all the benchmarks like SWE-bench, that is what these models are being trained to do. And so, doesn’t it make sense basically to align the agents you’re building to be able to kind of build the software you need dynamically to dissolve that boundary. So, before I get to started in Code Mode, let’s look at kind of what an agent looks like. So, hopefully you’ve built this uh uh kind of agent before. You give an agent

[02:05] kind of a huge catalog of tools, and then iteratively a user question comes in, it calls the tools that get pushed in the context window, it reasons about it, and then it calls another tool that get pushed in the context window. And hopefully most of you have built an agent like this. Uh certainly if you have a certain set of tools, this can work pretty well. But, we’re now in that age where we want a lot more. We want much more emergent behavior. We want to put a lot more context into the agent. We want to have longer horizons. And so,

[02:37] this is where you kind of get this bloat inside of the context. You’ll see there’s a lot of tools that get added into the context window that might not be relevant to the task. Um maybe the tool call is not responding with a lot of junk, or maybe needs to paginate through data. And so, you deal with this kind of context rot. You also deal with multi-turn, a lot of turns, as a result, and you’re going to have to deal with compaction. So, luckily CodeMon solves a lot of these things. It’s kind of an alternative

[03:08] architecture. Um instead of, let’s say, just giving it a huge index or a menu of tools, you give it the ability to search for the specific tool, and then you also give it the ability to execute the tool. But, you don’t give it just the ability to execute the tool, you actually give it a programming environment to execute those tools in different types of flows. So, they can do it sequentially, they can do them in parallel, um can put conditionals around it. Um and the nice thing about this is

[03:38] you can call multiple tools in one turn, and also return only what’s necessary to push back into the context window of the model. And so, to kind of summarize it, put those these two things hypotheticals side by side, traditional tool calling, you know, you accumulate context window blow every time you call a tool. That’s obviously going to, you know, add to latency and cost. It’s also going to increase increase turns. So, the time your user takes to get to value increases, right?

[04:10] So, has a lot of overhead. Um, on on the flip side, code mode potentially, when done well, can unlock a lot of abilities because it can call as many as it wants in a single turn and it only has to put in exactly what’s necessary into the context window to solve its problem and you can also get a reduction in turn. So, that’s sort of the the goal of of code mode. And so, let’s just kind of go over some of the reasons why code mode works. Code

[04:41] mode works because one, you don’t have to give it the giant catalog of tools up front. It can just pick and choose the tools that it needs and understand those tools and then execute just those. So, there’s a progressive disclosure of tools. Uh, certainly there’s things like tool search now also built into the foundation model providers. There’s also the composability. There’s a huge amount of benefit to not being able to being able to call tools in different sequences, either in sequence or parallel, fan out, chaining them together. You can create much more

[05:11] complicated and efficient things. If you’ve heard of obviously Claude’s dynamic workflows is built on this composability but composability of sub agents. I already mentioned sort of token efficiency. You don’t have to spit out all the tools outputs and worry about the tools outputs being shoved into the context window. The model can dynamically kind of trim and search for certain areas and only put what it needs back into its context window. And the fourth one, which is the kind of the one of the major reasons we’ve embraced code mode, is this idea of

[05:42] emergent behavior, being able to build its own tools, right? So, for example, traditional with traditional tool calling, if I said for example like take all these records and remove personally identifiable information, it wouldn’t be able to do that because it doesn’t have a tool, or it might try to do it inside of its its context window, but then you’re leaking credit card numbers in the context window, and that’s not great. So, the emerging behavior of being able to create its own tools has a huge amount of benefit. So, here are some ways in which we’ve

[06:14] embraced Code mod. Uh so, we build our own agent uh and harness inside of Phoenix, our open source uh our observability platform, and we started with Bash. You know, Bash is a great tool of being able to compose together things like uh you know, said and grep to be able to uh compose together, you know, built-in Linux primitives with also our own CLI and be able to offload those into files for later use. We also added um

[06:44] you know, a Python’s sandbox, and we hoisted all our rest CRUD endpoints. Those are like perform getting traces or uh manipulating data sets, and we put that into this coding environment so that it can compose those create, read, update, delete operations, which unlocks like a whole category of things. And we also added one additional one, which is the ability to write SQL. And you know, text of SQL, you’ve obviously like heard like that probably many times before, but this also unlocks a lot of

[07:15] capabilities. The reason why is not everything fits into the tool category of just creating, updating, and deleting. Maybe you need to be able to do aggregate queries like tell me all the LM spans that have P95 latency of X, Y, and Z. You don’t want to have to paginate through all your traces to do that. You want it the LM to be able to pinpoint find exactly what you’re looking for. This is kind of a a neat and creative way we’ve also used code mode. So, we’ve actually also created a sort of a

[07:45] programming paradigm in our UI that’s bound to our UI. So, we’ve been able to kind of be able to give it the ability to change the time range or be able to read data from the data store inside of the front end. And what’s really cool about this is you kind of almost get this computer loose use like emergent behavior because we’re able to put that programming paradigm in a web worker that has a two-way data binding directly into our browser and it can kind of do complex UI interactions for you and it’s really pretty fun to to watch it uh

[08:17] cook. So, code mode is not uh obviously for free. Um you’re dealing with LLM generated code. If you’ve been at to the the Anthropic talks, you certainly probably seen some of these. You’re dealing with resources. So, if you’re working with hosted sandboxes, you have to worry about CPU, memory, how long those sandboxes stay around. Networking is a huge one. Maybe you want it to be able to go out to the web, but you never know what’s out in the web. And so, you have to carefully think about network egress. Uh secrets is a

[08:50] hot topic. I think every sandbox provider is trying to come up with a different vaulting strategy. But, let’s say you want to use Jev inside of your sandbox like Pi uh durable just shipped, you know, that’s a crazy cool idea uh to be able to make fast decisions inside of a sandbox, but you have to make sure that those secrets don’t come back into the context window. And then the other one is permissions. Uh there’s some very interesting research around this as well, but typically permissions are overbroad. And

[09:20] so, maybe in the first five sets the permissions are correct, but in the sixth operation it is not. Or maybe in composition uh the permissions are not. And so, you have to kind of think of guard railing some of these things if that is necessary. There’s also operational complexity. Uh certainly sandboxes don’t boot uh all the time perfectly. And so you have to you know be able to deal with failures. They’re harder to debug because now you’re debugging code and you’re not debug debugging individual tools. And

[09:52] tool parameter accuracy becomes a much bigger issue because the tool parameter now is code. Uh so what if something fails in the middle? Uh tool discovery is also still an issue. Previously if you did have a tool, the LM would up front know it, but now it might have to go through a handshake to be able to understand which tools are in its catalog of things to be able to do. And then this is sort of a big one, you know, you see code mode being injected into MCP, but then you see a lot more code mode being pushed also into

[10:23] harnesses. And now you have a double sandboxing uh problem. So sandboxing, you know, is going to return stuff out as serialized JSON and then it needs to be parsed and then put into another code mode. And so there’s this like double duty that ends up happening that also can be on operational complexity. These are sort of open problems. Uh they’re not like blockers, but durability is a problem. So let’s say you build a giant piece of code that needs to execute and it breaks in the

[10:53] middle. You can’t resume from that step. Um if determinism and mathematics are important to you, for example, it might actually force you to think about which programming language you’re using. So JavaScript is something LLMs are really good at doing, but maybe not great for math. Um For example, uh code mode can be great way to do multimodal and manipulating images or creating bytes, but getting that out of the sandbox is quite tricky, right? Because you don’t want to serialize the whole binary, the whole image. That’s

[11:25] going to end up in the the context window. So you might have to do some sort of signed image handoff. And then the other one which is like the Frontier models are amazing at code mode, but if you’re trying to do cost saving and you want to swap out a smaller model, its capabilities might not just quite um get there. So, how do we at Arize evaluate code mode? Um we use our own We dogfood our own platform, which is called Arize Phoenix, um and we run our agents through various

[11:56] permutations through something called the Harbor framework, which basically puts the agents into uh sandbox environments and runs them on clear instructions with network access turned off, and we run this multiple times in trials, so we eliminate a lot of the flake. And we build evals in the form of Harbor verifiers to make sure that the agent’s doing the correct thing. And then, Harbor’s sort of rooted in this RL framework. We give it a a one or a zero to indicate whether or not performs the

[12:27] task, and we test it across many different permutations. So, this is kind of why you want to test like this, because as I mentioned, you can get a lot of flake. Um sometimes it might work where you’re dealing with an indeterminate system. It might take different trajectories uh depending how you do it, and we uh track pass at K of each individual task that we think it should pass. So, you know, how does this work? Uh this is kind of our results from uh running this

[12:58] Harbor run. You can see pre uh code mode and post code mode, we, you know, decreased the amount of tokens by 43%. The cost went down by 31%, and you know, there was some overhead with the sandbox, but the latency stayed pretty constant. So, we knew that across these multiple surfaces, whether or not it was cloud code or MCP or the CLI, we had accomplished something that uh was definitely better than it was before. How do we use this data? It’s really uh a huge unlock if you have you both capture the trajectory and the evals. As

[13:30] you’ve seen with a lot of the other talks, this gives you a very great environment to reinforce and look at the behavior of these agents and be able to tell it how to hill climb. So, maybe, you know, first time we introduce a new tool, sometimes actually the efficiency goes down. And so, we can tell a coding agent why in these specific scenarios, what parts of the instruction are are guiding it in the wrong direction and we’re able to hill climb these evals to be able to make our agents better. So, if you don’t take anything other than

[14:02] this away, hopefully this will sum it up. We really like code mode at RI because of the fewer turns you get out of code mode. We want you to be able to bring any model for us. So, we want it to be cheaper and we’re really excited about the emergent behavior and the long horizon tasks that our agents can do. And so, I hope this talk convinces you to give your agent a sandbox and then use one of our tools to evaluate it. And that’s it. Thank you.