desabafo aleatório sobre onde estamos com agentes de IA:

alguns não os chamam de agentes, mas "agentes de fluxo de trabalho" com fluxos determinísticos estão em toda parte e funcionam. qualquer um pode construir agentes de fluxo de trabalho simples, mesmo começando com ferramentas sem código como Zapier e n8n. agentes de fluxo de trabalho complexos exigem muito mais reflexão para serem construídos de forma confiável e eficiente. um fluxo de trabalho complexo para um caso de uso comum e valioso, com integrações relevantes incorporadas, pode se sustentar como um negócio, e também ser uma ótima estratégia de entrada no mercado para expandir mais tarde para outros fluxos de trabalho ou trabalho mais autônomo.

agentes mais dinâmicos/autônomos estão começando a trabalhar e são úteis para pesquisa (especialmente se baseados na web) e programação. menos confiáveis uma vez que você começa a adicionar mais fontes de dados (por exemplo, APIs). agentes somente leitura parecem seguros e fáceis de testar, mas deixar agentes autônomos tomar ações (escrever) é assustador. (ideia aleatória sobre isso: seria legal se ferramentas como um CRM permitissem que você "forkasse" um espelho de desenvolvimento e executasse experimentos de automação que você pudesse reverter ou mesclar de volta.)

agentes dinâmicos funcionam bem quando podem (1) criar e acompanhar um bom plano e (2) executar tarefas corretamente, enquanto (3) encontram o contexto certo para alimentar cada etapa (tanto o planejamento quanto cada tarefa). finalmente, precisa (4) refletir ao longo do caminho (com ou sem input humano) para que possa ajustar o plano de forma apropriada e também melhorar a forma como executa tarefas falhadas ou de baixo desempenho.

planeamento de tarefas: as capacidades de raciocínio dos LLM funcionam bem para listas de tarefas simples que não requerem contexto privado (como pesquisa aprofundada, apenas uma série de pesquisas na web enquanto resumem). se você quiser pesquisar muitas entidades, a pesquisa aprofundada não funciona tão bem porque a gestão da lista de tarefas é relativamente básica. ferramentas de IA baseadas em folhas de cálculo funcionam melhor para pesquisar muitas entidades porque você está efetivamente transferindo a gestão de tarefas para a folha de cálculo, já que passar longas listas de tarefas entre prompts não funciona aqui. a gestão de tarefas em agentes de codificação funciona com problemas simples, código simples, ou quando você está começando do zero. uma vez que você entra em projetos pré-existentes mais complexos, eles são menos confiáveis - e os desenvolvedores aumentam a confiabilidade documentando como seu código funciona e está organizado (arquivos .md), o que permite que o agente construa listas de tarefas mais bem informadas. código complexo requer mais documentos e, eventualmente, puxar dinamicamente apenas o contexto relevante desses documentos. muitas pessoas/empresas têm opiniões fortes não documentadas sobre a ordem/abordagem/ferramentas corretas para abordar um projeto, e precisamos de mais abordagens para documentar isso de forma antecipada e em tempo real. outra razão pela qual agentes de codificação e pesquisa na web funcionam bem é que todos eles usam o mesmo conjunto de ferramentas, portanto, não há necessidade de "aprender" a usar essas ferramentas (mais sobre isso a seguir).

execução de tarefas: as tarefas são geralmente chamadas de API (exigindo autenticação e compreensão de como usar a API e a estrutura de dados subjacente - que pode ser única, como em um CRM ou banco de dados com tabelas/colunas personalizadas), raciocínio LLM (por exemplo, resumir), uma combinação, e até mesmo agentes de fluxo de trabalho*. um agente de pesquisa é realmente apenas uma busca na web e sumarização em um loop. agentes de codificação são CRUD na sua base de código, e talvez busca na web para aprender sobre APIs. autenticação e acesso básico à API parecem resolvidos (MCPs se encaixam aqui), mas eu gostaria de ver mais sobre o contexto específico da ferramenta (perguntar ao usuário, mas também analisar na conexão inicial, aprofundar-se nos dados existentes para entender como a ferramenta é usada, como os dados são estruturados, quais cenários/projetos usamos a ferramenta). erros/reflexão/feedback precisam se transformar em aprendizados organizados que sejam alimentados de volta como contexto quando relevante. as mesmas ferramentas podem ser usadas para diferentes propósitos e de diferentes maneiras entre organizações e precisamos capturar/documentar isso de alguma forma para executar as tarefas bem.

contexto: imagine ser um novo funcionário numa empresa. você aprende muito durante a integração (e quanto melhor a integração, mais eficaz você é desde o início), e depois há o aprendizado no trabalho, que se divide em aprender com a experiência da organização ("é assim que fazemos as coisas") e aprender com a própria experiência - o primeiro é mais predominante em grandes organizações. a gestão de contexto é semelhante. existem camadas de contexto como meta (usuário/empresa), específico de projeto/departamento, específico de tarefa, específico de ferramenta, etc. evoluímos de simples prompts de sistema para estratégias híbridas de RAG (vetor, palavra-chave, gráfico), mas além de ter os dados/contexto, precisamos de orientação sobre quando e como recuperar o contexto, o que vemos nas versões iniciais de hoje - mas há muito espaço para melhorias. isso não é meramente um problema técnico, mas também uma questão de negócios - pois você basicamente precisa criar um documento de integração que cubra todos os cenários que espera. à medida que os projetos se tornam mais complicados, é necessário mais cuidado para podar corretamente o contexto, de modo que apenas as informações relevantes sejam incluídas no prompt, minimizando o contexto irrelevante.

reflexão: temos ferramentas de monitoramento de agentes que cobrem custos de LLM/api, observação, mas atribuir sucesso/fracasso é um desafio - uma área onde os agentes de codificação têm uma vantagem sobre os outros é uma maneira determinística de notar falhas (através de testes do código). para muitas outras tarefas agentivas, ainda estamos descobrindo a maneira certa de coletar input humano para melhorar a saída futura. até onde sei, a reflexão hoje é com humanos no loop, onde o feedback está sendo amplamente alimentado a desenvolvedores humanos para melhorar o agente, mas a chave vem quando descobrimos como transformar a reflexão em autoaperfeiçoamento - onde o agente tira insights de falhas na geração de listas de tarefas e execução de tarefas para fazer melhor na próxima vez. basicamente, a reflexão precisa se transformar em um contexto bem organizado que pode ser puxado para os prompts quando e somente quando relevante. isso evolui para o ajuste fino de partes do agente, e então ambientes de RL agentivos - ainda parece bastante cedo aqui.

*anteriormente mencionei a delegação de tarefas a agentes de fluxo de trabalho, que começa a fazer sentido quando o seu agente se beneficiaria de não ter agentes de fluxo de trabalho como ferramentas (em vez de descobrir uma lista de tarefas conhecida a cada vez) ou quando o seu sistema é complicado o suficiente para que agentes especializados com contexto e ferramentas especializadas tenham um desempenho melhor. ou se você está aproveitando agentes construídos por outras pessoas (um padrão que comecei a ver aqui são endpoints de API de linguagem natural para facilitar a colaboração entre agentes).

se tivéssemos a qualidade do modelo de hoje com uma janela de conteúdo infinita (sem degradação na qualidade), computação infinita, armazenamento infinito, acesso via navegador e um método de pagamento, um único ciclo de LLM provavelmente seria suficiente para fazer muito o ponto do ponto sem sentido acima (nada é infinito) é que a orquestração de agentes é em grande parte sobre gerenciar limitações, arquitetando maneiras de descarregar trabalho do LLM através de estrutura e código.

os agentes em produção vêm em várias formas: como ferramentas internas, como um produto independente que combina várias ferramentas, e incorporados como uma funcionalidade a uma ferramenta central. eles podem ser genéricos ou especializados. agentes de chat, voz e de fundo parecem ser a interface de utilizador mais comum para acionar fluxos agentes.

o que mais estou a perder?