monday.com detalha harness que mantém agentes confiáveis em produção

{"resumo": "## O que é um harness\n\nO texto parte de uma analogia com boliche: a tarefa é a bola, o LLM é a superfície da pista e o harness são as tabelas laterais que impedem que a bola caia na canaleta. Sem elas, um arremesso ruim vira citação alucinada, saída malformada ou um loop descontrolado que consome o orçamento. Jogar sem limites pode até acertar o alvo, mas não de forma garantida - e em fluxos agênticos de produção a empresa quer que isso seja garantia.\n\nO monday.com relata que, ao construir o feedAgent, identificou três pontos principais de falha: dados e contexto (o que entra no agente e o que ele sabe sobre o mundo em que opera), fluxo do agente (o fluxo em si e seus limites) e loop de feedback (como ele melhora). A empresa afirma que existem harnesses fortes no mercado, mas defende que adotar um exige conhecê-lo bem, entender o domínio de negócio e enriquecê-lo com necessidades específicas. Foi o que fez: usou a arquitetura de agentes da LangChain com o harness embutido e construiu em volta o seu próprio harness, específico do negócio.\n\n## O caso feedAgent\n\nUm workspace é um espaço compartilhado de projeto em que pessoas e agentes colaboram. O feedAgent monta um feed de atividades personalizado para cada membro, decidindo o que destacar entre tudo o que acontece ao redor, garantindo que o feed seja preciso, acionável, atual e confiável. O caso é descrito como útil por combinar restrições: o agente raciocina em loop, chama ferramentas e decide quando terminou; busca dados reais de várias fontes; sua saída precisa ser estruturada e ancorada - cada item cita as atividades específicas que o originaram - e é o que os usuários de fato veem e sobre o que agem. O desafio é extrair apenas o mais importante de um volume enorme de dados de atividades em quadros, documentos, execuções de agentes e assim por diante.\n\nO método adotado foi “percorrer o fluxo”: revisar cada fase da execução, entender os caminhos possíveis e, em cada passo, perguntar o que pode dar errado ali e o que o harness faz a respeito. Segundo o texto, isso respeita o fato de que um agente não é um pipeline, mas um loop complexo, diferente para cada feed.\n\n## Antes da invocação do agente\n\nA primeira fase é a recuperação de dados e a montagem do prompt: um prompt de sistema com contexto da tarefa, do fluxo e do que é considerado sucesso, seguido dos dados do feed - atividade de usuários em diferentes ativos, atividade de agentes, itens de feed já existentes. O modelo só recebe o que o harness decide expor.\n\nTrês mecanismos aparecem aqui. O pré-processador de atividades reduz tokens de entrada mantendo os dados importantes, tanto por gestão de contexto quanto por custo: colapsa rajadas de eventos de usuários e agentes em eventos únicos, mantém apenas mudanças agregadas relevantes e descarta ruído de configuração; essa etapa é determinística e também remove dados pessoalmente identificáveis antes que o LLM os veja. O sistema de aliases substitui IDs brutos por aliases curtos e cria uma superfície de detecção de alucinação, de modo que referências inventadas pelo modelo sejam capturadas e descartadas. Por fim, o cache de prompt no gateway de IA faz o prompt de sistema ser transmitido uma vez, com chamadas seguintes dentro da janela de cache pagando uma fração do custo.\n\n## Durante a execução\n\nNa inicialização, o modelo é instanciado com configuração de runtime (nome do modelo, temperatura, limites de tokens), as ferramentas são conectadas, o prompt de sistema é anexado e a pilha de middleware é aplicada. O harness define aí as capacidades e restrições do agente.\n\nO schema de saída obriga o modelo a emitir a resposta por meio de uma chamada de ferramenta validada por schema, em vez de confiar que ele produza JSON válido - a diferença, diz o texto, entre um contrato e uma esperança. Se o schema falha, há nova tentativa com o erro de validação anexado como contexto. Um limite de chamadas ao modelo, usando o modelCallLimitMiddleware da LangChain com exitBehavior “end”, impede execução indefinida e dispara parada segura em vez de falha não tratada.\n\nDentro da execução, um limite de recursão limita quantas iterações do grafo podem ocorrer, separado do limite de chamadas ao modelo: o modelo não pode ser chamado mais de N vezes e o loop não pode ciclar mais de M vezes. Toda execução resolve de forma limpa - com saída validada ou com a falha capturada e registrada, sem chegar ao usuário.\n\nQuanto às ferramentas, cada uma é um ponto potencial de falha. O texto descreve padrões: não dar ao agente a opção de escolher uma ferramenta indispensável, separando-a da execução e adicionando-a depois no fluxo para garantir que aconteça; restringir ferramentas e permissões às ações necessárias; escrever mensagens de erro acionáveis, que instruem o modelo sobre como agir na falha, em vez de apenas sinalizar erro; e gerenciar o ciclo de vida das ferramentas, garantindo o fechamento de conexões independentemente de como a execução termina.\n\n## Depois da execução\n\nAo terminar, o agente devolve itens novos de feed e atualizações, cada um citando os aliases usados como evidência. O harness então filtra alucinações: tudo que não resolve para um ID de atividade válido é descartado e registrado. Também aplica deduplicação, já que a mesma atividade não pode aparecer em dois itens; quando o modelo agrupa o mesmo evento duas vezes, um sistema de prioridade o mantém no item mais relevante, controlado por um conjunto que rastreia todos os IDs resolvidos na saída.\n\n## Observabilidade, aprendizado e avaliações\n\nA invocação inteira é envolvida em traceable(), com o LangSmith capturando cada passo intermediário: chamadas de ferramentas, respostas do modelo, contagem de tokens e cadeias de raciocínio. Um evento-resumo é disparado em toda execução, com sucesso ou falha, carregando duração, contagens de atividade, número de itens de feed, nome do modelo, trajetória de chamadas de ferramentas e detalhamento do comprimento do prompt.\n\nO Feed Memory fecha o loop entre execuções: sinais comportamentais de como os usuários interagem com o feed voltam à entrada do agente na execução seguinte. Regras explícitas dadas pelo usuário são convertidas por um extrator de chat em regra estruturada de alta autoridade, aplicada deterministicamente antes da curadoria. Observações inferidas vêm de um agregador que lê padrões em descartes, cliques em chamadas de ação e tempos de permanência; têm autoridade menor, são fornecidas como contexto leve, informam decisões limítrofes e nunca sobrepõem regras explícitas.\n\nAvaliações são feitas em dois níveis. Offline, com um conjunto de dados continuamente enriquecido com casos vistos em produção, um LLM como juiz com métricas específicas por parte e execução no CI para evitar regressões antes do deploy. Online, com análise contínua de dados de produção para detectar problemas e sugerir correções, com métricas semelhantes sobre dados em tempo real. Nos dois casos, a empresa usou habilidades e infraestrutura internas do monday.com.\n\n## Conclusão\n\nAs tabelas laterais não garantem um strike, mas garantem que a bola permaneça na pista em toda execução e para todo usuário. Segundo o texto, o padrão que se repetiu ao longo do fluxo é que os modos de falha não estavam no modelo, e sim nas premissas construídas ao redor dele: o que entra no prompt, o que limita a execução, o que é verificado antes da saída chegar ao usuário e o que é lembrado para a próxima vez não são trabalho do modelo - são trabalho do harness.", "hook": "O monday.com descreve como construiu um harness em volta de um agente que monta o feed de atividades de cada membro de um workspace, depois de adotar a arquitetura de agentes da LangChain e estendê-la com regras próprias de negócio. O texto identifica três pontos de falha - dados e contexto, fluxo do agente e loop de feedback - e detalha limites de chamadas ao modelo, schema de saída obrigatório, filtragem de citações inventadas e um sistema que aprende com o comportamento do usuário entre execuções.", "entities": ["monday.com", "LangChain", "LangSmith", "feedAgent"], "themes": ["agentes-e-automacao"], "story_key": "harness-feedagent", "reasoning": {"story_key": "O fato canônico é o harness que o monday.com construiu em torno do feedAgent para operar agentes em produção.", "themes": {"agentes-e-automacao": "O tema central é a construção de um harness para um agente de negócio em produção, com limites, schemas, tratamento de ferramentas e aprendizado entre execuções - agentes fora do escopo de código."}, "entities": {"monday.com": "Organização que construiu e relatou o harness e o feedAgent.", "LangChain": "Fornece a arquitetura de agentes e o middleware de limite de chamadas usados como base.", "LangSmith": "Ferramenta citada como responsável pelo rastreamento das execuções do agente.", "feedAgent": "Agente específico cujo harness é o objeto do estudo de caso."}, "excluded": {"Kamie Shami-Schnitzer": "Autora do texto, não sujeito do fato.", "monday.com blog": "Veículo que publica a evidência, não sujeito adicional.", "economia-de-tokens": "O cache de prompt e a redução de tokens aparecem como técnica pontual do harness, não como o fato ou tese central.", "pesquisa-e-benchmarks": "As avaliações descritas são controle de qualidade do próprio produto, não medição ou pesquisa de modelos."}}