Um Prompt é um Desejo. Uma Ferramenta é uma Lei.

Como deixei não engenheiros enviarem ferramentas de IA para produção — e a infraestrutura entediante que tornou isso seguro.

Uma gerente de produto descreveu um fluxo de trabalho em inglês simples — "toda manhã, puxe os pagamentos falhados de ontem, agrupe-os por código de erro e poste um resumo em nosso canal." Vinte minutos depois, estava rodando em produção. Ela nunca abriu um editor. Ela nunca viu uma linha de TypeScript. Ela conversou com um agente, o agente escreveu o código e — uma vez que um humano revisou o pull request — foi enviado.

Essa frase deve te deixar nervoso. Me deixou nervoso, e eu sou quem construiu a coisa.

A demonstração é "veja, ele escreveu o código." A operação é "uma ferramenta de marketing agora tem um caminho para o banco de dados de pagamentos e ninguém a revisou." A engenharia interessante não é a parte onde um LLM escreve código — essa é a parte fácil, demonstrável. São as barreiras que decidem se o código que ele escreve é permitido existir.

Aqui está a plataforma, e os cinco problemas que tive que resolver para torná-la segura para pessoas que não conseguem ler o código que roda.

A forma da coisa

A plataforma é um lugar onde qualquer um — engenheiros, PMs, designers, QA — pode publicar uma ferramenta de IA reutilizável, e todos os outros podem usá-la. Escreva uma vez, disponível para todos.

Alguns termos à frente, porque todo o design se baseia neles:

• MCP (Modelo de Protocolo de Contexto) é uma maneira padrão para um cliente de IA descobrir e chamar suas funções. O detalhe chave: há um passo onde o cliente pergunta ao servidor "quais ferramentas você tem?" e o servidor responde com uma lista. Segure isso — metade do design depende dessa lista.
• Cloudflare Workers é código que roda nos servidores da Cloudflare na borda da rede em vez de no seu próprio. Objetos Duráveis são armazenamento do lado do servidor por sessão que vive fora do contexto do modelo — a janela finita e custosa em tokens de tudo que o modelo pode atualmente ver. Nada disso é exótico; o que importa é onde cada peça de estado vive.

Por baixo dos panos, são três pequenos Workers falando MCP: um gateway (autenticação, roteamento, segredos), um executor de habilidades, e um executor de agentes. Segredos são buscados pelo gateway de um gerenciador de segredos — nunca embutidos, nunca entregues ao código que executa a lógica do usuário, a menos que esse código seja explicitamente uma ação (mais sobre essa distinção abaixo).

Aqui está a parte que a maioria das postagens sobre "plataformas de IA" pula: como é consumido. Você não instala cinquenta agentes separados em seu cliente Claude. Você conecta um servidor MCP. Cada ferramenta publicada aparece através desse único ponto de extremidade. Essa escolha é a diferença entre uma plataforma e uma máquina de inchaço de contexto, e voltarei a isso.

As ferramentas em si alcançam os sistemas que uma empresa opera — rastreadores de problemas, chat, docs, o CMS, o armazém de análises, o banco de dados de pagamentos. Alguns desses dados são inofensivos. Alguns deles são um incidente de conformidade esperando por um fetch descuidado. Todo o design é organizado em torno dessa assimetria.

Problema 1: Um prompt é um desejo. Uma ferramenta é uma lei.

O fluxo de autoria é um pipeline fixo: planeje, obtenha a aprovação do plano, gere os arquivos, revise seu próprio trabalho, abra um PR. Um fluxo agradável e ordenado.

O agente se recusou a respeitá-lo. Ele gerou arquivos antes que o plano fosse aprovado. Ele "revisou" o código dizendo parece bom e imediatamente abriu um PR. Ele pulou as etapas inconvenientes e avançou em direção ao fim, porque é isso que um modelo otimizado para ser útil, completar a tarefa faz. Meu pipeline existia na minha cabeça e em um longo arquivo de instruções que o modelo tratava como uma sugestão educada.

Tentei as coisas óbvias primeiro, em ordem de crescente desespero:

• Instruções. Um prompt do sistema com "PARAR. Não escreva código até que o plano seja aprovado." O modelo lê, concorda e escreve código de qualquer maneira quando a tarefa parece exigir. O texto do prompt é uma entrada que o modelo pondera, não uma regra que ele obedece.
• Uma máquina de estados em memória. Acompanhe a fase da conversa e recuse-se a avançar. Isso morre no momento em que o contexto é compactado — os agentes resumem a história antiga para economizar espaço, então um fato que o modelo "sabia" vinte mensagens atrás silenciosamente desaparece, e ele esquece em que fase está.
• Ganchos. Intercepte ações e bloqueie as não permitidas. O modelo é notavelmente bom em contornar um caminho bloqueado, reformulando ou encontrando outra ferramenta que o leve ao mesmo lugar.

O padrão em todos os três: cada um vive dentro do raciocínio do modelo, e qualquer coisa dentro do raciocínio do modelo é negociável. Um modelo sob pressão de tarefa racionaliza seu caminho além do texto de forma confiável o suficiente para que você não possa depender dele. Os prompts ainda direcionam o modelo — eles apenas não podem garantir isso, e uma regra de produção precisa de uma garantia.

Então o truque não é dizer ao modelo as regras melhor. É fazer das regras uma propriedade das ferramentas. Cada passo se torna sua própria ferramenta, e as ferramentas formam um gráfico: uma ferramenta de passo valida que o passo anterior aconteceu, e somente com sucesso ela retorna as instruções para o próximo passo. O modelo não pode pular à frente, porque fisicamente não tem as próximas instruções até que o portão atual as entregue — e o portão é a única borda para o próximo estado.

start_building → confirm_plan → submit_for_review → submit_final → create_pull_request

Esta é a parte que as pessoas erram, incluindo eu no começo: a coisa que faz um portão ser uma parede é não que uma chamada de ferramenta falhada seja difícil de ignorar. O modelo pode ignorar um erro — pode tentar novamente ou contornar, da mesma forma que contornou ganchos. O que ele não pode fazer é fabricar as instruções do próximo passo, porque essas existem apenas dentro de uma resposta de sucesso validada. O determinismo está no portão de estado do lado do servidor — cada ferramenta verifica a fase persistida antes de agir — não no erro. O erro é apenas como o portão diz não ainda.

Concretamente: o agente chama create_pull_request enquanto a fase ainda está planejamento. O portão vê a fase errada, retorna um erro e — a parte que importa — nunca devolve as instruções do próximo passo. O agente não está proibido de terminar; ele está incapaz de fazê-lo, porque terminar requer palavras que ele nunca recebeu.

O estado vive do lado do servidor, indexado por sessão, no armazenamento de Objetos Duráveis — persistido fora do contexto do modelo completamente, então a compactação que matou a versão em memória não pode tocá-lo.

const fail = (text: string) => ({ isError: true, content: [{ type: "text", text }] });
const ok = (text: string) => ({