Por que janelas de contexto maiores não vão salvar seu agent — Elizabeth Fuentes Leone, AWS

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: Why Bigger Context Windows Won’t Save Your Agent — Elizabeth Fuentes Leone, AWS · Canal: AI Engineer · 15:21 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de prompts e contexto, Ferramentas de desenvolvimento com IA, Infraestrutura e hardware de IA

Resumo

Elizabeth Fuentes Leone explica por que ampliar a context window não resolve, por si só, os problemas de agentes que recebem grandes volumes de dados. Ela apresenta estratégias de context engineering para controlar o que chega ao modelo: externalizar dados, selecionar o que é relevante, comprimir informações e isolar contextos entre agents. A palestra demonstra técnicas com Strands, incluindo gerenciamento de conversas, memória de longo prazo, ponteiros para dados armazenados, limites de chamadas de ferramentas e operações assíncronas. A recomendação final é evitar entupir a context window e fornecer ao agent apenas o necessário para responder.

Pontos-chave

Uma context window maior não impede que o modelo perca informações relevantes quando recebe contexto demais.
Context engineering consiste em fornecer ao modelo as informações certas no momento em que ele precisa delas.
As estratégias apresentadas são externalizar dados, selecionar informações relevantes, comprimir contexto e isolar contextos entre agents.
O gerenciamento de conversas pode manter mensagens recentes, resumir mensagens antigas ou combinar as duas abordagens.
Memórias de curto prazo, de longo prazo e em grafo podem ser combinadas conforme as necessidades da aplicação.
Dados extensos, como logs, podem ser armazenados externamente e acessados por meio de um memory pointer.
Compartilhar todo o contexto entre agents pode introduzir informações desnecessárias; ponteiros podem permitir o compartilhamento seletivo.
Limitar o número de chamadas de ferramentas ajuda a evitar loops repetitivos do agent.
Operações assíncronas permitem lidar com ferramentas e APIs externas que demoram a responder.

Capítulos

Início	Capítulo	Resumo
00:12	Limites de uma context window maior	A palestrante explica como o excesso de dados pode causar degradação e esquecimento, e introduz context engineering.
03:01	Estratégias de context engineering	São apresentadas as estratégias de externalizar, selecionar, comprimir e isolar informações, além de técnicas de gerenciamento de conversas em Strands.
06:26	Memória e armazenamento externo	A palestra diferencia memórias de curto e longo prazo e memória em grafo, e mostra como recuperar logs usando um memory pointer.
09:47	Isolamento entre agents e limites de ferramentas	A palestrante aborda o compartilhamento seletivo de contexto entre agents e o uso de limites para evitar loops de chamadas de ferramentas.
12:08	Chamadas assíncronas e recomendações finais	São descritas chamadas assíncronas para ferramentas e APIs externas, seguidas de recomendações para evitar excesso de contexto.

Citações

Antes, achávamos que adicionar mais tokens resolveria o problema. Hoje sabemos que isso não é verdade. — 01:52

Context engineering é dar ao modelo as informações de que ele precisa quando precisa delas. — 02:28

Você não precisa dos logs para entender isso; mas, se precisar, pode pedir para recuperá-los pelo ID. — 08:38

Você não precisa incluir tudo na context window; o modelo não precisa de todas as informações. — 13:45

Conceitos e entidades

context engineering (conceito): Prática de controlar quais informações são fornecidas ao modelo e quando elas são disponibilizadas.
context window (conceito): Espaço de contexto usado pelo modelo, que pode ficar sobrecarregado com dados excessivos.
Strands (ferramenta): Framework apresentado para criar agents e configurar estratégias de gerenciamento de conversas.
Amazon Bedrock (ferramenta): Serviço citado como parte da implementação usada por Strands.
AWS (empresa): Empresa associada à palestrante e às ferramentas e serviços mencionados na apresentação.
Elizabeth Fuentes Leone (pessoa): Palestrante que apresenta técnicas de context engineering para aplicações com agents.
Neo4j (ferramenta): Banco de dados mencionado como opção para representar relações entre entidades em uma memória em grafo.
MCP (conceito): Protocolo citado no contexto de chamadas a ferramentas e integrações externas, inclusive assíncronas.
memory pointer (conceito): Identificador mantido no contexto que permite recuperar dados armazenados externamente quando necessário.
FastAPI (ferramenta): Framework citado na demonstração de ferramentas para iniciar e consultar tarefas assíncronas.

Tradução completa (pt-BR)

00:12 Oi. Bem, primeiro preciso dizer que sou Elizabeth. Não sou Morgan. Mas o cara responsável pela agenda nunca muda a agenda. Então somos quase iguais, mas com cores de cabelo diferentes. Certo. Então vai ser parecido. Hoje vou falar sobre a janela de contexto infinita. É uma necessidade. Sim, sim, porque, no momento, o sistema de agentes falha quando as ferramentas retornam uma grande quantidade de dados. A context window

00:48 transborda, e o mecanismo começa a alucinar e a recuperação se degrada. Então, no momento, a engenharia de contexto nos ajuda a oferecer uma arquitetura melhor para essa aplicação de agent. Temos algumas técnicas que nos permitem melhorar a context window dessa aplicação agêntica. Imagine que você tem um agent responsável por supervisionar alguma

01:21 aplicação. Esse agent precisa recuperar os logs dessa aplicação. Então, toda vez que esse agent recupera os logs, os dados são colocados na context window, e ela cresce cada vez mais. Ela vai crescer toda vez porque, quando temos uma sessão, cada sessão recupera a sessão anterior, já que vai se lembrar de tudo. É assim que os agents se lembram e usam a context window

01:52 para isso. Há cerca de um ano, antes desta era agêntica, achávamos que bastava adicionar mais tokens para resolver o problema. Sim, uma context window maior resolveria. Hoje sabemos que isso não é verdade, por causa da curva em U da atenção. O que é isso? Temos muitos dados, mas, se esses dados forem grandes demais, o mecanismo vai esquecer o meio da curva. Ele só vai se lembrar do início e do fim do que enviamos para essa context window.

02:28 Estou falando aqui de engenharia de contexto. Posso avançar? A engenharia de contexto fornece ao modelo as informações de que ele precisa, quando precisa delas. Às vezes, o agent não precisa de todas as informações dentro dessa context window. Às vezes, a context window envenena o mecanismo, porque pode haver um problema de injeção de prompt dentro dela. A engenharia de contexto

03:01 nos ajuda a incorporar a context window para obter resultados ideais e consumir menos tokens. Hoje vou mostrar algumas técnicas que podem ajudar a melhorar a context window. Organizei essas técnicas em uma estratégia. Temos a externalização: mover esses dados grandes para um armazenamento persistente. Você pode criar um ponteiro de memória

03:34 para armazenar esses dados. Vou compartilhar os slides no final. Então, não precisa anotá-los. Prestem atenção, por favor, porque vou compartilhar todas as informações sobre as quais vou falar. A segunda é a seleção: você pode recuperar apenas o que for relevante. Temos a compressão, que reduz a quantidade de tokens, porque você pode resumir e compactar essas informações. A última é o isolamento, porque você pode separar o contexto entre agents. Vamos começar.

04:09 Então, o ponto de partida é o Conversation Manager. Temos algumas estratégias um pouco complicadas, mas vamos começar pela mais simples, que podemos usar dentro do framework. Aqui, nessa estratégia, vamos usar o mecanismo Strands. É um framework que mantemos; é completamente open source, sim, é grátis e, sim, é open source e grátis, então

04:39 é completamente independente de modelo. Com o Strands, você pode usar três estratégias diferentes dentro do framework. Temos a janela deslizante, que permite manter apenas as mensagens mais recentes. Temos o resumo dentro do framework, que permite resumir todas as mensagens e manter a atual. E a última é uma combinação das duas: você pode combinar um resumo das mensagens antigas com as recentes. Primeiro, vamos ver o que é o Strands. É assim:

05:16 você só precisa de uma linha de código para criar o loop do agent. Essa linha cria todo o loop do agent nos bastidores. Você não precisa criar os nós nem o grafo, nada disso, porque o Strands faz isso por você. E você tem o system prompt e as ferramentas. Sim, é simples porque usa o Amazon Bedrock nos bastidores. Mas, se quiser usar Lambda, Gemini e Anthropic, basta adicionar uma linha, porque você pode fazer isso. Importe a biblioteca da OpenAI,

05:51 por exemplo, e depois adicione a linha do modelo, e pronto. Vamos voltar à nossa estratégia. Se quiser usar o gerenciador de conversas com resumo, essa é a única linha que você pode adicionar a esse loop do agent. Você tem a taxa de resumo, que, neste caso, é de 50%, e quer preservar as últimas quatro mensagens. Então, toda vez que invocar esse agent nesta sessão, a sessão vai gerenciar sua context window dessa maneira. Ela

06:26 vai manter as quatro últimas mensagens e resumir os outros 50%. Sim, isso é incrível. Mas o que acontece quando você tem muita memória e não quer perder toda a memória dentro dessa context window? Bem, sempre temos a memória de curto prazo, que é o histórico recente da conversa. Então, você pode usar essa aplicação com memória de curto prazo. Mas o que acontece

07:00 quando você quer voltar e tem uma nova sessão para esse agent, sem memória de curto prazo? Você pode ter memória de longo prazo e criar um banco de dados vetorial para ela. Você pode ter diferentes tipos de memória nesse banco de dados vetorial, com diferentes prompts que entendem sua conversa e fazem o que você quiser. A terceira é a memória relacional. Você pode usar um grafo de entidades. Você pode falar com o pessoal da Neo4j, que pode explicar mais sobre isso. Você pode usar

07:33 percursos baseados em como as coisas se conectam. Assim, você pode entender e usar uma combinação dessas três opções. Pode ter memória de curto e longo prazo para a sessão que está usando. Depois, pode recuperar a memória do passado, a memória de longo prazo. E, se houver alguma relação que você queira manter de outra maneira, também pode adicionar uma memória em grafo. Vamos continuar com a outra opção. O que acontece com essa aplicação

08:04 que tem muitos logs, como eu disse? Você não quer colocar esses logs na context window toda vez que invoca a aplicação agêntica, esse agent. Você pode salvá-los em um ponteiro de memória. Como isso funciona? Você tem as ferramentas. Uma ferramenta retorna um monte de logs. Você pode usar outra ferramenta capaz de pegar esses logs e salvá-los em um armazenamento. Ela vai retornar um ID para esse armazenamento e, usando o

08:38 Strands, você pode fazer isso com o estado do agent. No estado do agent, você vai ter todas as informações das ferramentas. Depois, pode usar outra ferramenta capaz de entender esses logs e enviá-los — ela vai enviar ao agent: “Pronto, os logs; você não precisa dos logs para entender isso.” Mas, se precisar dos logs, pode dizer: “Este é o meu ID. Recupere os logs, porque preciso saber.” Isso é algo que você pode criar na sua arquitetura. É algo assim: você pode

09:13 ter duas ferramentas diferentes. É assim que criamos ferramentas no Strands: apenas com o decorador de ferramenta. Temos a ferramenta fetch application logs e, como você pode ver, ela recebe tool context, agent e step state. Recuperamos essas informações e as salvamos em um ponteiro de memória. Criamos um ID de ponteiro de memória que será preservado dentro da nossa context window. Mas e se sua aplicação for supercomplexa e as ferramentas não forem suficientes? Você pode usar

09:47 Ah, se eu me esqueci de mencionar, você pode usar uma aplicação multiagente. Então, pode criar um swarm com vários agents, mas compartilhar a context window entre eles é como adicionar lixo para os outros agents, porque nem todos precisam das informações uns dos outros. Você pode compartilhar as informações usando um ponteiro para o estado da invocação. Assim, pode criar um ID entre esse swarm de agents.

10:23 …do swarm, e você pode compartilhar o ponteiro de memória entre os estados de invocação desses agents. E é assim que criamos o swarm em um agent do Strands. Meu Deus, faltam 9 minutos. Vou ser rápida. E a próxima coisa é: o que acontece quando o mecanismo nunca quer parar? Às vezes, temos esse mecanismo que fica em loop para sempre, invocando a mesma tool repetidamente, e isso

10:58 nunca acaba. Então, você pode interromper isso definindo um número máximo de invocações dentro do loop. Qual é o problema? Eu disse que o problema é que a tool pode estar disponível. Então, o que acontece quando você não tem uma resposta clara ao invocar a tool? Você pode evitar isso com uma resposta clara da tool e com um limite de invocações para ela. E faz assim: você define um número máximo de chamadas à tool. Neste exemplo,

11:32 minhas tools são search flight. Você só pode invocar essa tool três vezes. E a outra tool também, três vezes. Assim, o agent não vai entrar nesse loop interno. Ele só vai invocar essas tools três vezes. E a última — sim, estou quase terminando — é algo que não ajuda a context window diretamente. É algo que você pode usar para ajudar sua context window, porque às vezes nós

12:08 invocamos tools MCP ou usamos MCP, ou temos uma API externa que não responde no momento em que precisamos. Às vezes, por exemplo, temos o AWS API Gateway, que tem um tempo máximo para receber a resposta. Então, se você não tiver esse tempo, o atraso pode fazer sua aplicação parar. Você pode evitar isso usando uma abordagem assíncrona.

12:38 Quando você usa uma abordagem síncrona, seu mecanismo vai esperar para sempre pela resposta do seu MCP. Mas, se você tiver um manipulador assíncrono, poderá invocar seu MCP ou sua API externa, salvar a solicitação e recuperar a resposta na próxima invocação ou quando precisar dela. Sim, isso depende do caso que você está desenvolvendo. Você pode fazer assim: criar o MCP. Esta é uma função que usa FastAPI, e com o FastAPI você

13:12 só precisa criar as tools. Então, vou ter duas tools diferentes: uma é start job e a outra é check job status. Fiz muitos testes usando esse manipulador assíncrono, e a diferença é grande. Por exemplo, com essa abordagem, o agent nunca para de me responder. Como eu espero, ele pode recuperar as informações. Para encerrar esta sessão — faltam seis minutos —, nós

13:45 temos os pontos principais. Então, evite encher o contexto. Não precisa incluir tudo e mais um pouco na context window, sabe? O mecanismo não precisa de todas as informações. Você pode compartilhar apenas o que é necessário para criar a resposta que o usuário pediu. Você pode usar a sumarização nativa. Às vezes, quando você usa a sumarização nativa, o

14:17 agent pode esquecer o que você precisa. Se você fizer qualquer tipo de sumarização, talvez ela não inclua tudo de que o mecanismo precisa para responder. E, quanto ao preenchimento do contexto, novamente: não passe tudo para o agent. Ele não precisa de todas essas informações. E o que é bom fazer aqui? Se uma tool retornar muitos dados, como logs, dados de banco de dados ou informações de alertas, externalize esses dados,

14:50 selecione o que usar e use um ponteiro de memória. Muitos mecanismos precisam dos mesmos dados volumosos. Você pode compartilhar informações de invocação entre etapas e loops de agents ou manipuladores de tools. Você pode ter instruções mais claras — sabe, fornecer uma resposta clara para a tool —, limitar o número de chamadas e usar um manipulador assíncrono. Obrigada. E, claro, se quiser saber mais sobre Strands, temos um estande enorme

15:21 lá. Temos muitos brindes. Temos uns Legos da Amazon que vocês podem levar. Vejo vocês lá. Temos especialistas, e eu sou Elizabeth No Morgan, lembrem-se. [risos] Muito obrigada. >> [música]

Transcrição original

[00:12] Hi. Well, first I have to say I am Elizabeth. I am not Morgan. But the guy for the agenda they never change agenda. So we are almost the same but with different colors hair. Okay. So it’s it’s going to be similar. So today I going to talk about the infinite content window is a meet. Yes. Yes is because right now edge system breaks when tools returns a large amount of data. Context

[00:48] window overflow and the engine start to hallucinate and start the recar is degrad. So right now context engineering help us to uh give us a better architecture for this agent application. So we have some techniques that allows us to improve the context the context window for this agentics application. So imagine that you have a agent that is responsible to uh supervise some

[01:21] application. So this agent they have to retrieve log logs for that application. So every time this agent is doing the retrieve for the logs is putting data for the content window and every time this content window is going to grow. It’s going to grow every time because when we have a one session and each session is going to retrieve the last session because it’s going to remember everything. That’s the way that agents remember and they use the content window

[01:52] for that. In the past about probably one year ago before this agentic era we saw that just add more token that will fix it. Yeah, there’s more bigger content window that is going to fix it. And today we know that is not true because we have the uh attention you curve. What is this? We have a lot of data, but if that data is super super big, the engine is going to forget the meter in the in

[02:28] the in the curve. It’s only going to remember the first part and the last part that we sent to that content window. And I’m talking here about context engineering. But I can move. But content engineer is giving the model the information it needs when it needed. Sometimes the agent doesn’t need all the information inside that content window. Sometimes the content window is poison the engine because you can have a problem injection inside your content

[03:01] window and the content engineer help us to incorout the context window for optimal outcomes and token consumption. So today I going to show you some techniques that can help you to improve the content window. And these techniques uh I manage for a strategy. We have we have the externalize because move this that this big data to a persistent storage. You can create a memory pointer

[03:34] to storage that data. I going to share the deck at the end. So you need to you don’t need to have to. Please pay me attention and because I going to share you all the information that I going to talk share. And the second one is select you can retrieve only what is relevant. We have compress that reduce token because you can summarize and you can compact that information. And the last one is isolate because you can separate context across agents. and let’s start.

[04:09] So the starting point conversation manager this strategy yeah we have some strategy that are a little complicated but we are going to start for the easy one that we can use inside the framework. So here in this strategy we are going to use a strand engine is a framework like we are a we maintain is completely open source yes it’s free and is a yeah it’s open source free hence

[04:39] it’s completely model and so here with strands you can use three different strategy inside the framework so we have sliding window that allows you to keep only the most recent messenger we have summarization inside the framework that allows you to summarize all their messenger and keep present one and the last one is a combination of two we have that you can combine summarize of older messenger with resent one so first let’s see what is a strand a strand is this so

[05:16] you only need one line of code to create the agent loop so this line here create all the agent loop behind the scene. You need to create the nose, the graph, nothing because the strands can do that for you and you have the system prom and the tools. And yes, this is simple because it’s using Amazon better behind the scene. But if you want to use Lamba uh Gemini and tropics, you only need to add one line because you can do that. You import the the library for OpenAI

[05:51] for example and then you add the model line and that’s it. So let’s return to our strategy. If you want to use summarization conversation manager that’s the only line that you that you can add for this agent loop. So you have the summary radio that is in this case is 50% and you want to preserve preserve the last four messages. So every time that you invoke this agent in this session, this session is going to manage your content window in this way. So it’s

[06:26] going to keep the four last messages and it’s going to summarize the other 50%. And yes, this is amazing. But what happen when you have a lot of memory and you don’t want to lose you don’t want to lose all the memory inside that content window. So you can use well always we have shortened memory because shortterm memory is when you have the recent conversation history. So you can use this uh application in the shortterm memory. But what happen

[07:00] when you want to return and uh you for you uh you have a new session for this agent and you don’t have short-term memory. You can have long-term memory and you can create a vector database for that long-term memory. You can have different types of memory inside that vector database with different prompts that can understand your conversation and say whatever you want. And the third one is relation memory. You can use entity graph. You can go to the uh to the guy for neo forj that they can explain you more about that. You can use

[07:33] traversal baset or how things connect. So you can understand you can use a combination of three of those. You can have long short-term memory for the me the session that you have. Then you can retrieve the memory that is in the past the long longterm memory and if you have some relation thing that you want to keep in a different way you can add for that a graph memory as well. Let’s continue with the other one. So what happened with this application

[08:04] where a lot of logs that I told you you don’t want to put that locks inside your content window every time that you invoke the agentic application that agent you can save that inside a memory pointer. So what how this work? You have the the tools. The tool returns you and a bunch of uh logs. You can use another tools that is going to capable to took that logs and save that logs in a storage and you are going to retrieve an ID for that storage and for that using a

[08:38] strands you can have that using the agent state. In the agent state you are going to have all the information for the tools. Then you can use another tool that is going to capable to understand that logs and it’s going to send um it’s going to send to the agent hey the logs okay you don’t need the logs to understand that but what happen is you need the logs you can go say hey this is my ID come on retrieve the logs because I needed to know so this is something that you can build in your architecture and it’s something like this you can

[09:13] have two different tools that’s the way that we create tools inside the trans only with the tool decorator. So we have fetch application logs and if you can see there you have the tool context agent step state. So we retrieve that information and we save that in a memory pointer. We create a memory pointer ID that is going to preserve inside our content window. But what happened is your application is super complicated and the tools is not enough. You can use

[09:47] ah if I forget that you can use a multi- aenting application. So you can create a a trans swam with multi- aents but you share the context window between agents is like add garbage to the other agents because no all the agents need the information between them. So you can share the information between the invocation state pointer. So you can create an ID between that swam agent

[10:23] swam and you can share the memory pointer between the the invocation state between that aents and that’s the way that we create the swamp in a strand agent and oh my god 9 minutes I going to be fast and the next one is where the next one is what happened when the engine uh want to stop never in sometimes we have this engine that stay in the loop like forever invoking the same tool the same tool again and it’s

[10:58] never ending so you can stop that with a minimum amount on invocation inside the loop so what is the problem I said the problem to sell more soul may be available so what does happen when you not when you you don’t have a clear response when you evolve the tool So you can avoid that with the tool way with the clear response and with amounts of invocation for the tool and you do like this. So you have a limited tool count. So you set max tool counts for this

[11:32] example is my tools search fly. You can you only can invoke that tool three times and the other tool. Yeah. Three time as well. So the agent never is going to do to do this uh internal loop. It’s only going to invoke that tools three times. And the last one, yes, I almost there. The last one is uh is not something that help you to the context window. is something that you can use to help your content window because sometimes we are

[12:08] invoking IMCP tools or IMCP or we have external API that never answer you at the time that you need it. Sometimes for example we have EP gateway AWS EP gateway it have a a maximum time that is going to receive the the answer. So if you don’t have that time, it’s going to uh like stop your application because the delay. So you can avoid that using a a synchron.

[12:38] So when you use synchronous, your engine is going to wait forever for the answer for your NCP. But if you have an a sync handle, you can invoke your NCP, your external API. So then you can save that and you can retrieve the answer in the next invocation or when you need it. Yes, this is going to depend of the case that you are building and you can do that like this create MCP this is a function that use fast API and with fast API you

[13:12] only need to create the tools. So I going to have two different tools. One is the star lob and another one is check job status and I did a lot of test using this uh a sync handle and the different is a lot. For example, if you have the different um the well the agent never stop to answer me. So because I wait then he can retrieve the information and to close this session six minutes we

[13:45] have the antipartis so why uh you have to avoid you have to avoid contact stuffing so you need you don’t need to include everything and the kitchen you know you don’t have to include everything the content window because the engine doesn’t need all the information there you can only share what a need to create the answer that your user or you’re asking for. You can have uh native summarization. Sometimes when you do native summarization, the

[14:17] agent uh can uh you can uh forget what you need. If you’re doing whatever superization what you may for probably in that summarization, you are not going to have everything that the engine is needed to answer you. and context population. Again, don’t pass everything to the agent. The agent doesn’t need all that information. And what is a good scene here? So tool returns large data, logs, database, alert information, externalize,

[14:50] select and use a memory pointer. Many engines need the same large data. You can share invocation between stage and agent loops or tool hands. You can have clearest st you know give a clear answer for the tool and limited to counts and a thin handle. Thank you. And of course if you want to learn more about stringent we have a huge boot

[15:21] there. We have a lot of swag. We have a little Legos for Amazon that you can have and see you there. We have the specialist and I am Elizabeth No Morgan remember. [laughter] Thank you so much. >> [music]