Por que você deveria criar agentes por conta própria

• Agentes LLM são uma estrutura tecnológica que faz mais sentido quando você implementa na prática, em vez de apenas entendê-los como conceito
• Com apenas algumas dezenas de linhas de código Python, é possível criar um agente conversacional usando a OpenAI Responses API; ao adicionar a função de chamada de ferramentas (tool call), ele passa a agir de forma autônoma
• O núcleo de um agente é um loop de chamadas repetidas para um LLM sem estado, implementando conversas de múltiplas rodadas ao gerenciar diretamente o contexto da conversa (context)
• Context Engineering é um problema real no nível de tarefas de programação, exigindo um projeto que otimize entrada, saída e descrição de ferramentas dentro do limite de tokens
• Hoje, o design de agentes é um espaço aberto de problemas de engenharia de software, no qual até desenvolvedores individuais podem experimentar novas abordagens

---

A simplicidade de escrever um agente

• Um agente LLM pode ser implementado apenas com a OpenAI Responses API, sem configurações complexas
  • No código de exemplo, a conversa entre usuário e modelo é armazenada em uma lista context, que é reutilizada em chamadas repetidas para gerar respostas conversacionais como as do ChatGPT
• É possível simular uma conversa com múltiplas personalidades criando dois contextos, um com “boa personalidade” e outro com “má personalidade”
  • O LLM não tem estado, e a continuidade da conversa é mantida por um array de strings (context) gerenciado pelo usuário
• Mesmo só com essa estrutura simples, já é possível ter conversas de múltiplas rodadas e vivenciar diretamente como o LLM funciona

Integração de ferramentas e operação autônoma

• O agente pode ganhar uma função de verificação de conectividade de rede ao registrar uma função de ping como ferramenta
  • A OpenAI API exige a definição da ferramenta em formato JSON; quando o LLM solicita o uso da ferramenta, o código Python a executa e devolve o resultado
• Mesmo sem instruções explícitas, o LLM faz ping automaticamente em vários hosts (google.com, www.google.com, 8.8.8.8)
  • Isso mostra que o LLM foi capaz de fazer julgamentos autônomos apenas por ter “permissão para usar ferramentas”
• Todo o loop segue simplesmente a estrutura “pedido de chamada de ferramenta → execução → retorno do resultado”, tornando possível implementar um agente autônomo sem lógica de controle complexa

Aplicações reais e crítica ao MCP

• Embora o código de exemplo seja simples, ele pode ser expandido de forma prática ao combinar ferramentas adicionais (como traceroute) ou armazenamento de contexto com SQLite
• MCP (Multi-Context Protocol) é apenas uma interface de plugin de ferramentas para Claude Code ou Cursor, não uma tecnologia indispensável
  • Ao lidar diretamente com a API, é possível implementar a mesma funcionalidade sem MCP
• O MCP só é útil em ambientes onde você não tem controle sobre o código e pode, na verdade, limitar a flexibilidade da arquitetura do agente
• A segurança em LLMs é complexa, mas ainda assim é possível projetar estruturas seguras com contextos isolados e restrições de ferramentas

A importância da engenharia de contexto

• “Prompt engineering” é um conceito exagerado, mas engenharia de contexto é um problema real de programação
  • O número de tokens na janela de contexto é limitado, e entrada, saída e descrição de ferramentas ocupam esse espaço
  • Ao ultrapassar esse limite, a qualidade das respostas do modelo se torna instável
• Como solução, é possível criar subagentes (sub-agents) com contextos e ferramentas diferentes, projetando-os para resumirem e trocarem informações entre si
  • Essa estrutura pode se expandir para diversos experimentos, como redes de agentes em árvore ou compressão baseada em resumos em tempo real
• Mesmo ideias complexas mantêm um nível de simplicidade que permite implementação em cerca de 30 minutos

Problemas de engenharia em aberto e o valor da experimentação

• Atualmente, muitas startups estão desenvolvendo agentes para detecção de vulnerabilidades, e desenvolvedores individuais também podem fazer os mesmos experimentos
• O design de agentes inclui os seguintes desafios de engenharia ainda não resolvidos
  • equilíbrio entre não determinismo e programação estruturada
  • validação com a realidade (ground truth) e prevenção de encerramento precoce do loop
  • formatos de troca de dados entre agentes em múltiplas etapas (JSON, SQL, Markdown etc.)
  • alocação de tokens e controle de custos
• Esses problemas podem ser explorados não apenas em grandes pesquisas, mas também por meio de experimentos individuais, com cada iteração podendo ser tentada em poucas dezenas de minutos
• Em conclusão, a experiência de construir um agente com as próprias mãos é o ponto de partida para entender a tecnologia de LLMs

[GN⁺]

Comentários do Hacker News

• Há realmente muita coisa para fazer. Quero montar uma CPU com portas NAND direto numa breadboard e também queria fazer uma CDN em Rust, mas falta tempo
  Em vez disso, segui o tutorial do Karpathy e montei um LLM, e senti que ir experimentando aos poucos desse jeito é bem válido

  • Parece uma curva sem fim. Antes eu montei um computador de 8 bits numa breadboard, e desta vez acabei mergulhando em treinamento de voo (PPL)
    Toda vez que parece que “agora terminei”, dá a sensação de que a linha de chegada fica mais distante. No fim, acho que gente como nós simplesmente não é do tipo que fica totalmente satisfeita
  • No começo do TFA ele explica como isso pode ser feito com facilidade. Esse é justamente o ponto principal do texto

• O exemplo usa o GPT-5, mas a interface de consulta já está num nível de padrão da indústria
  Por exemplo, se você conectar o OpenRouter.ai, dá para trocar facilmente de modelo e de provedor em tempo de execução
  Também há modelos gratuitos, como o DeepSeek, mas são lentos e limitados. Ainda assim, são ótimos para experimentação

• Alguns meses atrás eu mesmo criei um agente em Ruby. Foi muito divertido
  A lógica central tinha só quatro linhas e, conceitualmente, era surpreendentemente simples

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• Há 2 anos eu fiz um agente em 25 linhas de PHP e, na época, ainda nem existia tool calling, mas funcionava muito bem
  Para mim, LLMs parecem ferramentas Unix de manipulação de texto, como sed ou awk — você dá uma entrada e um comando, e eles devolvem uma saída
  Quando você combina chamadas de LLM desse jeito e cria loops ou ramificações, o resultado vira um sistema bem poderoso
  Código relacionado: hubcap, llm

  • Gosto muito do hubcap. Mesmo com pouco código, o resultado foi impressionante
    Fiquei muito inspirado depois de ler o texto do Simon Willison

• A parte de criar você mesmo uma alternativa ao Claude Code me tocou especialmente. Fazer um agente de programação autoaperfeiçoável é uma experiência quase mágica
  Você pode trocar de modelo livremente e, se usar modelos rápidos como os da Cerebras, sente uma diferença enorme até em chamadas de ferramenta interativas
  Se adicionar memória, reconhecimento de voz e afins, fica muito mais eficiente. Dá para implementar em poucos minutos e é muito divertido

  • Fiquei curioso sobre qual modelo de reconhecimento de voz você usa. O Whisper era lento e pouco preciso, e os modelos de áudio da GPT davam respostas de recusa com frequência
    Os modelos do Google tinham qualidade baixa, e os da Mistral são rápidos, mas às vezes acabam reagindo ao texto
    Então às vezes acontece de, em vez de transcrever o que eu falei, ele registrar o fluxo de consciência do LLM
  • Gostei muito da expressão “build your own lightsaber”
    No começo eu fiz isso para entender a estrutura interna, mas era mais simples do que eu imaginava, então agora estou adicionando diretamente as funções que eu quero
    Dá para colocar recursos mais rápido do que num produto feito por equipe. Os agentes têm uma estrutura surpreendentemente simples
  • Se eu quisesse começar, nem saberia por onde. É a primeira vez que ouço falar da Cerebras. Hoje eu só uso o Copilot no VS Code
    Fico me perguntando se isso é baseado em modelos locais
  • A Cerebras agora oferece o glm 4.6. Continua absurdamente rápido e agora está bem mais inteligente

• Esse texto dá vontade de recriar a filosofia Unix — ferramentas que fazem uma coisa bem feita
  Além de deixar os agentes mais simples, isso também aumenta a segurança

  • Em 2021 eu criei um agente para testar conectividade de rede e, ao delegar ao agente ferramentas básicas como ping, dig, traceroute, ele entregava resultados bem bons
    Não era perfeito como um sistema de telemetria feito manualmente por humanos, mas consegui atingir 90% de utilidade com muito mais facilidade
  • Também dá para imaginar um conjunto de ferramentas de propósito limitado exposto diretamente a humanos
  • Para fazer uma coisa bem, você acaba precisando de mais ferramentas e, com isso, cresce também a capacidade de entender contexto
    Acho que o tamanho ideal de um LLM fica num meio-termo, um pouco acima das ferramentas Unix tradicionais

• Fico pensando: “é mesmo preciso criar um agente?”
  Num cenário em que todos os provedores de IA estão operando no vermelho, sou cético quanto à possibilidade de um modelo de receita sustentável

  • Se você construir um por conta própria, consegue entender intuitivamente como os agentes funcionam e quais são seus limites. Esse é o ponto principal
  • Este texto é só sobre experimentar a tecnologia por diversão. Não tem relação com monetização
    É uma lógica parecida com citar o prejuízo da Astral como motivo para não usar Python
  • Nem todas as empresas de IA estão dando prejuízo
    Elas precisam de capital por causa do custo do treinamento do próximo modelo, mas a etapa de inferência é lucrativa
  • Você também pode virar seu próprio provedor de IA
  • Este comentário passa um pouco de cansaço emocional. Fiquei curioso se você é um desenvolvedor com muitos anos de carreira

• A parte de engenharia de contexto me marcou especialmente
  Estou criando um assistente pessoal, e ele tem mais memória, rastreamento de tarefas e capacidade de resolver problemas do que um agente genérico
  Projetei vários agentes para conversarem entre si e resolverem problemas, e o primeiro agente atua como supervisor de gerenciamento de tarefas
  Quanto mais fundo vou nesse processo, mais isso vira um problema de engenharia
  Escrevi mais detalhes neste post do meu blog

  • Parece um projeto realmente incrível

• Todo mundo gosta de criar agentes, mas ninguém gosta de depurar
  No começo funciona como mágica, mas aos poucos as falhas probabilísticas se acumulam e fica difícil reproduzir os problemas
  Como cada etapa leva 0,5 segundo, você acaba esperando de 10 a 20 minutos para descobrir onde deu errado

  • Por isso eu criei uma ferramenta de execução paralela, para rodar o código modificado centenas de vezes
    e também reexecutar cenários antigos para verificar se nada quebrou

• Com base no código fornecido, criei um MCP: gurddy-mcp.fly.dev
  O código-fonte pode ser visto no repositório no GitHub