A Unconference Fez as Perguntas Certas. Aqui Estão as Respostas de Uma Arquitetura.

Acabei de terminar o episódio do Podcast de Tecnologia da Thoughtworks onde Ken Mugrage, Kief Morris e Andrew Harmel-Law discutem a unconference sobre o futuro da engenharia de software que realizaram na Suíça com Martin Fowler (transcrição completa aqui).

Se você ainda não ouviu: o clima mudou. Há alguns meses, essas conversas eram "olhe para as coisas brilhantes." Agora é "Sabemos que isso pode funcionar, mas precisamos responder a essas perguntas"

O episódio é basicamente um tour pelos problemas abertos na engenharia agentic — confiança, limites, controle, governança — e o que me impressionou foi quantos deles são problemas de infraestrutura disfarçados de problemas de prompt.

Divulgação completa antes de começarmos: passei os últimos meses construindo IRC-A (Internet Relay Chat para Agentes), um padrão de arquitetura descentralizada e SDK para sistemas multi-agente. Portanto, quando digo "aqui está como eu responderia isso," tenho uma arquitetura específica e opinativa em mente — considere como as respostas de um praticante, não como um evangelho. Agora, as perguntas.

1. "Você precisa de infraestrutura que não permita isso"

No início do episódio, Kief menciona um medo que alguém levantou: e se o agente, deixado sem supervisão, conectar o ambiente de desenvolvimento ao banco de dados de produção para pegar alguns dados?

A resposta dele é a melhor linha de todo o episódio:

"Não, você precisa ter infraestrutura e sistemas que não permitam que algo rodando em seu ambiente de desenvolvimento se conecte ao seu banco de dados de produção."

Exatamente. E é aqui que eu iria mais longe: na maioria das arquiteturas de agentes hoje, o agente conversacional possui as credenciais do banco de dados. Então, gastamos um esforço enorme em engenharia de prompt e revisão de código para impedir que ele as misuse. Isso é controlar o comportamento através da esperança.

IRC-A traça um limite de rede rigoroso: apenas os servidores de ferramentas FastMCP, rodando em sandboxes isoladas, possuem drivers e credenciais de banco de dados.

Os agentes não podem fisicamente se conectar a nada transacional — eles não têm os drivers, as credenciais ou o caminho de rede. Uma injeção de prompt dizendo ao agente para descartar o esquema corporate_financials falha não porque o agente se recusou, mas porque não há literalmente nada em seu ambiente que poderia executá-lo. Segurança que você não precisa lembrar de impor.

2. Agentes não respeitam limites desenhados em prompts

Andrew descreve algo que qualquer um que roda agentes em um código real já sentiu:

"Os agentes podem vagar por aí... eles são muito sycophantic, eles querem fazer o que você pediu e te deixar feliz. Se você quer que eles façam isso enquanto ainda... protegem alguns limites em um código, é muito possível que eles não respeitem isso. Mesmo que você comece com algo claro, as bordas podem se tornar muito borradas muito rapidamente."

A observação dele de que as equipes estão voltando para microserviços em repositórios separados "porque este agente não pode mudar isso — ele não tem direitos para mudar este código neste repositório" é reveladora: estamos redescobrindo que os limites só funcionam quando são impostos pelo ambiente, não descritos em instruções.

Mas dividir repositórios é uma ferramenta grosseira. IRC-A impõe a mesma propriedade com canais lógicos: cada nó (agente ou servidor de ferramenta) declara seus canais através de variáveis de ambiente (IRCA_CHANNELS="#aml-restricted,#compliance-audit"), e o Gateway BFA mascara a descoberta de capacidade dentro do índice FAISS de acordo.

Um agente em #finance não pode nem mesmo ver que uma ferramenta AML existe — a capacidade é filtrada da busca vetorial antes da correspondência. O limite vive na infraestrutura, onde a sycophancy não pode falar seu caminho para além dele.

3. Firmeza: markdown < scripts < criptografia

Kief descreve uma hierarquia de garantia: arquivos de habilidade markdown e AGENTS.md te dão alguma orientação, mas "ferramentas scriptáveis que são executadas e fazem tarefas particulares de uma maneira previsível" são mais fortes. Ele as chama de "níveis de força de garantia."

Eu argumentaria que há um nível acima dos scripts, e os sistemas de agentes precisam disso: restrição criptográfica.

Quando um agente IRC-A quer invocar uma capacidade, o Gateway BFA cria um Token de Execução Delegada Efêmera (DET) — um token PASETO assinado com Ed25519, limitado a uma função, com bloqueio de parâmetros.

O servidor de ferramentas verifica offline contra a chave pública do Gateway e checa se os argumentos de tempo de execução correspondem exatamente aos parâmetros bloqueados. fetch_customer_credit_score(customer_id="882") é executado; a mesma função com "885" é rejeitada na porta.

Um arquivo markdown pode ser contornado. Um script pode ser chamado com argumentos diferentes. Uma assinatura não pode.

4. Quem possui o harness?

Ken levanta a questão organizacional — quem possui o harness, a equipe de plataforma? — e Andrew aponta para plataformas que "abençoam" certos harnesses e habilidades para que as equipes obtenham requisitos não funcionais (conformidade, manuseio de dados, replicação) junto com funcionalidade, especialmente em ambientes regulados.

Isso se mapeia diretamente na separação do IRC-A: o BFA (Backend para Agentes) é estritamente um perímetro de governança — registro, diretório de capacidade, cunhagem criptográfica. Ele nunca executa loops de raciocínio e nunca toca em dados transacionais. A equipe de plataforma possui a governança; as equipes de produto possuem a execução. Governança como sua própria camada, ou — como eu disse antes — ela se entrelaça com a execução e ambas apodrecem juntas.

5. Especialistas orientados a tarefas, não personalidades

Ambos os convidados se opuseram a dar aos agentes "personalidades", e Kief chegou à formulação com a qual concordo:

"Pense sobre esses fluxos de trabalho e quais partes você quer delegar a um LLM para realizar... é muito orientado a tarefas."

O IRC-A leva isso à sua conclusão: agentes cognitivos são especialistas sem estado com exatamente uma responsabilidade. Um agente não deve conhecer o ecossistema em que opera — apenas seu próprio objetivo. Sem persona de agente BA, sem organograma de 73 agentes com um otimista e um cínico. Capacidades, não personagens.

6. Pare de fazer teatro de controle — controle o limite em vez disso

A thread do "teatro de controle" foi a parte mais filosoficamente honesta do episódio.

Andrew: "Sempre tivemos muito menos controle do que pensamos que tínhamos." Kief questionando se pull requests alguma vez garantiram a captura de erros humanos, "ou isso é apenas teatro?"

Minha opinião: eles estão certos que revisar cada linha sempre foi parcial. Mas a conclusão não é "desista do controle" — é mover o controle para onde é determinístico.

IRC-A não pode garantir o que um agente raciocina, e não tenta. Ele garante o que um agente pode executar: cada solicitação inter-agente carrega um trace_id e uma lista de visited_nodes, então loops de delegação circular são detectados e rejeitados pelo SDK. Cada execução requer um DET válido, limitado e não expirado. O raciocínio é livre; o limite não é negociável. Previsível onde importa — que é exatamente a palavra que Andrew sugere que usamos em vez de "determinismo."

7. Contexto sem o excesso

Houve uma sessão sobre a construção de um gráfico de conhecimento organizacional para que os agentes possam "extrair as informações certas que precisam sem ter que preencher seu contexto com tudo." Sim — e esse problema é maior do que conhecimento.

A maioria das estruturas multi-agente preenche o contexto com tudo: cada esquema de ferramenta, cada contrato de API, todo o histórico de conversação, em cada chamada única. Isso é excesso de prompt, e é por isso que os custos de token escalam tão mal.