Agentes em Go sem framework: por que tratar o LLM como componente, não como sistema

Gerar código e chamar APIs com um LLM virou trivial. O problema começa depois: transformar essas chamadas em um sistema agêntico confiável, que não entre em loop infinito, não invente ações e não estoure o orçamento de tokens em produção. Esse é justamente o recorte de um workshop avançado anunciado na agenda oficial da GopherCon 2026, ministrado por Johnny Boursiquot (Principal Software Engineer na Stable Kernel), com duração de quatro horas.

A descrição pública da sessão parte de uma premissa que vale destacar para quem constrói software no Brasil e vem empilhando integrações de IA: o risco operacional não some só porque tem um modelo envolvido. Estado escondido, loops descontrolados, ações alucinadas e frameworks opacos continuam sendo bugs, agora com uma camada probabilística por cima.

O agente como máquina de estado

A abordagem central proposta é framework-free: nada de orquestradores mágicos que escondem o fluxo de controle. Em vez disso, o agente é modelado como uma máquina de estado explícita, orientada a objetivo, na qual o LLM é apenas um componente de decisão restrito, não o sistema inteiro.

Essa inversão importa. Em muitas stacks de agentes populares, o modelo fica no centro e decide livremente qual ferramenta chamar, quando parar e o que fazer a seguir. O resultado é difícil de testar, difícil de observar e propenso a comportamentos emergentes indesejados. Ao colocar a máquina de estado no comando e reduzir o LLM a responder perguntas pontuais dentro de fronteiras bem definidas, o engenheiro recupera controle sobre o que a fonte chama de state, actions, planning, execution, validation, retries, and termination conditions, ou seja, os blocos que normalmente ficam escondidos no framework passam a ser código Go que você escreve e lê.

Go se presta bem a esse desenho. Tipos explícitos, error como valor de retorno, goroutines e um modelo de concorrência previsível ajudam a expressar transições de estado e condições de término sem magia. O preço é escrever mais código à mão, mas em troca você entende cada aresta do grafo de estados.

Skills como fronteira de capacidade

Outro conceito apresentado na descrição são as skills: fronteiras de capacidade que delimitam o que o agente tem permissão de fazer. É um princípio de menor privilégio aplicado a agentes. Em vez de dar ao modelo acesso irrestrito a um catálogo de ferramentas, você declara explicitamente o conjunto de ações possíveis em cada estado.

O ponto interessante é o desacoplamento: segundo a sessão, essas skills podem ser servidas tanto por funções Go locais quanto por ferramentas remotas via Model Context Protocol (MCP), sem mudar o fluxo de controle do agente. Ou seja, o MCP entra como mecanismo de integração de ferramentas, mas quem manda no loop continua sendo o código Go. Essa separação entre onde a capacidade vive e quem decide usá-la é o tipo de trade-off que costuma ser abstraído longe demais em soluções prontas.

Guardrails, observabilidade e os modos de falha

A proposta também promete examinar modos de falha comuns e adicionar guardrails para tornar esses sistemas observáveis, testáveis e seguros de operar. Não à toa a preparação recomendada inclui OpenTelemetry (opcional, mas sugerido): sem tracing e métricas, um agente é uma caixa-preta que às vezes gasta dinheiro. Prevenir loops infinitos, ações alucinadas e custos descontrolados aparece explicitamente entre os objetivos de aprendizado.

Para quem quiser acompanhar o tema, os pré-requisitos técnicos listados dão uma boa pista do stack de referência:

• Go 1.26+ com plugin no editor/IDE
• Conta em OpenAI, Anthropic ou AWS (roteando via Bedrock) para LLMs remotos
• Ollama e pgvector para o cenário local
• Docker e uma conta GitHub

O detalhe de Ollama mais pgvector é revelador: dá para exercitar boa parte dos padrões com modelos locais e busca vetorial no Postgres, sem depender de nuvem para tudo. Isso reduz custo de experimentação e é especialmente útil no contexto brasileiro, onde faturamento em dólar de APIs de LLM pesa no orçamento.

Por que isso importa

Vale reforçar o que este texto é e o que não é: a iMasters não esteve na sala e não sabe o que foi de fato apresentado. O que a agenda oficial descreve é a intenção da sessão, e o tema merece atenção independentemente do conteúdo específico.

A mensagem de fundo é útil mesmo para quem não vai ao evento: agentes confiáveis não nascem de prompts melhores, mas de arquitetura de controle. Tratar o LLM como um subsistema restrito dentro de uma máquina de estado que você escreveu, testou e instrumentou é um caminho mais chato e mais seguro do que entregar as chaves para um framework. Para times que já passaram do estágio de chamadas avulsas de modelo e querem workflows agênticos de produção, esse é o tipo de disciplina que separa demo de sistema.

Fonte: Agenda oficial — Meeting Room 434, Level 4, SCC | Summit