LangSmith Agent Builder é uma proposta de criação de agentes de IA sem código, construída para automatizar tarefas recorrentes do dia a dia por meio de linguagem natural. Em vez de exigir programação ou uma linguagem de configuração própria, a base do agente é descrita e evoluída com arquivos, o que torna o comportamento mais previsível, ajustável e fácil de manter.
Um elemento central dessa abordagem é o sistema de memória, pensado para que o agente aprenda preferências, regras e conhecimento útil ao longo do tempo. A memória não é tratada como um “truque” adicional, mas como uma parte estrutural que sustenta a consistência do agente entre sessões, reduzindo repetição e melhorando a qualidade de execução em tarefas repetidas.
O que é o LangSmith Agent Builder
O LangSmith Agent Builder é um construtor de agentes no-code, ou seja, sem necessidade de escrever código para montar e operar um agente. Ele é uma solução hospedada na web e voltada para pessoas com perfil técnico mais leve, que precisam automatizar fluxos específicos com rapidez. Em vez de ser um agente genérico que resolve “qualquer coisa”, ele é desenhado para configurar agentes com funções bem definidas e repetíveis.
Esses agentes costumam ser criados para rotinas como assistentes de e-mail, apoio à documentação, triagem de solicitações, preparação de resumos e outras atividades com padrões claros. Como a tarefa se repete, ajustes feitos hoje continuam valendo amanhã, e o sistema se beneficia muito de memória persistente. A proposta é permitir que o agente seja ajustado por conversa e vá se tornando mais fiel ao jeito esperado de trabalhar.
Criação de agentes usando linguagem natural
A criação é guiada por instruções em linguagem comum, reduzindo o atrito de configuração. Em vez de parametrizações extensas ou regras complexas, o agente recebe orientações que definem objetivo, estilo, restrições e critérios de qualidade. Essas orientações são registradas de forma estruturada em arquivos, para que o comportamento não dependa apenas do contexto momentâneo de uma conversa.
Essa estratégia favorece um ciclo iterativo: um agente executa uma tarefa, surgem correções, e essas correções viram parte da memória. A cada repetição, o agente reaproveita aprendizados anteriores e diminui a necessidade de reexplicar preferências. O resultado esperado é um agente mais estável, com menos variação e maior aderência ao processo definido.
Por que priorizar memória em vez de lançar sem ela
Em muitos produtos de IA, a memória aparece apenas depois, ou de forma limitada, porque a utilidade pode parecer incerta no início. Em um ambiente de agente generalista, sessões podem ser desconexas e a memória corre o risco de guardar algo irrelevante para a próxima tarefa. Já em agentes voltados para um único fluxo, a repetição torna o reaproveitamento de aprendizados muito mais valioso.
Nesse tipo de automação, a ausência de memória tende a causar um efeito cumulativo de frustração, porque as mesmas preferências precisam ser repetidas em várias sessões. A memória passa a ser parte do próprio “contrato” de qualidade do agente: o que foi combinado e corrigido deve continuar valendo. Por isso, a memória deixa de ser opcional e vira um componente de primeira linha.
O que “memória” significa em agentes: categorias principais
Para definir “memória” de forma objetiva, é útil separá-la em categorias, pois nem todo tipo de lembrança tem o mesmo propósito. A classificação mais usada nesse contexto separa memória em procedural, semântica e episódica. Essa divisão ajuda a projetar onde cada aprendizado deve ser armazenado e como deve ser aplicado.
As categorias abaixo organizam o que um agente precisa “saber fazer”, “saber sobre o mundo” e “lembrar do que aconteceu”. Essa distinção reduz confusão, evita armazenar tudo no mesmo lugar e melhora a manutenção do conhecimento. A lista a seguir resume essas três categorias de memória usadas no desenho do sistema.
- Memória procedural: regras e instruções que determinam o comportamento do agente, como formato de resposta, critérios e limites.
- Memória semântica: fatos e conhecimentos reutilizáveis, como definições, termos do domínio, políticas internas e vocabulário.
- Memória episódica: registro de sequências do comportamento passado, como conversas anteriores e decisões tomadas em contextos específicos.
Representação da memória como um conjunto de arquivos
A memória no Agent Builder é representada como um conjunto de arquivos, decisão intencional para aproveitar a familiaridade de um sistema de arquivos. Modelos de linguagem costumam lidar bem com estruturas de “pastas e arquivos”, lendo, comparando e atualizando conteúdos textuais com facilidade. Isso reduz a necessidade de ferramentas especiais só para editar memória, pois o próprio agente pode operar sobre arquivos.
Essa escolha também traz organização: cada arquivo pode ter uma responsabilidade clara, como instruções centrais, ferramentas disponíveis ou conhecimentos específicos. Além disso, arquivos favorecem portabilidade, auditoria e revisão humana, já que mudanças podem ser inspecionadas com facilidade. A memória vira um artefato estruturado, e não apenas um rastro implícito de conversas.
Arquivos principais e padrões usados na memória
Quando possível, são usados formatos reconhecíveis no ecossistema de agentes, porque padrões reduzem ambiguidade e facilitam migração para outros ambientes. O arquivo AGENTS.md concentra instruções centrais do agente e serve como referência primária de comportamento. Além disso, existem arquivos para skills (habilidades) e para descrição de ferramentas em JSON, o que dá previsibilidade a integrações.
Alguns arquivos seguem estruturas específicas para funcionar corretamente, como tools.json para ferramentas e arquivos de habilidades com metadados bem definidos. Também pode haver uma pasta de subagentes, que são agentes auxiliares com uma missão mais estreita e acionados quando necessário. Essa composição permite construir agentes mais complexos sem exigir uma linguagem de configuração proprietária.
Memória como “filesystem” virtual, armazenado em banco de dados
Apesar do modelo mental ser um sistema de arquivos, o armazenamento pode ser feito em um banco como Postgres, expondo os conteúdos “como se” fossem arquivos. Isso combina duas vantagens: para o agente, o acesso continua parecendo leitura e escrita em arquivos; para a infraestrutura, o armazenamento em banco tende a ser mais eficiente, gerenciável e consistente. Essa camada é um filesystem virtual, isto é, uma representação de arquivos montada sobre outro mecanismo de persistência.
Essa arquitetura é descrita como “plugável”, permitindo trocar o mecanismo de armazenamento por alternativas como S3 ou MySQL, sem mudar o conceito central. O agente continua operando no mesmo paradigma, o que preserva o comportamento e reduz impacto de mudanças internas. A memória, portanto, fica estável como interface, mesmo que a implementação varie.
Arquivos adicionais e escrita de conhecimento “no caminho quente”
Além dos arquivos centrais, o sistema permite criar e manter arquivos adicionais na pasta de memória do agente. Esses arquivos podem conter conhecimento arbitrário, como glossários internos, regras operacionais, exemplos aceitos e recusados, ou documentos de referência do próprio fluxo automatizado. O agente pode consultar esses materiais enquanto trabalha e também atualizá-los quando aprende algo novo.
As atualizações podem ocorrer “no hot path”, expressão que significa durante a execução normal do trabalho, em tempo real. Isso torna o aprendizado mais imediato, pois correções e refinamentos podem ser transformados em mudanças persistentes. Ao mesmo tempo, esse poder exige controles para evitar que o agente escreva informações incorretas ou em formato inválido.
Como os arquivos se conectam aos tipos de memória
Os diferentes arquivos se encaixam bem na separação entre memória procedural e semântica. A memória procedural tende a residir em arquivos que definem regras e capacidades, como AGENTS.md e tools.json. A memória semântica aparece em arquivos de habilidades e outros documentos que guardam fatos e conhecimento reutilizável.
Nesse desenho, a memória episódica não é priorizada inicialmente, porque muitos agentes do tipo “fluxo repetido” extraem mais valor de regras e conhecimento do que de históricos completos de conversas. Ainda assim, a ausência de memória episódica é reconhecida como uma lacuna funcional, especialmente para auditoria e para refinar decisões com base em contextos passados. Essa separação evita que o arquivo de instruções vire um depósito de tudo, mantendo coesão.
Exemplo de estrutura de memória em um agente de recrutamento
Um exemplo prático de organização é um agente voltado à busca e triagem de perfis, onde há instruções centrais, ferramentas para pesquisa e um subagente para executar uma parte repetitiva. A memória fica distribuída em arquivos com responsabilidades claras, em vez de um único texto longo. Isso ajuda o agente a “saber onde procurar” cada tipo de informação.
A estrutura abaixo ilustra como esses componentes podem aparecer na memória. Ela mostra arquivos para instruções do agente, um diretório de subagentes, configuração de ferramentas e documentos adicionais acumulados durante o uso. O conjunto expressa um agente que evolui com o tempo e mantém artefatos de trabalho de forma organizada.
- AGENTS.md: instruções centrais do agente, com objetivos, regras e estilo.
- subagents/: diretório com subagentes especializados, como um trabalhador de busca.
- tools.json: configuração de ferramentas disponíveis via MCP e seus limites.
- Arquivos adicionais: documentos do processo (por exemplo, descrições de vaga) que foram ajustados e mantidos durante o uso.
Como a edição de memória funciona: um exemplo concreto e progressivo
Um modo claro de entender memória é observar como pequenas correções viram regras persistentes. O ponto de partida é uma instrução simples, e o agente executa de um jeito que pode não ser o ideal. Uma correção vira uma modificação no arquivo de instruções, e a próxima execução já incorpora o novo padrão sem depender de lembretes repetidos.
O exemplo a seguir mostra uma evolução por semanas, em que preferências de formatação e extração de itens vão sendo acumuladas. A cada interação, o agente transforma feedback em regras explícitas, construindo um guia operacional. O bloco abaixo representa como o conteúdo do AGENTS.md pode crescer de maneira organizada ao longo do tempo.
Semana 1: instrução inicial no AGENTS.md: “Resumir notas de reunião.” O agente retorna em parágrafos; surge a correção para usar tópicos.
Semana 2: novo resumo já sai em tópicos; surge pedido para separar itens de ação ao final, e isso também vira regra.
Semana 4: as duas preferências passam a ser aplicadas automaticamente em reuniões diferentes.
Mês 3: o AGENTS.md já contém preferências por tipo de reunião, distinções conceituais e pessoas frequentes, consolidando um padrão estável.
Exemplo de AGENTS.md consolidado
# Preferências de Resumo de Reunião
## Formato
- Usar tópicos em vez de parágrafos
- Extrair itens de ação em uma seção separada ao final
- Usar passado para decisões
- Incluir timestamp no topo
## Tipos de reunião
- Engenharia: destacar decisões técnicas e justificativas
- Planejamento: enfatizar prioridades e prazos
- Cliente: remover informações sensíveis
- Reuniões curtas (< 10 min): apenas pontos-chave
## Pessoas
- Sarah Chen (Liderança de Engenharia): foco em detalhes técnicos
- Mike Rodriguez (Produto): foco em impacto de negócio
Aprendizados de construção: o desafio de “prompts” corretos
O principal fator de dificuldade em memória de agentes costuma ser o prompting, isto é, o desenho das instruções que orientam o modelo a lembrar e a escrever do jeito certo. Quando um agente lembra pouco, lembra demais ou lembra no lugar errado, frequentemente o problema não é “falta de IA”, mas sim uma regra mal especificada. Ajustes no texto de orientação tendem a corrigir grande parte de comportamentos inconsistentes.
Problemas comuns incluem o agente não registrar aprendizados relevantes, registrar detalhes irrelevantes, ou colocar tudo em AGENTS.md quando parte deveria ir para arquivos de habilidades. Outro ponto frequente é o agente não respeitar o formato esperado de certos arquivos. Por isso, o trabalho de prompting vira uma engenharia contínua para equilibrar utilidade, concisão e manutenção.
Validação de formatos: evitando arquivos inválidos
Alguns arquivos exigem estruturas rígidas para serem interpretados corretamente, especialmente arquivos JSON e arquivos com metadados específicos. Um risco é o agente produzir conteúdo sintaticamente incorreto ou fora do esquema esperado, quebrando ferramentas e fluxos. Para reduzir esse risco, entra uma etapa explícita de validação antes de efetivar mudanças.
Quando a validação falha, os erros podem ser devolvidos ao modelo para correção, impedindo que uma versão inválida seja “comitada” como memória. Essa abordagem cria um ciclo mais robusto: o agente tenta escrever, o sistema valida, e só então a mudança é aplicada. Esse mecanismo protege a integridade da memória e evita degradação acumulada ao longo do uso.
Adição é fácil, compactação é difícil: o crescimento da memória
Agentes costumam ser bons em adicionar informações específicas, porque isso é parecido com anotar uma exceção. Já a compactação, que é resumir, generalizar e eliminar redundâncias, tende a ser mais difícil para o agente fazer espontaneamente. O resultado pode ser uma memória que cresce com listas grandes e detalhes demais, reduzindo clareza e aumentando custo de contexto.
Um exemplo típico é armazenar uma lista de casos particulares quando seria melhor transformar a regra em algo mais geral. Em vez de guardar dezenas de remetentes a ignorar, uma regra pode virar “ignorar abordagens comerciais frias” e, se necessário, definir exceções. Sem compactação, a memória vira um acúmulo de remendos, o que atrapalha manutenção e previsibilidade.
Quando comandos explícitos ainda ajudam a gerenciar memória
Mesmo com edição automática de memória, há momentos em que instruções explícitas para “refletir e atualizar” são úteis. Isso ocorre especialmente ao final de uma execução, quando é possível capturar aprendizados que passaram despercebidos durante o trabalho. Também ajuda quando a memória ficou específica demais e precisa ser generalizada.
Nesse cenário, a ideia de um comando explícito para lembrar, como /remember, se encaixa como um gatilho intencional de consolidação. Em vez de depender apenas do comportamento automático, o comando induz uma revisão do que aconteceu e uma escrita mais organizada. Essa prática reforça consistência e reduz o risco de aprendizado incompleto.
Humano no circuito: aprovação antes de alterar memória
Alterações de memória podem ser sensíveis, porque definem comportamento futuro e podem introduzir regras perigosas ou equivocadas. Por isso, um modelo comum é o human-in-the-loop, ou seja, exigir aprovação humana antes de gravar mudanças. Esse controle ajuda a impedir que a memória seja alterada por instruções maliciosas ou por interpretações erradas.
Esse cuidado também reduz riscos associados a prompt injection, um tipo de ataque em que instruções escondidas tentam induzir o agente a agir contra o objetivo original. Ao submeter mudanças à aprovação, a memória passa por uma barreira de revisão. Ainda assim, pode existir um modo sem aprovação, às vezes chamado de yolo mode, que privilegia velocidade em cenários de menor risco.
O que essa memória habilita: experiência no-code mais escalável
Um problema recorrente em construtores no-code é a dependência de uma DSL (linguagem específica de domínio) que precisa ser aprendida e nem sempre escala com complexidade. Ao usar arquivos Markdown e JSON, a configuração fica em formatos familiares e mais fáceis de inspecionar. A memória, portanto, não é só “lembrar”, mas também um jeito de estruturar o agente sem linguagem proprietária.
Essa forma de organização tende a facilitar o crescimento gradual do agente, pois regras e conhecimentos podem ser adicionados em lugares previsíveis. Em vez de uma configuração monolítica, existe separação por responsabilidade. Isso melhora legibilidade, manutenção e evolução do comportamento, mantendo o espírito no-code sem perder potência.
Construção iterativa melhor: feedback vira configuração
Construir um agente costuma ser um processo iterativo, porque o comportamento real só aparece quando o agente executa tarefas concretas. Sem memória, cada iteração exige mudanças manuais na configuração, o que aumenta fricção e incentiva atalhos. Com memória em arquivos, o feedback em linguagem natural pode se transformar em ajustes persistentes, encurtando o ciclo de melhoria.
Essa dinâmica cria um caminho em que o agente “se calibra” com o uso, acumulando preferências e regras operacionais. Em vez de uma especificação perfeita no início, surge uma especificação progressiva, que reflete o histórico de correções. O resultado é um agente que tende a convergir para um padrão estável e alinhado ao fluxo automatizado.
Agentes portáteis: arquivos facilitam migração e reaproveitamento
Arquivos são naturalmente portáveis, porque podem ser exportados, versionados e transportados entre ambientes com relativa facilidade. Quando um agente é descrito por um conjunto de arquivos bem definidos, fica mais simples reproduzir o mesmo comportamento em outro executor compatível. Isso reduz aprisionamento em uma plataforma e melhora longevidade do agente.
Quanto mais a estrutura segue convenções consistentes, menor o esforço de migração. Mesmo quando não existe um padrão universal para tudo, usar formatos similares aos já conhecidos diminui o custo de adaptação. A memória como arquivos também facilita auditoria, pois o estado do agente pode ser inspecionado como um conjunto de documentos.
Direções futuras: memória episódica e conversas como arquivos
Uma evolução natural é adicionar memória episódica, registrando sequências de comportamento e conversas anteriores de forma consultável. Um caminho prático é expor conversas passadas como arquivos no filesystem virtual, permitindo leitura e sumarização seletiva. Isso ajuda em cenários onde o contexto histórico muda decisões ou onde é preciso justificar por que uma regra foi criada.
Esse tipo de memória também pode apoiar depuração do agente, análise de consistência e melhoria de políticas. Ao mesmo tempo, aumenta o volume de dados e exige governança, como limites de retenção e filtros de sensibilidade. Por isso, a implementação tende a exigir critérios claros de o que armazenar e como indexar.
Processos de memória em segundo plano: reflexão fora do hot path
Quando toda atualização acontece no hot path, o agente pode perder oportunidades de aprendizado por estar focado em completar a tarefa. Um processo em segundo plano, executado periodicamente, pode revisar conversas e consolidar memória com mais calma. Esse processo é frequentemente descrito como um cron job, isto é, uma rotina agendada para rodar em intervalos fixos.
Essa reflexão posterior tende a ser útil para generalizar aprendizados, detectar padrões e eliminar redundâncias. Também ajuda a capturar detalhes que passaram despercebidos durante a execução principal. O efeito esperado é uma memória mais limpa e mais útil, com regras menos fragmentadas e mais bem organizadas.
Busca semântica na memória: além de grep e padrões
Buscar em arquivos com correspondência literal, como por nomes e termos exatos, é simples e eficaz em muitos casos. Ainda assim, há situações em que a informação está escrita com outras palavras, e a busca literal falha. A busca semântica resolve isso ao procurar por significado, e não apenas por texto igual.
Com busca semântica, o agente pode encontrar conteúdos relacionados mesmo quando não existe coincidência direta de palavras. Isso tende a melhorar recuperação de conhecimento em memórias grandes e heterogêneas. Ao mesmo tempo, introduz complexidade, pois exige indexação e mecanismos de similaridade, além de cuidados com precisão e custo.
Níveis diferentes de memória: agente, usuário e organização
Um limite comum de memórias isoladas é que tudo fica preso ao agente específico. Em ambientes com várias pessoas e vários agentes, faz sentido separar memórias por escopo: o que é preferência pessoal, o que é padrão de equipe e o que é regra do agente. Essa separação pode ser representada por diretórios distintos no filesystem virtual.
Com essa estrutura, o agente pode consultar primeiro políticas de organização, depois preferências do usuário, e por fim regras específicas do agente. Isso melhora consistência entre agentes e reduz repetição de configuração. Também facilita governança, pois políticas globais ficam centralizadas e menos sujeitas a alterações acidentais.
Conclusão
O sistema de memória no LangSmith Agent Builder organiza comportamento e conhecimento em arquivos, aproximando a operação do agente de um modelo compreensível e inspecionável. A separação entre instruções centrais, ferramentas, habilidades e arquivos adicionais permite que o agente evolua por correções e se torne consistente em tarefas repetidas. A escolha de um filesystem virtual apoiado por banco de dados combina facilidade para o modelo com eficiência de infraestrutura.
Os aprendizados de implementação destacam que o sucesso depende de prompting bem feito, validação de formatos, compactação de memória e controles como human-in-the-loop. A memória habilita uma experiência no-code mais escalável, facilita iteração e aumenta portabilidade do agente como conjunto de arquivos. As direções futuras apontam para memória episódica, processos em segundo plano, busca semântica e níveis de memória por escopo, completando o ciclo de um agente que aprende, consolida e mantém estabilidade ao longo do tempo.