A infraestrutura de agência e o novo backend

spinny:~/writing $ vim agentic-infrastructure-stack.md

1~
2Muitas vezes falamos sobre estruturas de agência. LangGraph, CrewAI, AutoGen, vários SDKs, loop, chamada de ferramenta, memória, planejador, crítico, supervisor. Todas palavras úteis, pelo amor de Deus. Mas quanto mais observo os agentes realmente utilizados, mais me parece que a parte interessante deslocou-se para baixo do nível da estrutura.
3~
4A questão não é mais apenas: qual biblioteca devo usar para fazer um modelo passo a passo pensar?
5~
6A verdadeira questão é: onde mora esse agente quando deixa de ser um demo?
7~
8Porque um agente sério não é uma função que chama um modelo e retorna texto. É um pequeno sistema distribuído. Ele deve ler o contexto, usar ferramentas, executar código, mexer em arquivos, lembrar de decisões, pedir permissão, falhar bem, reiniciar, deixar logs, não queimar o orçamento e não virar uma escavadeira dentro do repositório de produção.
9~
10A estrutura é o volante. A infraestrutura é a estrada, os freios, a garagem, o seguro e quem sabe onde estão as chaves.
11~
12## Porque se fala muito sobre isso agora
13~
14Em 2023 e 2024 a conversa foi muito centrada no modelo. Qual LLM? Quanto contexto? Quanto custa isso? Quão bom ele é em programação?
15~
16Em 2025 e 2026 a conversa mudou. Os modelos são bons o suficiente para realizar trabalho real, mas é por isso que as partes chatas se tornam visíveis: tempo de execução, segurança, conectores, identidade, observabilidade, execução de código, implantação, reversão.
17~
18É a transição natural da magia para a engenharia.
19~
20Quando um agente precisa apenas gerar uma resposta, basta um chat. Quando você precisa abrir uma solicitação pull, consultar um banco de dados, chamar um CRM, iniciar um trabalho, navegar em um site, ler o Slack, compilar código e atualizar um documento, você precisa de um sistema operacional em torno disso.
21~
22Não no sentido literal. No sentido organizacional.
23~
24## A primeira parte: um tempo de execução onde o agente pode durar
25~
26Um agente geralmente trabalha em etapas. Observe o estado, escolha uma ação, use uma ferramenta, observe o resultado, atualize o plano, repita.
27~
28Se esse loop residir dentro de uma única solicitação HTTP, você terá um problema imediatamente. Algumas ações são lentas. Alguns aguardam a contribuição humana. Alguns falham e devem ser tentados novamente. Alguns devem sobreviver a uma implantação ou tempo limite.
29~
30É aqui que entram em jogo fluxos de trabalho duráveis, filas, históricos de trabalho e máquinas de estado. Eles não são glamorosos, mas são a diferença entre um agente que parece inteligente na demonstração e aquele que você pode deixar trabalhando enquanto vai tomar um café.
31~
32Para mim, o tempo de execução da agência deve responder a perguntas muito concretas:
33~
34- onde salvo o estado entre uma etapa e outra?
35- o que acontece se o processo morrer no meio?
36- posso fazer uma pausa e pedir aprovação?
37- posso repetir uma corrida para entender por que ele fez essa escolha?
38- posso limitar a duração, a memória, as ferramentas e o custo?
39~
40A Vercel está se esforçando bastante nessa frente com SDKs de IA, funções, fluxos de trabalho e ferramentas para construir agentes em aplicações web. Mas a questão não é apenas Vercel. A questão é que o agente precisa de um local operacional, não de um único terminal.
41~
42## A segunda peça: sandbox, pois o agente deve conseguir se sujar sem quebrar
43~
44Assim que um agente escreve código ou executa comandos, é necessária uma sandbox.
45~
46Parece uma palavra técnica, mas a ideia é doméstica: você dá uma bancada para ele. Ele pode abrir arquivos, instalar dependências, executar testes, fazer experimentos, gerar resultados. Se ele errar, você conteve o dano. Se funcionar, promova o resultado.
47~
48Um sandbox agente deve ter algumas propriedades:
49~
50- sistema de arquivos isolado;
51- CPU, memória e limites de tempo;
52- rede controlada;
53- segredos montados somente quando necessário;
54- registros completos;
55- possibilidade de exportar artefatos;
56- reinicialização limpa entre execuções, quando necessário.
57~
58O Vercel Sandbox vai exatamente nessa direção: ambientes isolados para executar código, instalar dependências, trabalhar com arquivos e produzir artefatos sem executar tudo no tempo de execução da aplicação principal.
59~
60Essa coisa é mais importante do que parece. Muitos protótipos agentes saltam diretamente do modelo para o sistema real. O modelo pode chamar tool. As ferramentas podem fazer coisas. Tudo parece elegante até o primeiro comando errado, a primeira dependência instalada no lugar errado, o primeiro token que vai parar em um log.
61~
62A caixa de areia é a forma adulta de dizer: vá em frente, mas aqui.
63~
64## A terceira peça: MCP e o problema do conector
65~
66O Model Context Protocol tornou-se uma das partes mais interessantes do ecossistema porque tenta padronizar algo que de outra forma rapidamente se tornaria incontrolável: como um modelo descobre e usa ferramentas externas.
67~
68Sem um padrão, cada integração é uma pequena ilha. Um conector para GitHub feito de uma maneira, um para Slack feito de outra, um para bancos de dados com semântica diferente, um para automação de navegador que parece nada.
69~
70O MCP propõe uma linguagem comum entre cliente e servidor: ferramentas, recursos, prompts, autorizações, transporte, descoberta. Não resolve magicamente a governança e a segurança, mas fornece uma gramática.
71~
72E a gramática é importante. Quando um agente pode se conectar a muitas ferramentas, a questão não é apenas “ele consegue fazer isso?”. O problema é “ele entende o que pode fazer, com quais limites, em nome de quem e deixando quais rastros?”.
73~
74Para mim, o MCP não é exagero porque "faz chamadas de ferramentas". Nós já fizemos isso. É um exagero porque muda o centro de gravidade da integração única para o catálogo operacional de ferramentas.
75~
76Em uma boa arquitetura agêntica, o MCP se torna uma espécie de patch panel:
77~
78- GitHub para código e problemas;
79- Slack para contexto conversacional;
80- Linear ou Jira para trabalhos planejados;
81- banco de dados somente leitura para análises;
82- navegador ou raspador controlado para sites externos;
83- armazenamento de documentos;
84- ambientes de execução isolados;
85- sistemas internos expostos com permissões estritas.
86~
87A parte complicada é que um catálogo de ferramentas sem políticas é apenas uma forma mais elegante de criar o caos.
88~
89## A quarta peça: identidade e permissões
90~
91Esta é a área onde muitas demonstrações fecham os olhos.
92~
93Um agente atua em nome de alguém. Portanto, deve ficar claro quem é o sujeito da ação.
94~
95Está usando permissões de usuário? De uma conta de serviço? De um espaço de trabalho? Você tem acesso temporário ou permanente? Você consegue ler tudo ou apenas alguns recursos? Você pode escrever? Você pode cancelar? Ele pode enviar mensagens para pessoas reais?
96~
97Se você não responder bem a essas perguntas, mais cedo ou mais tarde construirá um assistente com as chaves de casa e sem memória de quem as deu a ele.
98~
99A regra que gosto é esta: o agente deve ser capaz de fazer menos que o humano, e não mais que o humano. E quando ele tem que fazer algo mais arriscado, ele tem que parar e perguntar.
100~
101Isso significa OAuth, escopo de token, gerenciamento de segredos, log de auditoria, política de ferramentas, lista de permissões, etapa de aprovação. Coisas não muito românticas. Coisas necessárias.
102~
103## A quinta peça: memória e contexto, mas sem acumular lixo
104~
105Os agentes precisam de memória, mas a memória é perigosa quando se transforma num sótão.
106~
107Existem pelo menos três tipos de memória:
108~
109- memória de execução: o que aconteceu nesta execução;
110- memória de projeto: convenções, decisões, restrições;
111- memória pessoal ou de equipe: preferências, tom, rituais, processos.
112~
113Colocar tudo no prompt é o atalho. Funciona até não funcionar mais. A memória útil deve ser cuidada: indexada, atualizada, expirada, verificada, tornada citável.
114~
115Um agente que se lembra mal é pior do que um agente que não se lembra. Porque ele fala com confiança.
116~
117Portanto, a infra-estrutura deve incluir recuperação, arquivos de instruções, base de conhecimento, incorporação quando necessário, mas também limpeza. Precisamos de uma cultura da memória: o que entra, quem aprova, quando decai, como faço para corrigir.
118~
119## A sexta peça: observabilidade, avaliação e repetição
120~
121Se um agente cometer um erro, o log “chamado de modelo” não será suficiente.
122~
123Você quer ver a rota. Que contexto ele recebeu? Quais ferramentas estavam disponíveis? Qual ferramenta você escolheu? Com que argumentos? Que resposta você obteve? Quanto custou? Onde ele ficou preso? O humano aprovou alguma coisa? O erro é um erro de modelo, ferramenta, prompt, dados ou permissão?
124~
125Aqui os agentes são mais parecidos com sistemas distribuídos do que chatbots.
126~
127Você precisa de rastreamentos legíveis, não apenas de registros de texto. Você precisa ser capaz de reproduzir uma corrida. É necessário comparar duas versões do mesmo agente em tarefas conhecidas. Precisamos medir as regressões: não apenas "responde melhor", mas também "fecha o ticket certo sem tocar em arquivos não solicitados".
128~
129As avaliações de agente são mais difíceis do que as avaliações de texto porque incluem ações. Não é suficiente comparar uma string esperada. É preciso observar as sequências, os efeitos colaterais, a qualidade do artefato, o tempo, o custo, o número de intervenções humanas.
130~
131O engraçado é que sempre voltamos lá: engenharia de software. Testes, ambientes, rastreamentos, reversões. Só que o código agora também decide o que fazer a seguir.
132~
133## A sétima peça: interfaces humanas
134~
135O agente não precisa apenas viver em um chat.
136~
137Alguns agentes precisam de um conselho. Outros uma página com status e log. Outros de um botão "aprovar". Mais comentários embutidos. Ainda outros de uma CLI.
138~
139A IU muda o comportamento. Se a única maneira de controlar um agente for escrever uma mensagem longa, o usuário dará instruções vagas ao agente. Se, no entanto, ele vir o plano, as diferenças, as fontes, os riscos e a próxima ação, ele poderá intervir com precisão.
140~
141Uma infraestrutura de agente decente inclui superfícies de controle:
142~
143- situação atual;
144- plano editável;
145- artefatos produzidos;
146- diferença;
147- solicitações de aprovação;
148- cronologia;
149- botão parar;
150- botão de tentar novamente;
151- permissões visíveis.
152~
153Parece trivial, mas não é. A diferença entre “IA assustadora” e “assistente confiável” geralmente é apenas que o último mostra onde está as mãos.
154~
155## A pilha mental
156~
157Se eu comprasse hoje, o stack mínimo do agente seria este:
158~
1591. Modelo: raciocínio, geração, chamada de ferramenta, multimodal se necessário.
1602. Orquestração: loop, etapa, planejador, política, humano no circuito.
1613. Tempo de execução durável: fluxo de trabalho, fila, nova tentativa, pausa, retomada.
1624. Sandbox: execução de código, sistema de arquivos isolado, limitações, artefatos.
1635. Camada de ferramentas: MCP, API interna, navegador, banco de dados, repositório.
1646. Camada de identidade: OAuth, escopo, segredo, auditoria, política.
1657. Camada de memória: contexto do projeto, recuperação, instruções, expiração.
1668. Observabilidade: métricas de rastreamento, repetição, avaliação, custo e qualidade.
1679. Superfície do produto: converse quando for suficiente, painel quando necessário, revise quando for importante.
168~
169A estrutura de agência cobre principalmente os pontos 2 e uma parte do ponto 1. O resto é o verdadeiro trabalho.
170~
171## O que eu faria na prática
172~
173Se uma equipe me dissesse “queremos agentes em produção”, eu não começaria com dez agentes.
174~
175Eu começaria com um fluxo de trabalho pequeno, repetitivo e observável. Por exemplo: abrir PRs de manutenção, atualizar a documentação de problemas fechados, preparar uma revisão semanal, fazer triagem de bugs duplicados, gerar testes para arquivos afetados.
176~
177Então eu estabeleceria limites muito claros:
178~
179- não é permitido escrever sem ramificações ou sandbox;
180- sem segredos no prompt;
181- ferramentas na lista de permissões;
182- aprovação humana para ações externas;
183- registro e rastreamento obrigatórios;
184- orçamento por execução;
185- saída sempre inspecionável.
186~
187Só então eu expandiria.
188~
189Os agentes não falham só porque os modelos erram. Eles falham porque os colocamos em ambientes vagos, com permissões confusas e expectativas teatrais.
190~
191## Minha leitura
192~
193A infraestrutura agente é entediante da melhor maneira.
194~
195Não é a parte que te faz bater palmas na demo. É a parte que permite que você realmente use a demonstração na manhã de segunda-feira, com pessoas reais, dados reais e consequências reais.
196~
197O futuro dos agentes não será decidido apenas por quem tiver o melhor modelo. Será decidido por quem construir o melhor lugar para fazê-lo trabalhar: isolado quando experimenta, conectado quando necessário, sempre observável, autorizado com critério e humilde o suficiente para parar quando não sabe.
198~
199É aí que os agentes deixam de ser um brinquedo e passam a ser infraestrutura.
200~
201## Fontes
202~
203- [Vercel: Como construir agentes de IA com Vercel e o AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Documentos Vercel: Sandbox](https://vercel.com/docs/sandbox)
205- [Vercel Docs: Trabalhando com Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Documentos Vercel: MCP](https://vercel.com/docs/mcp)
207- [Protocolo de Contexto do Modelo: Especificação](https://modelcontextprotocol.io/specification)
208- [OpenAI: Novas ferramentas para agentes de construção](https://openai.com/index/new-tools-for-building-agents/)
209- [Blog da Cloudflare: Agentes na Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210~

NORMAL · agentic-infrastructure-stack.md [readonly]210 lines · :q to close

2Muitas vezes falamos sobre estruturas de agência. LangGraph, CrewAI, AutoGen, vários SDKs, loop, chamada de ferramenta, memória, planejador, crítico, supervisor. Todas palavras úteis, pelo amor de Deus. Mas quanto mais observo os agentes realmente utilizados, mais me parece que a parte interessante deslocou-se para baixo do nível da estrutura.

4A questão não é mais apenas: qual biblioteca devo usar para fazer um modelo passo a passo pensar?

6A verdadeira questão é: onde mora esse agente quando deixa de ser um demo?

8Porque um agente sério não é uma função que chama um modelo e retorna texto. É um pequeno sistema distribuído. Ele deve ler o contexto, usar ferramentas, executar código, mexer em arquivos, lembrar de decisões, pedir permissão, falhar bem, reiniciar, deixar logs, não queimar o orçamento e não virar uma escavadeira dentro do repositório de produção.

10A estrutura é o volante. A infraestrutura é a estrada, os freios, a garagem, o seguro e quem sabe onde estão as chaves.

11~

12## Porque se fala muito sobre isso agora

13~

14Em 2023 e 2024 a conversa foi muito centrada no modelo. Qual LLM? Quanto contexto? Quanto custa isso? Quão bom ele é em programação?

15~

16Em 2025 e 2026 a conversa mudou. Os modelos são bons o suficiente para realizar trabalho real, mas é por isso que as partes chatas se tornam visíveis: tempo de execução, segurança, conectores, identidade, observabilidade, execução de código, implantação, reversão.

17~

18É a transição natural da magia para a engenharia.

19~

20Quando um agente precisa apenas gerar uma resposta, basta um chat. Quando você precisa abrir uma solicitação pull, consultar um banco de dados, chamar um CRM, iniciar um trabalho, navegar em um site, ler o Slack, compilar código e atualizar um documento, você precisa de um sistema operacional em torno disso.

21~

22Não no sentido literal. No sentido organizacional.

23~

24## A primeira parte: um tempo de execução onde o agente pode durar

25~

26Um agente geralmente trabalha em etapas. Observe o estado, escolha uma ação, use uma ferramenta, observe o resultado, atualize o plano, repita.

27~

28Se esse loop residir dentro de uma única solicitação HTTP, você terá um problema imediatamente. Algumas ações são lentas. Alguns aguardam a contribuição humana. Alguns falham e devem ser tentados novamente. Alguns devem sobreviver a uma implantação ou tempo limite.

29~

30É aqui que entram em jogo fluxos de trabalho duráveis, filas, históricos de trabalho e máquinas de estado. Eles não são glamorosos, mas são a diferença entre um agente que parece inteligente na demonstração e aquele que você pode deixar trabalhando enquanto vai tomar um café.

31~

32Para mim, o tempo de execução da agência deve responder a perguntas muito concretas:

33~

34- onde salvo o estado entre uma etapa e outra?

35- o que acontece se o processo morrer no meio?

36- posso fazer uma pausa e pedir aprovação?

37- posso repetir uma corrida para entender por que ele fez essa escolha?

38- posso limitar a duração, a memória, as ferramentas e o custo?

39~

40A Vercel está se esforçando bastante nessa frente com SDKs de IA, funções, fluxos de trabalho e ferramentas para construir agentes em aplicações web. Mas a questão não é apenas Vercel. A questão é que o agente precisa de um local operacional, não de um único terminal.

41~

42## A segunda peça: sandbox, pois o agente deve conseguir se sujar sem quebrar

43~

44Assim que um agente escreve código ou executa comandos, é necessária uma sandbox.

45~

46Parece uma palavra técnica, mas a ideia é doméstica: você dá uma bancada para ele. Ele pode abrir arquivos, instalar dependências, executar testes, fazer experimentos, gerar resultados. Se ele errar, você conteve o dano. Se funcionar, promova o resultado.

47~

48Um sandbox agente deve ter algumas propriedades:

49~

50- sistema de arquivos isolado;

51- CPU, memória e limites de tempo;

52- rede controlada;

53- segredos montados somente quando necessário;

54- registros completos;

55- possibilidade de exportar artefatos;

56- reinicialização limpa entre execuções, quando necessário.

57~

58O Vercel Sandbox vai exatamente nessa direção: ambientes isolados para executar código, instalar dependências, trabalhar com arquivos e produzir artefatos sem executar tudo no tempo de execução da aplicação principal.

59~

60Essa coisa é mais importante do que parece. Muitos protótipos agentes saltam diretamente do modelo para o sistema real. O modelo pode chamar tool. As ferramentas podem fazer coisas. Tudo parece elegante até o primeiro comando errado, a primeira dependência instalada no lugar errado, o primeiro token que vai parar em um log.

61~

62A caixa de areia é a forma adulta de dizer: vá em frente, mas aqui.

63~

64## A terceira peça: MCP e o problema do conector

65~

66O Model Context Protocol tornou-se uma das partes mais interessantes do ecossistema porque tenta padronizar algo que de outra forma rapidamente se tornaria incontrolável: como um modelo descobre e usa ferramentas externas.

67~

68Sem um padrão, cada integração é uma pequena ilha. Um conector para GitHub feito de uma maneira, um para Slack feito de outra, um para bancos de dados com semântica diferente, um para automação de navegador que parece nada.

69~

70O MCP propõe uma linguagem comum entre cliente e servidor: ferramentas, recursos, prompts, autorizações, transporte, descoberta. Não resolve magicamente a governança e a segurança, mas fornece uma gramática.

71~

72E a gramática é importante. Quando um agente pode se conectar a muitas ferramentas, a questão não é apenas “ele consegue fazer isso?”. O problema é “ele entende o que pode fazer, com quais limites, em nome de quem e deixando quais rastros?”.

73~

74Para mim, o MCP não é exagero porque "faz chamadas de ferramentas". Nós já fizemos isso. É um exagero porque muda o centro de gravidade da integração única para o catálogo operacional de ferramentas.

75~

76Em uma boa arquitetura agêntica, o MCP se torna uma espécie de patch panel:

77~

78- GitHub para código e problemas;

79- Slack para contexto conversacional;

80- Linear ou Jira para trabalhos planejados;

81- banco de dados somente leitura para análises;

82- navegador ou raspador controlado para sites externos;

83- armazenamento de documentos;

84- ambientes de execução isolados;

85- sistemas internos expostos com permissões estritas.

86~

87A parte complicada é que um catálogo de ferramentas sem políticas é apenas uma forma mais elegante de criar o caos.

88~

89## A quarta peça: identidade e permissões

90~

91Esta é a área onde muitas demonstrações fecham os olhos.

92~

93Um agente atua em nome de alguém. Portanto, deve ficar claro quem é o sujeito da ação.

94~

95Está usando permissões de usuário? De uma conta de serviço? De um espaço de trabalho? Você tem acesso temporário ou permanente? Você consegue ler tudo ou apenas alguns recursos? Você pode escrever? Você pode cancelar? Ele pode enviar mensagens para pessoas reais?

96~

97Se você não responder bem a essas perguntas, mais cedo ou mais tarde construirá um assistente com as chaves de casa e sem memória de quem as deu a ele.

98~

99A regra que gosto é esta: o agente deve ser capaz de fazer menos que o humano, e não mais que o humano. E quando ele tem que fazer algo mais arriscado, ele tem que parar e perguntar.

100~

101Isso significa OAuth, escopo de token, gerenciamento de segredos, log de auditoria, política de ferramentas, lista de permissões, etapa de aprovação. Coisas não muito românticas. Coisas necessárias.

102~

103## A quinta peça: memória e contexto, mas sem acumular lixo

104~

105Os agentes precisam de memória, mas a memória é perigosa quando se transforma num sótão.

106~

107Existem pelo menos três tipos de memória:

108~

109- memória de execução: o que aconteceu nesta execução;

110- memória de projeto: convenções, decisões, restrições;

111- memória pessoal ou de equipe: preferências, tom, rituais, processos.

112~

113Colocar tudo no prompt é o atalho. Funciona até não funcionar mais. A memória útil deve ser cuidada: indexada, atualizada, expirada, verificada, tornada citável.

114~

115Um agente que se lembra mal é pior do que um agente que não se lembra. Porque ele fala com confiança.

116~

117Portanto, a infra-estrutura deve incluir recuperação, arquivos de instruções, base de conhecimento, incorporação quando necessário, mas também limpeza. Precisamos de uma cultura da memória: o que entra, quem aprova, quando decai, como faço para corrigir.

118~

119## A sexta peça: observabilidade, avaliação e repetição

120~

121Se um agente cometer um erro, o log “chamado de modelo” não será suficiente.

122~

123Você quer ver a rota. Que contexto ele recebeu? Quais ferramentas estavam disponíveis? Qual ferramenta você escolheu? Com que argumentos? Que resposta você obteve? Quanto custou? Onde ele ficou preso? O humano aprovou alguma coisa? O erro é um erro de modelo, ferramenta, prompt, dados ou permissão?

124~

125Aqui os agentes são mais parecidos com sistemas distribuídos do que chatbots.

126~

127Você precisa de rastreamentos legíveis, não apenas de registros de texto. Você precisa ser capaz de reproduzir uma corrida. É necessário comparar duas versões do mesmo agente em tarefas conhecidas. Precisamos medir as regressões: não apenas "responde melhor", mas também "fecha o ticket certo sem tocar em arquivos não solicitados".

128~

129As avaliações de agente são mais difíceis do que as avaliações de texto porque incluem ações. Não é suficiente comparar uma string esperada. É preciso observar as sequências, os efeitos colaterais, a qualidade do artefato, o tempo, o custo, o número de intervenções humanas.

130~

131O engraçado é que sempre voltamos lá: engenharia de software. Testes, ambientes, rastreamentos, reversões. Só que o código agora também decide o que fazer a seguir.

132~

133## A sétima peça: interfaces humanas

134~

135O agente não precisa apenas viver em um chat.

136~

137Alguns agentes precisam de um conselho. Outros uma página com status e log. Outros de um botão "aprovar". Mais comentários embutidos. Ainda outros de uma CLI.

138~

139A IU muda o comportamento. Se a única maneira de controlar um agente for escrever uma mensagem longa, o usuário dará instruções vagas ao agente. Se, no entanto, ele vir o plano, as diferenças, as fontes, os riscos e a próxima ação, ele poderá intervir com precisão.

140~

141Uma infraestrutura de agente decente inclui superfícies de controle:

142~

143- situação atual;

144- plano editável;

145- artefatos produzidos;

146- diferença;

147- solicitações de aprovação;

148- cronologia;

149- botão parar;

150- botão de tentar novamente;

151- permissões visíveis.

152~

153Parece trivial, mas não é. A diferença entre “IA assustadora” e “assistente confiável” geralmente é apenas que o último mostra onde está as mãos.

154~

155## A pilha mental

156~

157Se eu comprasse hoje, o stack mínimo do agente seria este:

158~

1591. Modelo: raciocínio, geração, chamada de ferramenta, multimodal se necessário.

1602. Orquestração: loop, etapa, planejador, política, humano no circuito.

1613. Tempo de execução durável: fluxo de trabalho, fila, nova tentativa, pausa, retomada.

1624. Sandbox: execução de código, sistema de arquivos isolado, limitações, artefatos.

1635. Camada de ferramentas: MCP, API interna, navegador, banco de dados, repositório.

1646. Camada de identidade: OAuth, escopo, segredo, auditoria, política.

1657. Camada de memória: contexto do projeto, recuperação, instruções, expiração.

1668. Observabilidade: métricas de rastreamento, repetição, avaliação, custo e qualidade.

1679. Superfície do produto: converse quando for suficiente, painel quando necessário, revise quando for importante.

168~

169A estrutura de agência cobre principalmente os pontos 2 e uma parte do ponto 1. O resto é o verdadeiro trabalho.

170~

171## O que eu faria na prática

172~

173Se uma equipe me dissesse “queremos agentes em produção”, eu não começaria com dez agentes.

174~

175Eu começaria com um fluxo de trabalho pequeno, repetitivo e observável. Por exemplo: abrir PRs de manutenção, atualizar a documentação de problemas fechados, preparar uma revisão semanal, fazer triagem de bugs duplicados, gerar testes para arquivos afetados.

176~

177Então eu estabeleceria limites muito claros:

178~

179- não é permitido escrever sem ramificações ou sandbox;

180- sem segredos no prompt;

181- ferramentas na lista de permissões;

182- aprovação humana para ações externas;

183- registro e rastreamento obrigatórios;

184- orçamento por execução;

185- saída sempre inspecionável.

186~

187Só então eu expandiria.

188~

189Os agentes não falham só porque os modelos erram. Eles falham porque os colocamos em ambientes vagos, com permissões confusas e expectativas teatrais.

190~

191## Minha leitura

192~

193A infraestrutura agente é entediante da melhor maneira.

194~

195Não é a parte que te faz bater palmas na demo. É a parte que permite que você realmente use a demonstração na manhã de segunda-feira, com pessoas reais, dados reais e consequências reais.

196~

197O futuro dos agentes não será decidido apenas por quem tiver o melhor modelo. Será decidido por quem construir o melhor lugar para fazê-lo trabalhar: isolado quando experimenta, conectado quando necessário, sempre observável, autorizado com critério e humilde o suficiente para parar quando não sabe.

198~

199É aí que os agentes deixam de ser um brinquedo e passam a ser infraestrutura.

200~

201## Fontes

202~

203- [Vercel: Como construir agentes de IA com Vercel e o AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Documentos Vercel: Sandbox](https://vercel.com/docs/sandbox)

205- [Vercel Docs: Trabalhando com Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Documentos Vercel: MCP](https://vercel.com/docs/mcp)

207- [Protocolo de Contexto do Modelo: Especificação](https://modelcontextprotocol.io/specification)

208- [OpenAI: Novas ferramentas para agentes de construção](https://openai.com/index/new-tools-for-building-agents/)

209- [Blog da Cloudflare: Agentes na Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210~